[CLI] All tools become unavailable after resuming a pre-upgrade session; `/model` restores them

[leo9344]

What version of Codex CLI is running?

0.149.0 and 0.149.1

What subscription do you have?

Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux x86_64

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

After upgrading Codex CLI from 0.149.0 to 0.149.1, resuming an existing session created before the upgrade can result in all tools becoming unavailable.

This includes:

• shell / command execution
• filesystem reading/editing
• patch/application tools
• web search
• other normally available tools

The model may respond with messages such as:

I’m unable to apply the changes because filesystem execution/editing tools are still unavailable in this session. No files have been modified. Please start a new coding session with workspace tools enabled; the current session cannot perform repository edits.

This is not only a filesystem or sandbox issue. Web search is unavailable as well.

A completely new Codex session created after the upgrade works normally with the same installation and configuration.

I am also using a custom Responses-compatible endpoint/model provider configuration.

The interesting part is that I found a reliable workaround:

1. Run /model.
2. Switch from the current model to another model.
3. Switch back to the original model.

After doing this, all tools immediately become available again, including filesystem editing, shell execution, and web search.

For example:

0.149.0 + existing gpt-5.6-sol session
    -> tools work

upgrade to 0.149.1

0.149.1 + resume same session/model
    -> all tools unavailable

new 0.149.1 session
    -> tools work

/model: gpt-5.6-sol -> gpt-5.6-terra
    -> tools immediately work

/model: gpt-5.6-terra -> gpt-5.6-sol
    -> tools continue to work

Changing sandbox settings, including workspace-write, did not restore the tools.

In at least some affected sessions, /status also does not show the normal Sandbox: entry.

I have also observed that using /fork from an affected old session can preserve the same tool-less state.

What steps can reproduce the bug?

Environment used in my reproduction:

Codex CLI before upgrade: 0.149.0
Codex CLI after upgrade:  0.149.1

Affected model: gpt-5.6-sol
Control model:  gpt-5.6-terra

Platform: Linux x86_64
Endpoint: custom Responses-compatible endpoint

Steps:

1. Install/run Codex CLI 0.149.0.

2. Start a new session using gpt-5.6-sol through the custom endpoint.

3. Verify that normal tools are available, for example:

   • run a shell command;
   • edit/read a repository file;
   • use web search.

4. Exit the Codex session normally.

5. Upgrade Codex CLI from 0.149.0 to 0.149.1.

6. Resume the old session:

   codex resume <session-id>

7. Ask Codex to perform a task that requires a tool, such as:

   • run pwd;
   • modify a file;
   • search the web.

8. Observe that no tool call is made and Codex reports that the tools are unavailable.

9. Run /status.

   In the affected session, the normal Sandbox: entry may also be absent.

10. Try changing sandbox configuration, including workspace-write.

11. Observe that this does not restore tool use.

12. Start a completely new session with Codex CLI 0.149.1.

13. Observe that shell/filesystem/web tools work normally in the new session.

14. Return to the broken resumed session.

15. Run:

/model

16. Switch from:

gpt-5.6-sol

to:

gpt-5.6-terra

17. Repeat the tool-requiring task.

18. Observe that tools work immediately.

19. Run /model again and switch back to:

gpt-5.6-sol

20. Repeat the same tool-requiring task.

21. Observe that tools continue to work on the original model.

I have also seen the affected state carry over when forking from the old session.

What is the expected behavior?

Resuming or forking a session created by an older Codex CLI version should initialize the current runtime and current tool configuration correctly.

The current session should have the same expected tool surface as a newly created session using the same CLI version, model, endpoint, and configuration.

A user should not need to perform an artificial model switch in order to restore:

• filesystem tools
• shell execution
• editing tools
• web search
• other model-visible tools

If the current Codex version has changed model instructions, tool definitions, schemas, or runtime metadata since the session was originally created, the resume path should refresh or rebuild that state automatically.

Additional information

The /model workaround makes me suspect that this is related to model/runtime/tool state rehydration during resume, rather than the tools themselves being broken.

The most important observation is:

same original model restored through resume
    -> tools unavailable

same original model reached after /model switch
    -> tools available

This suggests that the original model itself is capable of using the tools, but the resumed session may not be receiving or rebuilding the same runtime/tool context as a fresh session.

One possible root-cause hypothesis is that persisted model state is considered unchanged when the model slug is unchanged, even though the newer CLI may have changed:

• generated model/developer instructions;
• model-visible tool definitions;
• tool schemas;
• tool-selection/runtime metadata.

If no refresh is emitted during resume, the model may continue with stale or incomplete historical runtime context.

A real /model transition appears to force enough model/runtime state to be refreshed that the tools become usable again.

This is only a hypothesis; I have not confirmed the exact internal state that /model refreshes.

Possible fix direction

On the first turn after resuming or forking a non-empty history, Codex could verify that persisted runtime/model state is compatible with the current CLI runtime.

If model-visible runtime state has changed, Codex could force a bounded refresh or rebuild of the current model/tool context.

For example, compatibility could take into account more than only the model slug, such as:

model slug
+ model instruction version/digest
+ model-visible tool specification version/digest

The important behavior is that upgrading Codex should not leave a resumed thread with stale tool/runtime context merely because the model name itself has not changed.

Endpoint URLs, credentials, session identifiers, and request contents have been removed from this report.

Related issues

• codex exec >= 0.144.0: no shell tool exposed when config uses a custom model_provider and omits model #34758 appears closely related at the model/tool-resolution layer. In that issue, a custom model_provider could result in missing execution tools when Codex implicitly resolved the model, while explicitly selecting the same effective model restored tool availability. My trigger is different because it happens after a CLI upgrade and session resume, but the fact that an explicit model transition repairs the tool surface looks related.

• Older resumed Codex Desktop threads can miss newly available tools and may stay on legacy subagent runtime #25990 also appears related from the persisted-thread/runtime-state side, since it describes older threads missing newer tool capabilities.

• [CLI 0.147.0 regression] gpt-5.6-sol sends tools: [] with a custom Responses provider #37410

• Regression in 0.147.0: upgrade leaves all tools unavailable with existing code_mode_host=false #37376

I would not assume these necessarily have the exact same root cause, but they appear to involve the same general area: persisted or implicitly resolved model state affecting the model-visible tool surface.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• shell execution and other tools gone after update #41145

Powered by Codex Action

[leo9344]

This issue seems to be resolved. I just updated codex-cli (Linux x86_64) from version 0.150 to 0.152.1 using a custom endpoint. It can now successfully resume previous sessions with all tools enabled. I’ll keep monitoring it and post any updates here.

[XhinLiang]

Additional reproduction on macOS arm64, using a custom Responses-compatible endpoint:

• The session was last working under Codex CLI/TUI 0.152.1. In the last successful long turn (session 01a0616e-e171-75e1-8f6e-664606fedc9c, turn 01a06327-5bd3-7fa3-aaae-43f324b8e3d6), the rollout contains 49 custom_tool_call items and 49 matching custom_tool_call_output items.
• After resuming the same session under 0.153.0 with model gpt-5.6-sol, API-key auth, and the same custom endpoint, the first resumed turn (turn 01a06544-4928-7112-98fb-87cf5b309ee2) contained 0 custom_tool_call, 0 function_call, and 0 tool outputs. The assistant instead emitted literal text such as to=functions.exec code: rather than a tool-call item.
• The same happened on subsequent turns asking it to run/check commands. A fresh 0.153.0 session on the same machine and configuration can still execute tools.

Observed local app-server logs at resume also showed a model-cache mismatch: expected 0.153.0, cached 0.151.0, followed by “no usable cache entry”. The authentication mode had changed from ChatGPT to API key/custom endpoint before this resume, so that is a possible confounder.

The session rollout JSONL does not persist the raw Responses request body, so I cannot prove that the wire-level field was literally tools: []; the effective model-visible tool surface is zero based on the recorded output item types. No tool command was actually dispatched after the failure (including attempted deployment commands).

Expected behavior: resuming an existing session should reconstruct the current tool/runtime state and expose the same tool surface as a fresh session, without requiring a model switch. This looks like a useful regression check for the session-resume/tool-state rehydration path.

[leo9344]

@XhinLiang Have you tried switching to another model and then switching back? This fixes the issue on my Linux server but I am wondering if it works on macOS.

[XhinLiang]

@XhinLiang Have you tried switching to another model and then switching back? This fixes the issue on my Linux server but I am wondering if it works on macOS.

works sometimes