shell_command returns "unsupported call" after app update

same issue

Adding a repro for what looks like the same failure class, but on macOS + CLI (not the desktop app) and with a different tool name: exec_command instead of shell.

Environment

• codex-cli 0.143.0 (confirmed latest — codex update reinstalls 0.143.0)
• macOS (arm64), installed via the official install.sh
• Model: gpt-5.5 (the current default; no -m flag)
• codex exec, --sandbox workspace-write

Symptom

Every tool call the model makes is rejected by the local tool router:

ERROR codex_core::tools::router: error=unsupported call: exec_commandexec_command
ERROR codex_core::tools::router: error=unsupported custom tool call: apply_patchapply_patch
ERROR codex_core::tools::router: error=unsupported call: list_mcp_resourceslist_mcp_resources

(Note the tool name is printed twice in the error line — a small log-formatting
quirk, but it's verbatim and stable across runs.)

The model retries a few times (2–3 in single-run probes; more under longer
agentic prompts), then gives up and answers in text that it couldn't run the
command — exact wording varies per run ("the shell tool failed…", "the
terminal tool failed…"). Notably, codex exec still exits 0, so in
scripted/CI usage this fails silently — the session "completes" having done
no work.

Minimal repro

mkdir /tmp/codex-probe && cd /tmp/codex-probe && echo hello > probe.txt
codex exec --sandbox workspace-write --skip-git-repo-check \
  "run ls and cat probe.txt, then tell me the file content"
# -> 3x "unsupported call: exec_command", model reports it cannot run commands

Workaround

Pinning the previous model works perfectly with the same CLI/binary and the same prompt:

codex exec -m gpt-5.4 --sandbox workspace-write --skip-git-repo-check \
  "run ls and cat probe.txt, then tell me the file content"
# -> reads the file, returns "hello"

So this doesn't look like a stale-client issue: the newest available CLI (0.143.0) doesn't recognize the tool names gpt-5.5 emits (exec_command / apply_patch / list_mcp_resources), while gpt-5.4 emits the older tool set and works. It seems the server is handing the model a toolset the client never advertised.

Two smaller notes from the same session, in case they help triage:

• On a cold start with 6 parallel codex exec processes, ~/.codex/models_cache.json ended up empty and logged failed to load models cache: EOF while parsing a value at line 1 column 0 (possible concurrent-write race; it healed on the next run and is unrelated to the router error, which reproduces single-run with a warm cache).
• A non-tool prompt ("reply with exactly: ok") works fine on gpt-5.5 — only tool calls are affected.