Chrome plugin trusted bridge unavailable after macOS sleep/wake and Codex restart

[kevivnag]

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

26.506.31421 (2620)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

After closing the laptop lid and waking it, an existing heartbeat automation using @chrome stopped being able to control Chrome. The Chrome extension and native host still look healthy, but the trusted Chrome browser-control bridge is no longer exposed to the Codex runtime.

Expected:
Chrome heartbeat automation can call Chrome plugin browser APIs after sleep/wake or after restarting Codex.

Actual:
The automation cannot call browser.user.openTabs()/claimTab(). Chrome-side checks pass, but the trusted bridge is missing.

Evidence:

• Chrome running: true
• Codex Chrome Extension installed/enabled: true
• Extension version: 1.1.4_0
• Native host manifest exists and is correct
• codex mcp list exposes only computer-use and central_confluence
• Plain node browser-client attempt fails with:
  privileged native pipe bridge is not available; browser-client is not trusted

Trigger:
Laptop lid close / macOS sleep, then wake. Restarting Codex did not restore the bridge in the existing thread/runtime.

Impact:
Recurring Chrome heartbeat automations silently stop being able to interact with existing authenticated Chrome tabs.

What steps can reproduce the bug?

Start Codex Desktop with the Chrome plugin installed and enabled.
Create or use a heartbeat automation that explicitly uses @chrome, for example one that calls existing Chrome tabs every 10 minutes.
Confirm it works once: the automation can access existing Chrome tabs through the Chrome plugin.
Leave Chrome running.
Close the laptop lid so macOS sleeps.
Reopen the laptop and unlock it.
Let the next heartbeat run, or manually trigger/use the same @chrome workflow.
Observe that Chrome automation fails because the trusted Chrome bridge is no longer available.
Restart Codex Desktop.
In the same existing thread/runtime, retry the Chrome-backed automation.
Observe that the bridge may still be unavailable even though Chrome, the extension, and native host checks pass.

What is the expected behavior?

Expected: after wake, or at least after restarting Codex, the Chrome plugin bridge reconnects and @chrome can call browser APIs like openTabs() / claimTab().

Actual observed here: Chrome is running, the extension is installed/enabled, the native host manifest is correct, but the trusted browser-control bridge is not exposed to the runtime. The plain-node attempt fails with:
privileged native pipe bridge is not available; browser-client is not trusted

Additional information

Useful verification commands:
codex mcp list node ~/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/chrome-is-running.js --json node ~/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/check-extension-installed.js --json node ~/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/check-native-host-manifest.js --json

[m13v]

scenario: native messaging host has a long-lived stdio pipe to a chrome extension, laptop sleeps, darwin tears down the pipe but the extension's port object stays alive on the chrome side. on wake, chrome thinks the port is fine, the host process either died with SIGPIPE or is sitting on a dead fd, and the trusted-bridge handshake never gets re-issued. the bridge availability check is usually a cached boolean from boot, so codex restart alone won't help unless the restart path tears down and re-spawns the native host, not just reconnects to the existing one. worth checking if ps aux | grep chrome_native_host shows a stale pid after wake, that's usually the tell.