Acquire before starting the browser

The client obtains a lease before starting a team profile. The server rejects a conflicting acquisition while that lease is valid. Startup is part of the lease lifetime, so a slow launch still needs renewal and cancellation handling. A profile that never reaches its ready state must not leave an unmanaged child runtime behind.

Renewal failure is a lifecycle event

While a profile runs, the client renews its lease. If it cannot maintain the deadline, the application starts closing the runtime with a safety margin. A normal close waits for the actual child process to stop before releasing ownership. Reporting a window-close request is not sufficient evidence that the browser has finished saving or exited.

An unreachable client cannot be wished away

When access is revoked, the server may retain an existing lease until its original expiry. This prevents another client from acquiring the same profile immediately while the first Mac may still be shutting down or offline. The interface should distinguish that bounded waiting period from a failed permission check.

Settings need conflict detection too

Profile revisions prevent an older client from overwriting a newer configuration without noticing. The service also rejects conflicting changes while a profile is leased. On a conflict, reload the current settings and review the difference before retrying. Repeatedly submitting the same stale update is not a recovery strategy.

Test the transitions, not only the happy path

Our fixtures exercise lease acquisition, runtime startup, close, expiry and a competing client. The separate API load run created 450 profiles for 30 clients and checked renewal, revocation and persistence across server restarts. Those results cover controlled cases; they are not a guarantee for arbitrary network outages or a claim that the server runs 450 browser processes.