Codex Desktop Windows: Chrome plugin connects but navigation blocked because thread networkAccess persists as false

What version of the Codex App are you using?

Unknown from the UI during this debugging session. Local runtime/plugin evidence:

• chrome@openai-bundled version present locally: 0.1.7
• Codex primary runtime bundle present locally: 26.423.10653
• Chrome extension version detected: 1.1.4_0

What platform is your computer?

Windows, x64.

What issue are you seeing?

chrome@openai-bundled is installed and enabled, and the Codex Chrome Extension can communicate with the app well enough to list live Chrome tabs. However, browser navigation through the Chrome plugin is blocked before page load because the thread sandbox policy keeps networkAccess: false.

This makes the Chrome plugin effectively unusable for website navigation, even when the browser origin allowlist contains the requested domains.

Observed behavior:

• chrome@openai-bundled is enabled in Codex config.
• The Chrome extension backend successfully returns open Chrome tabs via the plugin runtime, so the extension path is not completely unavailable.
• Attempting to navigate a Chrome-controlled tab to https://www.cnbc.com/ is rejected before load with a browser security policy message.
• Attempting to navigate to a neutral URL, https://example.com/, is also rejected before load with the same class of policy message.
• Local browser config contains allowed origins, including https://www.cnbc.com, but the per-thread permission state still has sandboxPolicy.networkAccess: false, which appears to override the allowlist.
• Manually changing the persisted state has not been reliable; the value appears to be restored or rehydrated as false for the thread.

Evidence collected

Chrome plugin config:

[plugins."chrome@openai-bundled"]
enabled = true

[plugins."browser-use@openai-bundled"]
enabled = true

Browser allowlist config:

[origins]
allowed = ["https://lite.cnn.com", "https://www.cnbc.com"]

Per-thread persisted permission state contains:

"sandboxPolicy": {
  "type": "workspaceWrite",
  "networkAccess": false
}

Chrome extension check reports installed and enabled:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "installed": true,
  "registered": true,
  "enabled": true,
  "disabled": false,
  "versions": ["1.1.4_0"]
}

Native host manifest check also reports a setup problem:

Windows native host registry key does not exist:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

However, the immediate navigation failure happens as a browser security policy rejection tied to network access, not as a page load failure.

Steps to reproduce

1. On Windows, enable/install chrome@openai-bundled and the Codex Chrome Extension.
2. Start a new Codex Desktop thread in a workspace where the per-thread sandbox state has networkAccess: false.
3. Ask Codex: [@chrome](plugin://chrome@openai-bundled) go to cnbc.com.
4. Observe that the Chrome extension backend can be reached and can list live Chrome tabs.
5. Attempt to navigate to https://www.cnbc.com/ or https://example.com/ through the Chrome plugin.
6. Navigation is rejected before page load by browser security policy.

Expected behavior

If the user explicitly invokes @chrome to navigate to a website, and the Chrome plugin/extension is installed and enabled, Codex Desktop should either:

• request/enable the appropriate thread network permission,
• honor the browser origin allowlist, or
• expose a clear UI state explaining that network access is disabled and how to enable it.

The app should not silently initialize or rehydrate the thread with networkAccess: false in a way that makes the Chrome plugin unusable.

Actual behavior

The Chrome plugin is available enough to communicate with the extension, but navigation is blocked because the thread-level sandbox policy remains networkAccess: false. The user cannot find an obvious UI control to fix this in Codex Desktop on Windows.

Additional notes

This may be a permission propagation/rehydration issue in Codex Desktop on Windows: plugin config and browser allowlist are enabled, but per-thread sandbox policy overrides them and persists network-disabled state.