GPT-5.6 models get no tools in read-only sandbox (codex exec -s read-only says it has no shell/file tools)

Resolved 💬 4 comments Opened Jul 9, 2026 by TaylorAdamCA Closed Jul 10, 2026

What version of Codex is running?

codex-cli 0.144.0 (also reproduced on 0.143.0; pre-5.6 behavior verified on 0.137.0)

What platform is your computer?

macOS (Darwin 25.5.0, arm64)

What steps can reproduce the bug?

With any GPT-5.6 model selected, codex exec -s read-only sessions are provisioned with no tools at all — the model reports it has no shell or file-reading tool and cannot inspect the repo:

$ codex exec -s read-only -m gpt-5.6-sol "Run the shell command \`echo tool-check-ok\` and report its exact output. If you have no shell tool available, say NO-TOOLS."
NO-TOOLS

Reproduction matrix (all from the same machine/auth, same working directory):

| model | sandbox | result |
|---|---|---|
| gpt-5.6-sol | read-only | ❌ NO-TOOLS |
| gpt-5.6-terra | read-only | ❌ NO-TOOLS |
| gpt-5.6-sol | read-only + -c 'sandbox_permissions=["disk-full-read-access"]' | ❌ NO-TOOLS |
| gpt-5.6-sol | workspace-write | ✅ runs echo, returns output |
| gpt-5.5 | read-only | ✅ runs echo, returns output |

CLI version is not the variable: identical results on 0.143.0 and 0.144.0. gpt-5.5 + read-only worked on 0.137.0 earlier the same day and still works on 0.144.0.

In interactive sessions the model describes it as: "This session includes the repo path and filesystem permissions in its context, but no terminal or file-reading tool was actually provisioned to me."

What is the expected behavior?

Read-only sandbox sessions should provision the shell/file tools (with read-only enforcement), as they do for gpt-5.5.

What do you see instead?

GPT-5.6 sessions in read-only sandbox receive no tool bundle at all, so any read-only automation (codex exec -s read-only ..., review flows) silently degrades to a no-tool chat.

Additional information

Auth: ChatGPT login (Plus/Pro plan), model_provider is the local codex-lb (http://127.0.0.1:2455/backend-api/codex) provided by the ChatGPT desktop app — so this may be backend/rollout-side rather than CLI-side. Filed within hours of the GPT-5.6 GA rollout announcement.
Workaround: pass -m gpt-5.5 for read-only runs, or use -s workspace-write.

View original on GitHub ↗

4 Comments

TaylorAdamCA · 1 month ago

Additional finding: this is not limited to read-only. danger-full-access is also affected — on GPT-5.6 models, tools provision only under workspace-write:

| model | sandbox | result |
|---|---|---|
| gpt-5.6-sol | read-only | ❌ NO-TOOLS |
| gpt-5.6-sol | danger-full-access | ❌ NO-TOOLS |
| gpt-5.6-sol | workspace-write | ✅ tools work |
| gpt-5.5 | read-only | ✅ tools work |

This means the macOS desktop app's Full Access mode also produces tool-less GPT-5.6 sessions (app bundles codex-cli 0.144.0-alpha.4; reproduced identically with npm codex-cli 0.144.0). Workaround for desktop users: use Agent mode or a Custom mode based on workspace-write instead of Full Access.

sjamesc · 1 month ago

Looks to be related to the model_provider you mentioned, I'm having same issue routing via. codex-lb. See: https://github.com/Soju06/codex-lb/issues/1157

TaylorAdamCA · 1 month ago

Update after more testing (~1h later): the pattern is less clean than my earlier matrix suggested — provisioning on GPT-5.6 now appears flaky/rollout-dependent rather than strictly sandbox-keyed. With identical config (custom permission profile extending :workspace, gpt-5.6-sol), consecutive codex exec runs minutes apart gave: (1) tools working (echo executed), (2) tools working in-session — but see below, (3) no tools at all ("shell/file tools were unavailable in this session").

Separate observation from run (2): the session had tools and reported successfully writing and reading back a file under a profile-declared extra workspace root (~/Downloads, declared via [permissions.<name>.workspace_roots]), but the file never appeared on the real filesystem — no error surfaced to the model, which then reported success. If out-of-workspace writes land in an ephemeral scratch layer, the model can't tell the user's disk was never touched; a hard denial would be safer than a phantom success.

Reliable interim behavior for us remains: gpt-5.5 provisions tools consistently in every sandbox mode.

TaylorAdamCA · 1 month ago

Closing — root cause turned out to be outside codex. My setup (and, per the thread, several others') routes through the codex-lb proxy, whose v1.20.1 mishandles GPT-5.6's Responses Lite requests: its input normalization drops the additional_tools input item, and it strips the responses-lite marker before forwarding — so the model never receives its tool bundle and reports having no shell/file tools. That also explains the flakiness (HTTP vs websocket paths differ) and the phantom-write behavior I reported.

Fixed upstream in Soju06/codex-lb#1161, released in codex-lb v1.21.0-beta.1 (uvx codex-lb==1.21.0b1). Verified locally on the beta: gpt-5.6-sol provisions tools consistently across sandbox modes, and out-of-workspace writes land on the real filesystem again.

If you're hitting this WITHOUT codex-lb (or a similar proxy) in the path, it's likely a different issue — codex-cli 0.144.0 talking directly to the backend was not the problem here.