GPT-5.6-Sol lost access to create_thread tool after update

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.91948

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

This is a regression that appeared after updating Codex Desktop from the build using bundled app-server/CLI 0.144.2 to Codex App 26.707.91948, which bundles codex-cli 0.144.5, and then relaunching the app.

Before the update, on the same machine, GPT-5.6-Sol could discover and invoke the first-party Codex Desktop thread-management tools, including:

• codex_app.create_thread
• codex_app.fork_thread
• codex_app.list_threads
• codex_app.read_thread
• codex_app.send_message_to_thread
• codex_app.set_thread_title
• codex_app.set_thread_archived

After updating and relaunching, these tools became unreachable when using GPT-5.6-Sol.

The tools have not been removed. The affected session metadata still registers them as dynamic tools with defer_loading: true. However:

• they are absent from the model-visible initial tool surface;
• tool_search is also absent;
• therefore the model has no way to discover or invoke the deferred tools.

The direct user-visible symptom is that asking GPT-5.6-Sol to create another Codex task fails because create_thread is reported as unavailable.

This does not appear to be an account-permission or Desktop-handler-registration issue. The same account successfully invoked create_thread before the update, and the tool remains registered in current session metadata.

What steps can reproduce the bug?

1. Update to Codex App 26.707.91948 (build 5440), which bundles codex-cli 0.144.5.
2. Fully quit and reopen Codex.
3. Open a task using gpt-5.6-sol.
4. Ask:

> Create a separate Codex thread for testing.

1. Observe that Codex cannot access the dedicated create_thread tool.
2. Codex may attempt to fall back to running codex exec through the shell. This fallback does not create a normal user-owned task through the Codex Desktop task-management interface and should not be necessary.
3. The related deferred task-management tools, such as list_threads, fork_thread, and send_message_to_thread, are also unavailable.

Before the update/relaunch, GPT-5.6-Sol could discover and invoke codex_app.create_thread on the same machine and account.

What is the expected behavior?

The latest Codex update must not make first-party Desktop task-management tools unreachable for GPT-5.6-Sol.

When a dynamic tool such as codex_app.create_thread is marked deferred, Codex should provide a usable discovery path.

Either:

• tool_search must be exposed correctly in GPT-5.6-Sol's Direct/Responses Lite path; or
• the first-party Desktop tools must remain directly accessible when tool_search is unavailable.

Updating or restarting Codex should not remove capabilities that worked in the immediately previous app configuration on the same account and machine.

Additional information

I was able to restore the missing tools locally by forcing GPT-5.6-Sol back to its previous Code Mode configuration.

The downloaded model catalog showed:

{
  "slug": "gpt-5.6-sol",
  "tool_mode": "direct",
  "supports_search_tool": true,
  "use_responses_lite": true
}

I created a local copy of the complete model catalog, changed only GPT-5.6-Sol's tool_mode from:

"tool_mode": "direct"

to:

"tool_mode": "code_mode_only"

I then configured Codex to use it:

model_catalog_json = "/Users/<username>/.codex/model-catalog-sol-code-mode.json"

After fully restarting Codex, GPT-5.6-Sol could discover thread-management tools again. No account, project, plugin, or dynamic-tool registration changes were required.