Browser and Chrome plugins unavailable with gpt-5.6-sol but work with gpt-5.6-terra

Open 💬 5 comments Opened Jul 16, 2026 by gentiku
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

ChatGPT/Codex desktop app 26.707.91948, bundled Codex CLI 0.144.5.

What subscription do you have?

ChatGPT subscription. The exact tier is not displayed in the Codex diagnostics.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Browser and Chrome control stopped being exposed in new Codex tasks using gpt-5.6-sol.

The Browser and Chrome plugins and the node_repl MCP server were installed and enabled. The in-app Browser backend started successfully and its socket became ready, but tasks using gpt-5.6-sol reported that the browser-control or node_repl runtime was unavailable.

Local health checks passed for configuration, authentication, MCP setup, network connectivity, plugin installation, and the Browser backend. Restarting the app and reinstalling or re-enabling plugins did not help.

A controlled A/B test showed model-specific behavior:

  • gpt-5.6-sol: reports that node_repl MCP is unavailable.
  • gpt-5.6-terra: performs a real node_repl MCP call successfully.

The current model catalog marks gpt-5.6-sol as tool_mode=direct and gpt-5.6-terra as tool_mode=code_mode_only. Switching the default model to Terra and starting a fresh task immediately restored Browser control.

What steps can reproduce the bug?

  1. Install and enable the bundled Browser or Chrome plugin.
  2. Confirm that the node_repl MCP server is enabled.
  3. Start a fresh Codex task using gpt-5.6-sol.
  4. Ask the task to use Browser or explicitly call node_repl.
  5. Observe that the tool is unavailable even though the Browser backend starts successfully.
  6. Run the equivalent request in a fresh task or ephemeral CLI session using gpt-5.6-terra.
  7. Observe that node_repl is exposed and Browser control works.

The last confirmed working Browser call using Sol was July 15, 2026 at 21:46 Europe/Berlin. The first task already missing the code-mode bridge was July 16 at 11:19, before any local plugin cleanup or configuration changes.

Private feedback was also submitted through /feedback without logs. Feedback thread ID: 019f6b08-b264-7e13-adc0-1d9f2dcbd49a.

What is the expected behavior?

Browser, Chrome, and Computer Use plugins should remain callable with gpt-5.6-sol. If this is an intentional model limitation, the model selector or plugin UI should communicate it clearly instead of showing the plugins as installed and healthy but unreachable.

Additional information

Changing only the default model from Sol to Terra is a reliable workaround. No secrets, logs, local paths, or private task content are included in this public report.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33575
  • #33547
  • #33585

Powered by Codex Action

TouriM · 1 month ago

I had the same problem and the workaround works.

yeaight7 · 1 month ago

Same problem with every single tool call

bhighb · 1 month ago

Independent macOS confirmation from a controlled same-machine test today.

Environment:

  • ChatGPT/Codex desktop app: 26.707.91948
  • Platform: macOS desktop app
  • Browser plugin: browser@openai-bundled

I created fresh tasks and used the same Browser smoke test each time:

@Browser — Open https://example.com and tell me the page title.

Results:

| Model | Result |
|---|---|
| GPT-5.6-Sol | Failed twice. The Browser skill/package was visible, but the live Browser control action/connection was not exposed, so it could not open or inspect the page. |
| GPT-5.4 | Passed. Opened example.com and read page state. |
| GPT-5.5 | Passed. Opened example.com and read page state. |
| GPT-5.6-Terra | Passed. Opened example.com and read page state. |
| GPT-5.6-Luna | Passed. Opened example.com and read page state. |

There were no changes to the Mac, app version, Browser plugin, or test prompt between runs. This looks model-specific: Sol tasks are not being provisioned with the Browser plugin's required dynamic control bridge, rather than the Browser plugin being unavailable or misconfigured.

Barry-886 · 27 days ago

Independent Windows confirmation on a current Desktop build.

Environment:

  • Codex Desktop AppX: 26.727.4816.0
  • Chrome plugin: 26.721.31836
  • Model: gpt-5.6-sol
  • Platform: Windows x64

Observed behavior:

  • The Chrome plugin is installed and enabled.
  • Its skill is visible in the task, scripts/browser-client.mjs is present, and the plugin cache was verified complete at 376 files against the same-version bundled source.
  • Both an existing Codex task and a completely new task created after repair lacked the callable Chrome control bridge. The required JavaScript control tool was absent, and no tool-discovery entry capable of exposing it was available.
  • Fully restarting Desktop, disabling/re-enabling the plugin, and rebuilding the plugin cache did not change the result.
  • No Chrome action was attempted and no website state was modified.

I have not yet run the Terra side of the A/B test, but the Sol-side symptom matches this issue exactly on Windows and on a newer app/plugin build.