Skip to content

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

Closed
Closed
GPT-5.6-Sol lost access to create_thread tool after update#33585
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingtool-callsIssues related to tool calling

Description

@adiachenko
adiachenko
opened on Jul 16, 2026

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.

  5. Observe that Codex cannot access the dedicated create_thread tool.

  6. 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.

  7. 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.

Activity

  1. adiachenko
    added
    appIssues related to the Codex desktop app
    on Jul 16, 2026
  2. github-actions
    added
    bugSomething isn't working
    app-serverIssues involving app server protocol or interfaces
    tool-callsIssues related to tool calling
    on Jul 16, 2026

  3. github-actions commented on Jul 16, 2026

    @github-actions
    github-actionsBot
    on Jul 16, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. jackaljojo commented on Jul 16, 2026

    @jackaljojo
    jackaljojo
    on Jul 16, 2026

    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.

  5. adiachenko commented on Jul 16, 2026

    @adiachenko
    adiachenko
    on Jul 16, 2026
    Author

    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.

  6. bdharris26 commented on Jul 16, 2026

    @bdharris26
    bdharris26
    on Jul 16, 2026

    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.

  7. adiachenko commented on Jul 17, 2026

    @adiachenko
    adiachenko
    on Jul 17, 2026
    Author

    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.

  8. adiachenko
    closed this as completedon Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingtool-callsIssues related to tool calling

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions