[macOS][Browser Use] Session route race leaves Chrome readable but CDP input commands time out

What version of the Codex App are you using?

26.818.41509

What platform are you using?

• macOS 26.5.2 (25F84)
• Google Chrome 151.0.7922.172
• ChatGPT Chrome extension 1.2.27268.51612

What issue are you seeing?

Browser Use can create Chrome tabs, navigate, read the DOM, and capture screenshots, but click and keyboard operations intermittently time out in Input.dispatchMouseEvent, Input.dispatchKeyEvent, or Input.insertText.

The issue is not specific to ChatGPT pages. It was reproduced on a neutral HTML form page: DOM discovery succeeded, but clicking an input and entering a non-sensitive test string timed out.

Chrome and extension diagnostics pass:

• Chrome is running.
• The extension is installed, registered, and enabled.
• The Native Messaging manifest is valid and contains the expected extension origins.
• No extension disable reason or manifest error was reported.

Sanitized desktop lifecycle evidence shows:

1. The desktop app successfully captures the Browser Use session route.
2. Shortly afterward, the same session is reported as having no available browser route.
3. Concurrent getInfo requests for the same session can produce both failures and a success within milliseconds.
4. Browser sidebar ownership can be rebound to another Codex task while Browser Use is active.
5. A controlled Chrome tab initially has a valid target, but the target later becomes undefined after the input timeout.
6. Repeated recovery attempts create multiple Chrome backend identities for the same Codex task.

No raw logs, session identifiers, local paths, authenticated URLs, task content, or project information are included in this report.

Steps to reproduce

1. Start a Codex Desktop task on macOS.
2. Select the connected Chrome extension backend.
3. Create a fresh Chrome tab and navigate to a simple HTML form.
4. Confirm that tab discovery, navigation, DOM inspection, and screenshots work.
5. Click a text input and type a short non-sensitive test string.
6. Observe that a CDP Input.* command may time out even though read operations succeeded.
7. Inspect the desktop lifecycle logs and observe missing or inconsistent Browser Use route lookup for the active task.

The problem becomes more likely during long-running workflows involving multiple Codex tasks or after Browser Use runtime recovery attempts.

Expected behavior

A Browser Use session route should remain atomically and exclusively associated with its owning Codex task until the session ends. Switching or syncing another task should not invalidate an active Chrome target.

If no valid route exists, Browser setup should fail immediately instead of returning a partially functional browser handle.

Actual behavior

The session route registry can become inconsistent or be rebound. Read and navigation operations may continue through a surviving connection, while CDP input commands target a missing or stale route and time out.

Impact

Long-running browser workflows become unreliable. Failed input cannot be safely retried because it may have partially executed, and repeated recovery attempts can create additional stale backend/session associations.

Suggested fix areas

• Make Browser Use route capture and lookup atomic.
• Prevent browser-sidebar owner changes from detaching an active task's Chrome session.
• Fail setup immediately when the session route is unavailable.
• Clean up stale Chrome backend identities after runtime or session termination.
• Add a regression test with multiple Codex tasks while one task repeatedly performs DOM reads and CDP input actions.

Related issues

• #35083 — Browser route loss and lifecycle cleanup on macOS
• #35372 — Active macOS thread loses Browser route

Privacy

This report intentionally omits session/thread/browser/tab identifiers, local paths, authenticated URLs, task content, and usage context. Narrowly selected sanitized lifecycle excerpts can be provided if maintainers specify a private channel.