[macOS] Browser automation profile collision gives no owner or safe reconnect path

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT/Codex Desktop 26.818.41509 (build 6962); bundled codex-cli 0.149.0-alpha.4.1

What subscription do you have?

Not captured. The failure is local browser-profile ownership.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

During browser/UI proof from multiple Codex Desktop tasks, the normal browser automation surface failed with:

Browser is already in use for <redacted>/mcp-chrome-<profile-id>

This was observed across two task handoffs. The error did not identify which task or session owned the profile, whether the owner was live or stale, or whether attach/reconnect was safe. The only bounded way to finish the product proof was to use a separate CLI Playwright browser.

Observed: profile acquisition failed and no owner/recovery information was returned.

Inferred, not proven: a persistent automation profile was shared across tasks without an ownership handoff or reconnection protocol. The error alone does not establish whether the holder was live, stale, or recoverable.

What steps can reproduce the bug?

The exact collision has not been made deterministic.

1. Keep one Codex Desktop task alive after it has used browser automation.
2. From another task, invoke the normal browser automation surface.
3. In the observed failures, the second task received the profile-in-use error above and could not identify or safely reconnect to the owner.

The symptom occurred twice during separate UI-review handoffs.

What is the expected behavior?

Prefer one of:

• an isolated disposable browser profile per task; or
• an owner-aware broker for a persistent profile.

At minimum, a collision should return the owning task/session, lease state, and a bounded safe attach, wait, or release action. It should not require blind retries or killing an unidentified browser process.

Additional information

I searched existing openai/codex issues before filing. #21984 is related browser-MCP lifecycle evidence, but it explicitly focuses on eager process accumulation and notes that a profile collision was not its primary observed failure. This report is specifically about failed shared-profile admission plus the absence of owner-aware recovery.

No raw logs or private task data are included.

Start with the normal browser automation surface and the profile-acquisition failure described in the issue; the exact collision is not yet deterministic. Reproduce the two-task handoff scenario, then define and verify owner-aware recovery or isolated per-task profiles, including a bounded attach, wait, or release outcome.