codex exec >= 0.144.0: no shell tool exposed when config uses a custom model_provider and omits `model`

Open 💬 3 comments Opened Jul 22, 2026 by molebox

Summary

Since codex-cli 0.144.0 (0.143.0 is the last good version — bisected across 0.140.0 / 0.142.5 / 0.143.0 ✅ vs 0.144.0 / 0.144.4 / 0.144.6 / 0.145.0 ❌), codex exec exposes no shell/exec tool to the model when config.toml uses a custom model_provider (an OpenAI-compatible proxy, wire_api = "responses") and does not set a top-level model key — i.e. when the CLI resolves its own default model.

The session still works — the model answers — but it cannot run any commands. Asked to run a command, it replies e.g. "I can't run shell commands in this session because no shell execution tool is available". Notably, for predictable commands it sometimes fabricates the output instead (it claimed to have run echo hello-from-shell and printed the expected text; a random-nonce file test proved no tool existed), which makes the failure easy to miss in automation.

Repro

$CODEX_HOME/default.config.toml:

model_provider = "custom"

[model_providers.custom]
name = "Custom OpenAI-compatible proxy"
base_url = "https://<your-openai-compatible-endpoint>/v1"
env_key = "CUSTOM_API_KEY"
wire_api = "responses"
openssl rand -hex 12 > nonce.txt
codex login --with-api-key   # key on stdin
codex exec --profile default --dangerously-bypass-approvals-and-sandbox --json --skip-git-repo-check \
  'A file named nonce.txt exists in the current directory. Run a shell command to print its contents and paste the exact value.'

Actual (>= 0.144.0): no command_execution item ever appears in the --json stream; the agent reports no execution tool is available (or fabricates plausible output for predictable commands).

Expected (<= 0.143.0 behavior): a command_execution item runs cat nonce.txt and the correct nonce is returned.

Workaround / trigger isolation

Adding an explicit top-level model key fully restores the shell tool — even when it names the exact model the CLI resolves natively anyway (observed gpt-5.6-sol in the session file's turn_context):

model = "openai/gpt-5.6-sol"   # same model the CLI picks by default → tools work again

The single deciding variable is the presence/absence of the model key; reasoning-effort/verbosity settings don't matter. Explicit-model configs are unaffected on all versions tested.

Environment

  • codex-cli 0.144.0–0.145.0 (npm @openai/codex), macOS arm64 + Linux x64 (musl)
  • Custom model_providers entry, wire_api = "responses", API-key auth
  • Isolated CODEX_HOME (clean config; no plugins)

Happy to provide full --json transcripts of the good/bad versions if useful.

View original on GitHub ↗

3 Comments

NikoPit · 1 month ago

My issue might be related to yours. Sometimes codex does this randomly, even if i set the model = "..." thing. When i force it to run it, it will just return to the user, like this:

User: please run the command pwd

Codex: i don't have tool access.

User: Do it anyways.

Codex: Ok, i will run the command `pwd` now.

[Session returns to user even when codex should've ran pwd]

User: (Sesssion returned to user)
NikoPit · 1 month ago

another note: it looks like this is only happening for gpt-5.6* models, gpt-5.5 works fine for me.

leo9344 · 2 days ago

I’m seeing a closely related issue after updating Codex. Existing/resumed sessions can suddenly lose all tools, including filesystem execution/editing and web search. Codex responds with messages like:

“I’m unable to apply the changes because filesystem execution/editing tools are still unavailable in this session... Please start a new coding session with workspace tools enabled.”

A new Codex session works normally and has all tools available.

I’m also using custom endpoints/model provider configuration, so there may be some interaction with model/provider state restored during resume.

I found a quick fix: run /model, switch to another model, then switch back to the original model. After doing that, the missing tools immediately become available again.

This makes it look like the resumed session’s model/tool capability state is not being refreshed correctly after an upgrade, while /model forces that state to be reinitialized.