Bug report: the in-app browser never binds to the active conversation, and the Chrome/Edge native-host runtime registry is never written

Environment

Relevant feature flags (codex features list) are all enabled: browser_use,
browser_use_external, computer_use, in_app_browser.

The app's own availability state machine resolves to the success state:

browser_use_availability_resolved available=true browserPane=true
  platform=Windows reason=available release=26.1007.71326

So this is not a gating / entitlement / settings problem. Decoded from app.asar, the
other possible reasons would have been statsig-disabled, browser-pane-disabled,
config-requirement-disabled or wsl-disabled. None of those is reported.

Issue 1 - the in-app browser route is reassigned to an unsent "new chat" draft

agent.browsers.get("iab") fails in the conversation the user is actually typing in.
Two distinct failure modes are observed.

1a. Route stolen by a client-new-thread: draft

Every attempt produces this sequence in the desktop app log. The route is taken from the
real conversation and handed to an unsent new-chat draft:

IAB_LIFECYCLE received browser sidebar owner sync
    conversationId=client-new-thread:85bc1bb7-280d-41ea-9429-566756fd062f
IAB_LIFECYCLE reassigned browser use route
    sourceConversationId=01a13b39-24c2-7ef0-9407-9aab3d8b8f06   <- the real conversation
    targetConversationId=client-new-thread:85bc1bb7-280d-41ea-9429-566756fd062f
IAB_LIFECYCLE iab backend info request failed
    conversationId=01a13b39-24c2-7ef0-9407-9aab3d8b8f06
    errorMessage="No ChatGPT browser route is available for browser session 01a13b39-..."
IAB_LIFECYCLE created browser use host
    conversationId=client-new-thread:85bc1bb7-...
    routeKey=1:client-new-thread:85bc1bb7-...
IAB_LIFECYCLE ended browser use session activity
    conversationId=01a13b39-24c2-7ef0-9407-9aab3d8b8f06

The same pattern repeats with different draft ids (c5896cf5, 60c87272, 967bcc59,
766a9dc0, 85bc1bb7): each time the app creates a fresh draft, the draft takes the pane.

Some getInfo calls for the same conversation succeed while adjacent ones fail, so the
binding is also flapping:

iab backend info request completed  conversationId=01a13b39-...  metadataCodexSessionId=01a13b39-...
iab backend info request failed     conversationId=01a13b39-...  "No ChatGPT browser route is available"

1b. iab absent from browsers.list() entirely

In other attempts no iab backend is started for the new conversation at all, and the agent
gets:

Browser is not available: iab

In one session this was called 23 times, all of them before the app started an iab
backend for that conversation. The backend only became ready about 2.5 hours later, when
the browser sidebar happened to be bound to it.

What was tried, with no effect

• Sending a message first so the conversation has a real id, then opening the Browser pane
• Opening the Browser pane first, then asking
• Loading a real page in the pane rather than leaving it blank
• Using the documented [@Browser](plugin://browser@openai-bundled) plugin mention
• Reducing to a single app window (logs had shown both windowId=1 and windowId=3)
• Reinstalling the Browser plugin from the app's plugin UI
• Restarting the app repeatedly

The provider side is healthy throughout: browser_use_iab_backend_startup_ready is logged
with a pipe path, and all \\.\pipe\codex-browser-use* pipes accept connections (verified
by connecting to all 14 of them directly). The failure is purely the
(windowId, conversationId) route binding.

Issue 2 - chrome-native-hosts-v2.json is never rewritten, so Computer Use cannot read a browser URL

%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json is the runtime registry that
extension-host.exe reads to find a live Codex runtime. Both app.asar and
extension-host.exe contain that filename; codex.exe does not, so only the desktop app
writes it.

On this machine its single entry is stale, last written 2026-10-14 09:54 local:

appVersion : 26.1007.21434
entryId    : codex-runtime-b097ad1c296eb4c397931a8d229997df
presence   : pid 19348, lastSeenAt 2026-10-14T01:53:36Z
extensionHostPath : C:\Program Files\WindowsApps\OpenAI.Codex_26.1007.2314.0_x64__2p2nqsd0c76g0\...\extension-host.exe
browserClientPath : C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\latest\scripts\browser-client.mjs

Problems with that entry:

1. presence.pid 19348 is dead.
2. extensionHostPath points into app package 26.1007.2314.0, which the update to
   26.1007.9446.0 removed, so the path does not resolve.
3. browserClientPath references ...\chrome\latest\scripts\, but nothing creates the
   latest junction (see secondary findings), and since 26.1007.71326 the chrome plugin
   ships no scripts/ directory at all.

The app never rewrites it

• Restarting the app 4+ times, including after the update to 26.1007.9446.0: file untouched.
• Deleting the file and restarting the app: it is not recreated.
• Reinstalling the Browser plugin from the app's plugin UI: it is not recreated.
• Across every desktop log on this machine, the strings chrome-native-hosts,
  codex-runtime-, entryId, installId and nativeHostVersion have zero hits, so
  the write path is silent and apparently never runs.

extension-host.exe processes do start when Chrome or Edge launches (confirmed by
process start times matching browser launches), so the Chrome/Edge side of native
messaging works. The host simply has no live runtime to connect to.

Observable consequence: Computer Use is hard-blocked on all browser windows

Computer Use itself is healthy. sky.list_windows() returns windows, and screenshots,
clicks and accessibility trees all work on non-browser apps. But any interaction with a
browser window fails with:

Computer Use has been stopped for this turn because it could not determine the current
browser URL on Windows with enough confidence to enforce policy. Stop your work and
send a final message noting why Computer Use ended.

(from src/policy/url_policy.rs in codex-computer-use.exe; this is the "supported
browser, URL unreadable" variant, not the "browser not supported" variant.) Since the
policy check needs the extension to report the URL, and the extension has no route to a
live runtime, every browser task is refused. This makes Computer Use unusable for web work.

Secondary findings (genuine gaps, worked around locally)

1. plugins\cache\openai-bundled\chrome\latest is never created.
   The runtime registry references ...\chrome\latest\scripts\browser-client.mjs and
   browser-service.mjs, but codex plugin add only copies files and creates no junction,
   and no plugin directory on this machine ever had a latest entry. After an update the
   junction also goes stale. Creating it by hand makes those paths resolve.

2. The Edge NativeMessagingHosts registry root is never written.
   installManifest.mjs registers only HKCU\Software\Google\Chrome\NativeMessagingHosts,
   but Edge reads HKCU\Software\Microsoft\Edge\NativeMessagingHosts. With the extension
   installed and enabled in Edge, it could never reach the native host. Adding the Edge key
   made Edge spawn extension-host.exe on launch. For comparison, another vendor's
   extension on this machine registers under both roots.

3. codex plugin remove/add does no wiring.
   It does not create latest, does not write extension-host-config.json, does not touch
   the manifest, and does not refresh the runtime registry. Worth documenting, because
   docs/chrome-troubleshooting.md tells users to reinstall the Browser plugin - but the
   app UI reinstall did not refresh the registry either.

4. A symlinked CODEX_HOME breaks .mjs MCP servers.
   With C:\Users\<user>\.codex symlinked to D:\Codex\.codex, Node resolves
   import.meta.url to the real path (file:///D:/...) while
   pathToFileURL(process.argv[1]) keeps file:///C:/.... The common main-module guard

   if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) await runStdio();
   

   is therefore never true, the server exits 0 without serving, and Codex reports
   MCP server startup failed: connection closed: initialize response. Resolving the
   configured path through the symlink, or comparing real paths, would avoid this.

Elimination tests (both negative) - please do not re-suggest these

A stale runtime registry is NOT the (only) cause of the Computer Use block

To rule out the stale registry, chrome-native-hosts-v2.json was rewritten by hand with
fully valid, live values, taken from the app's own log line
browser_use_runtime_paths_selected:

appVersion / cliVersion / nativeHostVersion = 26.1007.71326
presence.pid       = the live desktop app main process (verified ALIVE)
presence.*         = current timestamps
codexCliPath       = ...\OpenAI\Codex\bin\9614f1d9b40d9c4f\codex.exe
nodePath           = ...\runtimes\cua_node\a9ba6825a525118c\bin\node.exe
nodeReplPath       = ...\runtimes\cua_node\a9ba6825a525118c\bin\node_repl.exe
nodeModuleDirs[0]  = ...\runtimes\cua_node\a9ba6825a525118c\bin\node_modules
extensionHostPath  = <current 26.1007.9446.0 package>\...\extension-host.exe
browserClientPath  = ...\browser\26.1007.71326\scripts\browser-client.mjs
browserServicePath = ...\browser\26.1007.71326\scripts\browser-service.mjs

All nine paths were verified to resolve, and the pid was verified alive at test time.
Chrome and Edge were then both fully restarted, and three extension-host.exe processes
spawned and stayed alive.

Computer Use still fails with the identical error. So the browser URL cannot be
determined even with a valid, live registry entry and a working native-messaging
transport. Something else in the URL-determination path is failing.

(Note: the registry has since been restored to the original app-written content, so the
machine reflects the real defect rather than the synthetic test entry.)

The "keep the pane bound to an existing conversation" workaround does NOT fix iab

Derived from ownerRoutePath in the logs, the sidebar owner follows whatever page the
window is currently displaying:

ownerRoutePath=/local/01a137a8-...        -> route bound to that conversation
ownerRoutePath=/settings/plugins-settings -> route rebound to a client-new-thread draft
ownerRoutePath=/settings/browser-use      -> route rebound to a client-new-thread draft
ownerRoutePath=/                          -> route rebound to a client-new-thread draft

So the test was repeated in an existing conversation, in a single window, without ever
opening a new chat or a settings page, with a real page loaded in the pane first.

agent.browsers.get("iab") still returns Browser is not available: iab.

What would help

• Issue 1: do not let a client-new-thread: draft take the browser route away from a
  conversation that is requesting it, or expose a way to pin the pane to the active
  conversation.
• Issue 2: make the desktop app rewrite chrome-native-hosts-v2.json on startup, and
  at minimum when the file is missing or when its extensionHostPath no longer resolves
  after an app update. Note from the elimination test above that this alone is unlikely to
  be sufficient for the Computer Use URL check - that path appears to have a second defect.
• Diagnostics: the URL-determination failure in url_policy.rs reports only
  "could not determine ... with enough confidence". Logging which source was consulted
  (extension channel, UI Automation, CDP) and why it was rejected would make this
  self-serviceable.