openai / openai/codex

0.150.1 regression: sessions provisioned without shell tool (code-mode harness only exposes apply_patch + MCP); 0.149.1 works

Open
#41,099 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug CLI tool-calls
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

What happened

After auto-updating to codex-cli 0.150.1 (macOS arm64, standalone install), every new session — TUI and codex exec — is provisioned without any local shell / file-read tools. The model only receives the code-mode JS exec harness exposing apply_patch, image_gen, and MCP tools; shell_command / exec_command are absent from the tool list entirely.

The model can chat normally but cannot run even ls or git status, replying e.g.:

但当前会话没有可用的本地文件/终端读取工具 …
("the current session has no local file/terminal tools available")

Asking the model to dump its available tool names from inside the exec harness confirms the provisioning gap — the full list contains only apply_patch, create_goal, get_goal, image_gen__imagegen, list_mcp_resources, MCP tools, etc. No shell tool.

A/B isolation (same machine, same account, same enterprise policy)

codex-cli model force flags shell tool
0.150.1 default (gpt-5.6) ❌ absent
0.150.1 gpt-5.5 (-m gpt-5.5) ❌ absent
0.150.1 default -c features.shell_tool=true -c features.unified_exec=true ❌ absent
0.149.1 (GitHub release rust-v0.149.1) default ✅ works, executes commands normally

So this is not local config, sandbox mode, trust level, model choice, or feature flags — pinning the CLI back to 0.149.1 with everything else identical restores shell execution.

Timeline detail that may help: on the same day, one early 0.150.1 session did still get shell_command, and sessions a few hours later did not — so a server-side provisioning component interacting with the 0.150.1 client may be involved.

Environment

  • codex-cli 0.150.1 (broken) vs 0.149.1 (works), standalone auto-updated install
  • macOS 15 (Darwin 25.5.0), Apple Silicon
  • sandbox_mode = "workspace-write", approval_policy = "on-request", project trusted
  • ChatGPT Enterprise account with managed requirements (verified not the cause: 0.149.1 works under the same policy)
  • Reproduces headlessly: codex exec "run ls; if you have no shell tool reply NO_SHELL_TOOL"NO_SHELL_TOOL

Expected

New sessions on 0.150.1 should provision the local shell tool exactly as 0.149.1 does.

Workaround

Repoint ~/.codex/packages/standalone/current to the retained 0.149.1-aarch64-apple-darwin release and set features.in_app_updates = false.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the headless codex exec reproduction and compare tool provisioning between 0.150.1 and 0.149.1, using the standalone release path at ~/.codex/packages/standalone/current. Check whether the feature flags and session modes affect the result. Done means new TUI and codex exec sessions expose the local shell tool as they do in 0.149.1.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, shell
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.