Coordinate Coding Agents That Share a Browser or Desktop
Drafted and reviewed using AI assistance.
On this page
Give shared browser work its own owner and handover record. Two coding tasks can have separate working trees while still depending on the same visible window, focused field or desktop input path. Before either task sends its next UI action, establish who may act, which target they have just inspected and what ends that turn.
A public feature request about parallel computer use asks for “a visible queue/lock when two agents request the same app.” That is a reported coordination need. It does not establish which features a current agent host offers, whether a reported setup still behaves the same way or how common the problem is.
The example below uses a manual coordinator and harmless fictional pages. Its turn labels are entries in a note, not native leases or operating-system locks. No browser, account, desktop, agent host or working tree was operated to produce the histories.
Map the shared surface as well as the code
The fictional Fern project has two coding tasks and one shared browser window. The paths and .invalid addresses are illustrative identifiers; they are not resources to open.
| Task | Owned working tree and branch | UI target | Requested delivery |
|---|---|---|---|
| A · Card spacing | /fictional/fern-layout, branch layout-gap |
https://layout.example.invalid/cards, banner FERN LAYOUT / L-17 |
spacing-check.md: inspect the grid overlay on the named preview |
| B · Empty-state copy | /fictional/fern-copy, branch empty-copy |
https://copy.example.invalid/empty, banner FERN COPY / C-08 |
copy-check.md: inspect the local draft wording on the named preview |
Both tasks point to the same UI resource, BR-1: the one browser window visible on the same fictional desktop. There may be two page tabs, but this example has no verified native window or tab identifiers and no verified tool binding to either target. The manual label BR-1 does not create those capabilities.
Git's worktree manual describes multiple working trees associated with a repository, including per-worktree state such as the index and HEAD. That identifies a code-management boundary. In this case, browser ownership is a separate application-workflow decision: assigning A and B different directories has not assigned them different input destinations.
The two page fixtures are complete enough to expose a focus mistake:
| Page | Initial state | Allowed local check |
|---|---|---|
| Layout L-17 | Show grid checkbox is unchecked |
Focus that checkbox and toggle it once; observe the overlay; do not edit other controls |
| Copy C-08 | Empty-state draft textarea contains Nothing here yet. with its caret at the end |
Replace only that local draft with No cards yet.; inspect it; do not save, submit or publish |
The shared resource also includes focus. MDN's keydown reference explains that a key event targets the focused element and can bubble. A remembered screenshot or intended field is not a reservation of the next keyboard destination.
Keep known and unknown identity separate
Use a resource card before handing over input:
Resource label: BR-1 (manual note label only)
Scope: one shared visible browser window and its desktop input path
Coordinator/operator: M
Candidate tasks: A, B
Known from the fictional setup:
- A's requested URL and banner: layout.example.invalid/cards; FERN LAYOUT / L-17
- B's requested URL and banner: copy.example.invalid/empty; FERN COPY / C-08
- Both request the same window resource
Unknown until inspected for the next step:
- Which page and control currently have focus
- Whether the expected preview revision is still visible
- Whether another actor changed the window since the last observation
Not established in this example:
- Native window/tab IDs or a documented automation target binding
- Any native lock, isolated desktop, lease expiry or input-queue cancellation API
Chosen operating mode:
M performs UI steps manually, one bounded request at a time.
A and B submit requests and inspect returned notes; they send no device input.
A URL and banner help M inspect the page, but do not replace a native target binding for an automated tool. If the URL or intended window cannot be identified reliably, even the manual step waits. If an actual host provides a suitable documented binding, record its documented scope before changing this operating mode. This guide makes no claim that a current Codex release has or lacks one.
Walk a complete focus conflict
The following is the unsafe fictional history. It deliberately permits both agents to send unscoped input. Start with the checkbox unchecked and the copy draft exactly as shown above.
| Step | Intended action or intervening event | Visible target at that moment | Expected consequence in this invented history |
|---|---|---|---|
| F1 | A inspects L-17 and focuses Show grid |
Layout L-17 checkbox | A prepares one Space press to toggle the overlay |
| F2 | B switches the shared window to C-08 and focuses the draft | Copy C-08 textarea, caret at end | A's earlier target observation is now stale |
| F3 | A's unscoped Space input is delivered | Copy C-08 textarea | Draft becomes Nothing here yet. with one trailing space; the layout checkbox is unchanged |
| F4 | A treats input delivery as proof of the grid check | Still Copy C-08 | That conclusion is unsupported; no current grid observation exists |
| F5 | M stops further UI input from both tasks for investigation | Shared resource is held out of use | Preserve the changed draft and the two action accounts; do not “repair” an unconfirmed target by typing again |
The final fixture state is precise: the checkbox remains unchecked, the copy draft has gained one U+0020 space and neither task has a valid completed UI check. There is no claim that a particular automation product routes input this way. The sequence illustrates the consequence of allowing an action whose destination changed after inspection.
If a host can bind an action to a particular element or page, inspect that documented behavior rather than assuming this failure applies to it. The example's unscoped-input assumption belongs to the example.
Give the coordinator five decisions
Here, own means permission under this manual plan to request the next bounded UI step. It is not a technical access-control state. M remains the only device operator in the sequential history.
| Decision | Use it when | What must be recorded before proceeding |
|---|---|---|
| Own | M admits one task for an identified target and scope; no earlier manual step is in progress | Task, resource, turn label, exact allowed action and fresh target inspection |
| Wait | Another task owns the turn, identity is uncertain, or a prior action's disposition is unknown | What is missing and who must establish it; no UI input while waiting |
| Yield | The owner finishes or reaches a stopping point | Last observed page/control, draft changes, uncompleted requests and a statement that no further steps are requested under that turn |
| Reinspect | A turn starts, focus/navigation changes, a human intervenes or an observation becomes stale | Current URL/banner/revision, focused control and whether the next action still fits |
| Revoke | M withdraws a turn after an unexpected change, uncertain operation or human takeover | Stop requesting new actions, preserve what is known, mark unresolved actions unknown and do not grant the next turn until the resource is accounted for |
Yield is complete only when M acknowledges it. A task saying “finished” does not establish that an earlier device command has stopped. In this manual version, M's pending list contains requests in text, not a hidden queue of browser commands. If a real deployment has in-flight or queued tool operations, use only its documented stop/observation mechanisms; an unanswered cancellation is an unknown, not an empty queue.
A time limit should prompt a stop and status check. It should not automatically grant B a turn while A may still be acting. Likewise, revoking a note does not forcibly interrupt an already-issued operation. If participants or tools do not honor the arrangement, the note cannot enforce exclusion.
Walk the sequential handover from a clean start
This is a separate history with the original unchanged fixture values. It does not silently erase the trailing space from F3. All observations and outcomes below are stipulated teaching expectations.
| Step | Coordinator decision and action | Owner / turn | Recorded state and next condition |
|---|---|---|---|
| S1 | M receives A's grid check and B's draft check | None | Original two page values; both UI requests are pending |
| S2 | M admits A's one-step check; B waits for UI access | A / H1 | Scope is only L-17 Show grid; B can continue its separate file work |
| S3 | M selects the Layout page and reinspects URL, L-17 banner and checkbox focus | A / H1 | Target matches; checkbox is unchecked; no earlier manual step is in progress |
| S4 | M performs A's one toggle and observes the overlay | A / H1 | Checkbox is checked; copy draft remains Nothing here yet.; A's note records the named revision and this expectation |
| S5 | A yields H1, reporting the checked box and no remaining requests under H1 | A / H1 until acknowledgement | M accounts for the completed manual step and records that H1 requests have ended |
| S6 | M acknowledges yield, then admits B | B / H2 | H1 no longer applies; B must inspect its own target before input |
| S7 | M selects the Copy page and reinspects URL, C-08 banner, draft value and focus | B / H2 | Draft is still Nothing here yet.; no Layout action is carried into H2 |
| S8 | M replaces only that local draft and inspects it | B / H2 | Draft becomes No cards yet.; grid remains checked; nothing is saved or submitted |
| S9 | B yields H2; M accounts for its step and acknowledges | None | No pending manual UI requests; last page is Copy C-08 |
| S10 | M returns the two scoped notes to the tasks | None | A's grid observation and B's draft observation remain separate; neither claims a production release or repository acceptance |
H1 and H2 are manual turn labels, not fencing tokens. The sequence assumes participants cooperate and no outside actor changes the window during a bounded manual step. An unexpected change takes the revoke branch instead of being ignored to keep the table moving.
Make the unknown and revoke branches usable
If M reaches S3 but sees a different banner or cannot establish which window is active, H1 performs no toggle. Record target_unknown, keep B waiting and ask for the target mapping to be re-established. A familiar tab title is insufficient. A new inspection must identify the intended page and revision before a new turn is admitted.
If an unexpected navigation or human takeover occurs after H1 was admitted, M records H1 as revoked. A stops requesting H1 actions. An action already issued but not accounted for remains outcome_unknown; M does not infer that it failed or repeat it against a newly focused control. Record the available observation, reconcile that action's status using the actual host's documented facilities, and only then consider a new turn. Human takeover is not a race to regain focus.
For a complete yield, use a compact card like this:
Task / resource / turn: A / BR-1 / H1
Allowed step completed: one toggle of L-17 Show grid
Last observed URL/banner: layout.example.invalid/cards; FERN LAYOUT / L-17
Last observed focus/state: Show grid; checked; overlay visible
Draft changes: none requested or made in the Copy page
Outstanding manual requests: none
Outstanding device operation: none in this stipulated manual sequence
Next action under H1: none; waiting for M's yield acknowledgement
If any operation is actually unaccounted for: stop here and record UNKNOWN
The card reports an observation; it does not keep it current forever. B still needs S7. Reusing A's coordinates, screenshot or “window ready” statement would skip the part of the handover that protects B's next decision from stale context.
Copy a bounded coordination request
Coordinate fictional Fern tasks A and B using the resource map,
focus-conflict history F1–F5 and sequential history S1–S10.
Do not open the .invalid URLs or operate a real browser, account or desktop.
Task A: /fictional/fern-layout, layout-gap, Layout L-17 grid check.
Task B: /fictional/fern-copy, empty-copy, Copy C-08 local draft check.
Separate working trees do not establish separate UI targets in this setup.
BR-1 is a manual shared-resource label, not an API identifier.
Use the manual mode: M is the sole UI operator; agents submit text requests.
No agent sends global keys, clicks or window changes while another turn
owns the resource. File work that does not touch the shared UI may continue.
Each admitted turn has one task, target revision, action scope and end condition.
M acknowledges yield before admitting the next turn; no timeout auto-transfer.
Reinspect actual target and focus before each bounded step and after handover
or unexpected change. Unknown target: wait, do not guess or probe by typing.
Revoke: stop new requests; retain already-issued unknown outcomes without replay.
If a real tool queue exists, its stopped/idle state needs documented evidence.
Manual acknowledgement is not proof of a native lock or canceled operation.
For any later automation adaptation, first identify the selected host/version
and official documentation for target binding, observations and stopping.
Use only the capabilities actually established there. If binding or stopping
cannot be established, retain the manual-operator path or stop UI work.
Do not invent acquire/release/lease APIs or a Codex feature assertion.
Return the completed resource/known-unknown map, both full histories,
own/wait/yield/reinspect/revoke cards, and separate observations for each task.
Preserve the exact draft strings, the extra F3 trailing space and the clean
start of the separate sequential example. Do not report expectations as runs.
No real deployment, account access or production action is included.
This arrangement organizes cooperating work; it does not isolate browser profiles, application storage, accounts or secrets. If the work needs a stronger technical boundary, establish that boundary separately before using the resource. A clear handover remains useful because it names the next action, the target that action belongs to and the evidence needed to let someone else proceed.