Browser backends are not propagated consistently across Desktop, CLI, and collaboration subagents #32664

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   browser

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   on Jul 13, 2026
2. github-actions commented on Jul 13, 2026

   

   github-actionsBot

   on Jul 13, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Terminal npm Codex cannot reach connected Chrome extension; app-bundled binary works #31980

   Powered by Codex Action
3. FranciscoJSBarragan commented on Jul 13, 2026

   

   FranciscoJSBarragan

   on Jul 13, 2026

   Author

   More actions

   I reviewed the suggested duplicate #31980 and its canonical issue #30545.

   They overlap with only one control result in this report: standalone npm Codex 0.144.1 cannot discover the connected Chrome extension backend and returns Browser is not available: extension with agent.browsers.list() => [].

   The primary reproduction here is different:

   • In the same Codex Desktop task, the root agent successfully acquires iab and navigates https://example.com/.
   • A collaboration subagent spawned from that working task loads the same Browser skill/client but fails with Browser is not available: iab.
   • The healthy parent IAB backend/session route is therefore not propagated or rebound to the child thread.

   #31980/#30545 do not cover collaboration subagents or the Desktop root-versus-child IAB availability mismatch. The CLI Chrome result is included only as a comparison/control and should be tracked under #30545. The standalone CLI IAB-skill-without-backend behavior is already related to #25647.

   I am keeping this issue open for the Desktop collaboration-subagent IAB propagation failure. If maintainers prefer, the title/body can be narrowed to that specific regression while retaining the CLI results only as diagnostic context.
4. rufusclaw1234 commented on Jul 16, 2026

   

   rufusclaw1234

   on Jul 16, 2026

   More actions

   Additional deterministic macOS CLI → Desktop handoff evidence

   I reproduced this on 2026-07-16 with:

   • macOS 26.5.2 (25F84), arm64
   • ChatGPT/Codex app 26.707.91948 (build 5440)
   • Codex CLI 0.144.5
   • bundled Browser plugin 26.707.91948

   This narrows the standalone interactive CLI failure: the Desktop handoff reaches the correct visible thread and ChatGPT publishes a live Browser socket, but the supported Browser client still finds no IAB backend matching the CLI session.

   Reproduction

   1. Start a brand-new interactive Codex CLI session.

   2. Confirm that nodeRepl.requestMeta["x-codex-turn-metadata"].session_id, thread_id, and the rollout session_meta.session_id are the same UUID.

   3. After the session is fully initialized, run:

      /usr/bin/open -a /Applications/ChatGPT.app \
        'codex://threads/<the-current-cli-session-id>'

   4. ChatGPT visibly switches to the exact CLI thread (the transcript matches).

   5. At the handoff, a new /tmp/codex-browser-use/*.sock appears and is owned by the live ChatGPT process.

   6. Initialize the bundled Browser client through the documented mcp__node_repl__js path and run:

      await agent.browsers.get("iab")

      Actual:

      Browser is not available: iab
      

   7. Follow bootstrap-troubleshooting and run the supported fresh scan:

      await agent.browsers.list()

      Actual:

      []

   8. Repeat the app-targeted deep link after the CLI session has been active for several minutes. ChatGPT still opens the correct thread, but the fresh backend scan remains [].

   Diagnostic significance

   This rules out stale Launch Services routing and a one-shot empty-client cache as explanations for this reproduction. The app handoff works and a live socket exists, but all IAB candidates are removed before the Browser surface is exposed to the CLI.

   The current bundled client filters IAB candidates by comparing the backend's metadata.codexSessionId with the current Codex session identity. The observed behavior is therefore consistent with the Desktop socket being published under a different session/route identity even though the UI opens the correct persisted thread. This appears to be the same session-ownership failure class discussed in #20678, now demonstrated specifically across an exact interactive CLI → Desktop deep-link handoff.

   Expected: opening the exact persisted CLI thread in Desktop should publish or rebind an IAB backend whose session identity matches that CLI thread, allowing get("iab") and list() to succeed.

   I did not bypass the trusted Browser client boundary or attempt raw socket control.
5. sh58702e commented on Aug 20, 2026

   

   sh58702e

   on Aug 20, 2026

   Last edited by sh58702e

   More actions

   Deterministic root vs subagent IAB session-scoping evidence — Desktop 26.814.41407

   I reproduced the collaboration-subagent case on macOS with ChatGPT/Codex Desktop and the bundled Browser plugin both at 26.814.41407.

   Observed metadata relationship:

   • The root turn owns a working iab; agent.browsers.list() returns one IAB registered to the root Codex session.
   • A spawned collaboration subagent has a distinct child thread_id.
   • Its trusted turn metadata still carries the same root session_id, identifies the root as parent_thread_id, and marks thread_source as subagent.
   • In that child, the documented fresh Browser setup returns agent.browsers.list() => [], and get("iab") fails with Browser is not available: iab.

   The bundled browser-service behavior explains the deterministic mismatch: for a subagent it derives the IAB discovery/session key from the child thread_id, then filters IAB candidates by exact equality with each backend's metadata.codexSessionId. The available IAB is registered to the shared root session, so it is removed before claimTab() can be used. Fresh setup does not change the result.

   This is not a plugin-version, enabled-backend, or stale-client mismatch. I did not patch config, trusted services, bundled files, or raw browser sockets.

   A security-preserving fix would separate:

   • browser ownership: trusted root session_id;
   • caller attribution: child thread_id and turn_id.

   An authorized child belonging to the same trusted root session should discover that root session's IAB, while unrelated sessions, missing metadata, and malformed metadata continue to fail closed.

   Suggested regression matrix:

   1. Root metadata + matching root IAB → visible.
   2. Child metadata + same root session_id + distinct child thread_id → same IAB visible.
   3. Unrelated root session_id → IAB absent.
   4. Missing or malformed trusted metadata → fail closed.
   5. Explicit IAB request → never fall back to Chrome.
   6. Child command → root browser ownership retained, child thread/turn attribution retained.
   7. claimTab() and later-turn handoff continue to work only inside the owning root session.

   As a local workflow mitigation, I am separating root-only Browser evidence capture from subagent implementation, with a frozen manifest/SHA handoff and no concurrent writers. That mitigates blocked work but does not fix child IAB discovery.
6. the-rpc commented on Sep 6, 2026

   

   the-rpc

   on Sep 6, 2026

   More actions

   Additional Windows reproduction using Codex Desktop's exposed mcp__cua_repl.js / cua interface:

   This also occurs intermittently in native Desktop subagents. A custom native role spawned with fork_turns="none" can receive:

   let tab = await cua.createBrowserTab("iab", url, {visible: false});

   Browser is not available: iab
   

   A subsequent await cua.getState() returns apps=[] and browsers=[]. The navigation action was allowed by approval review, so this failure was not an approval denial. No browser tab was created.

   Explicit iab selection succeeded in two preceding native-child runs, including closing the created tab, then failed in another fresh child. It therefore does not reliably work around the availability issue. These were native Desktop children, not independently launched CLI sessions.

   Earlier comparisons of successful and failing native children found browser route-capture/backend-ready records for working children but no matching records for failing children, even though their parent had browser readiness records. This suggests a child-session registration/lifecycle issue, but does not establish the cause. Equivalent spawn options did not ensure equivalent browser availability.

   Expected: native Desktop children assigned browser work should receive a usable browser session or a documented deterministic capability limitation. The failure is intermittent, rather than reproducible on every spawn.

   Platform: Windows. Exact Desktop build was not captured. No logs, session identifiers, timestamps, user/workflow data, or configuration files are included in this comment.