Browser and Chrome plugins unavailable with gpt-5.6-sol but work with gpt-5.6-terra
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 thatnode_replMCP is unavailable.gpt-5.6-terra: performs a realnode_replMCP 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?
- Install and enable the bundled Browser or Chrome plugin.
- Confirm that the
node_replMCP server is enabled. - Start a fresh Codex task using
gpt-5.6-sol. - Ask the task to use Browser or explicitly call
node_repl. - Observe that the tool is unavailable even though the Browser backend starts successfully.
- Run the equivalent request in a fresh task or ephemeral CLI session using
gpt-5.6-terra. - Observe that
node_replis 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.
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I had the same problem and the workaround works.
Same problem with every single tool call
Independent macOS confirmation from a controlled same-machine test today.
Environment:
26.707.91948browser@openai-bundledI created fresh tasks and used the same Browser smoke test each time:
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.comand read page state. || GPT-5.5 | Passed. Opened
example.comand read page state. || GPT-5.6-Terra | Passed. Opened
example.comand read page state. || GPT-5.6-Luna | Passed. Opened
example.comand 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.
Independent Windows confirmation on a current Desktop build.
Environment:
26.727.4816.026.721.31836gpt-5.6-solObserved behavior:
scripts/browser-client.mjsis present, and the plugin cache was verified complete at 376 files against the same-version bundled source.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.