›_ Codex Issues
Codex Issues / #33585

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

Resolved 💬 5 comments Opened Jul 16, 2026 by adiachenko Closed Jul 17, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33575
  • #33547

Powered by Codex Action

jackaljojo · 1 month ago

Independent macOS reproduction: thread management and automation tools disappear together

I can independently reproduce this regression in the unified Codex/ChatGPT Desktop app.

Environment

  • Codex App: 26.707.91948 (build 5440)
  • Bundled CLI: codex-cli 0.144.5
  • macOS: 26.5.2 (25F84), Apple Silicon / arm64
  • Model: gpt-5.6-sol
  • Reasoning effort: xhigh

Fresh-session reproduction

This still reproduces after:

  1. Fully quitting the Desktop app.
  2. Relaunching it.
  3. Creating a brand-new local task after the relaunch.
  4. Selecting gpt-5.6-sol with xhigh reasoning.

The model-visible codex_app surface in the new task contains only:

  • load_workspace_dependencies
  • navigate_to_codex_page
  • read_thread_terminal

The following first-party tools are missing/unreachable:

  • create_thread
  • fork_thread
  • list_threads
  • read_thread
  • send_message_to_thread
  • handoff_thread
  • set_thread_title
  • set_thread_pinned
  • set_thread_archived
  • automation_update

There is also no usable tool_search path for discovering the deferred tools. The underlying app-server thread-management schemas still exist, so this appears to be a model-visible tool exposure/discovery regression rather than removal of the backend capability.

User-visible impact

A Desktop coordinator task can no longer:

  • inspect existing user-owned tasks;
  • send instructions to an existing task;
  • receive or inspect cross-task handoff state through the intended task APIs;
  • migrate or manage an existing heartbeat automation.

Using shell commands such as codex exec or codex exec resume is not an equivalent workaround: it does not restore the Desktop task-management tool surface, normal sidebar task ownership, or native cross-task receipt routing.

This is especially disruptive because the app instructions still describe the thread and automation tools as supported, while the actual tool manifest does not expose them.

Correlation with the update

The same task-orchestration workflow worked before the unified Desktop update. It failed after updating to 26.707.91948 / 0.144.5 and persisted through a complete restart and a newly created task. This strongly supports the direct + Responses Lite / deferred-tool discovery explanation reported in this issue.

Related reports include #29223 for the collapsed local codex_app thread-management surface and #29128 for inconsistent automation_update exposure.

An in-product English feedback report was also submitted before posting here: 019f6acb-93db-7cd3-a646-0f2b16ecf82a.

adiachenko · 1 month ago

On potential duplicates: #33547 and #33575 cover MCP tools in CLI, while this issue covers first-party codex_app task tools in Desktop and has an independent reproduction.

I’ll keep this issue open unless someone from the team confirms those issues also covers the Desktop tool surface.

bdharris26 · 1 month ago

Independent Windows reproduction with a GPT-5.5 control:

  • Codex Desktop 26.707.12708.0; task session_meta.cli_version is 0.144.5.
  • Fresh gpt-5.6-sol and gpt-5.5 tasks persist the same complete 15-tool codex_app manifest, with the management tools marked deferLoading: true.
  • On Sol, only the three non-deferred app tools are exposed and tool_search is absent.
  • On GPT-5.5, tool_search is available and list_threads, read_thread, and send_message_to_thread are accessible.

This confirms that initial dynamic-tool injection succeeds and that the failure is model-route-specific after injection. It complements the Terra/Sol Windows control in #33637 with GPT-5.5 as a second working control.

adiachenko · 1 month ago

Updated to 26.715.21425 today. Removed the temporary fix described in _Additional information_ section of original post.

Codex app was able to create a thread without issue using GPT-5.6 Sol.

Looks like they fixed it. I'll give it a few hours and test it some more, then close the issue if nothing comes up.