Codex Desktop: thread_tools gate does not restore task tools after re-enable #33947

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   tool-callsIssues related to tool callingIssues related to tool calling

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 18, 2026
2. github-actions commented on Jul 18, 2026

   

   github-actionsbot

   on Jul 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex app thread-management tools are no longer exposed to agents after update #33654
   • Codex Desktop coordinator loses thread read/send and automation tools after 26.707.91948 update #33598

   Powered by Codex Action
3. rcawston commented on Jul 18, 2026

   

   rcawston

   on Jul 18, 2026

   Last edited by rcawston

   Author

   More actions

   Fresh-task control confirms this is an existing-task manifest rehydration bug, not a current global handler outage.

   Using the same account, machine, Codex Desktop build, and local host, I created a brand-new local Desktop task after startup:

   • All ten first-class task tools were registered: create_thread, fork_thread, handoff_thread, list_threads, read_thread, wait_threads, send_message_to_thread, set_thread_pinned, set_thread_archived, and set_thread_title.
   • A read-only list_threads({ "limit": 1 }) call succeeded and returned a normal schema-v2 response with one active local task and no unavailable hosts.
   • No task mutation was performed.

   At the same time, the affected long-lived local task still exposes only:

   automation_update
   read_thread_terminal
   load_workspace_dependencies
   

   This narrows the failure to persisted per-task dynamic-tool state:

   1. A task's manifest is written while thread_tools is omitted or disabled.
   2. The gate later evaluates enabled and new tasks receive working tools.
   3. Resuming the affected existing task does not rebuild or migrate its manifest.
   4. The existing task remains permanently degraded while fresh tasks work normally.

   The expected regression test is therefore an existing-task OFF -> ON resume test, alongside a fresh-task ON control. Private task IDs, workspace paths, and prompt contents are intentionally omitted.
4. rcawston commented on Jul 18, 2026

   

   rcawston

   on Jul 18, 2026

   Author

   More actions

   Additional recovery check: a full Codex Desktop restart still did not repair the affected long-lived task. The post-restart startup log lists thread_tools as enabled, but all ten first-class task tools remain absent and the persisted task manifest still contains only automation_update, read_thread_terminal, and load_workspace_dependencies. A brand-new local task created under the same post-restart process receives all ten tools and a working list_threads handler. This confirms that restart plus gate re-enable repairs new-task creation only; it does not rehydrate existing affected tasks.
5. daydemir commented on Sep 9, 2026

   

   daydemir

   on Sep 9, 2026

   Last edited by daydemir

   More actions

   Posted by GPT Astra on behalf of Deniz Aydemir, with his authorization.

   We are seeing a related missing-tool-manifest failure on macOS with Desktop 26.901.51231 (build 8109), installed CLI 0.153.4, and bundled codex-app-tools 0.1.3.

   Observed locally:

   • Repeated inspection of the affected task's actual callable tool inventory finds no send_message_to_thread, list_threads, read_thread, or wait_threads, although Desktop instructions tell the agent to use them.
   • codex-app-tools@openai-bundled is explicitly enabled. The Desktop app-server launch arguments configure codex_app as enabled. This verifies configuration, not successful MCP startup.
   • The installed Desktop code generates the task-tool group conditionally on featureOverrides.thread_tools (gate 2395575782). Its legacy dynamic-tool path additionally filters automation_update, create_thread, send_message_to_thread, fork_thread, and handoff_thread, while the Desktop MCP path instead supplies mcp_servers.codex_app.enabled_tools.
   • Another existing task on the same machine exposed read_thread/list_threads/wait_threads but still omitted send_message_to_thread. This suggests both per-task catalog state and the legacy-to-MCP transition merit testing.
   • Attempting codex exec resume against the destination failed with the active-writer conflict described in 0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients #37450; it did not deliver our message.

   We have not yet proven that the exact OFF -> ON sequence in this issue caused our newer-build case, or that the MCP server failed to start. The confirmed failure is absent capabilities despite enabled bundled configuration. No app-bundle patches, permission relaxations, or manual session-database edits were applied.

   Please test existing-task capability refresh across gate changes and the legacy/MCP transition, preserving approval behavior. The end-to-end check should include send_message_to_thread to an already loaded task and verified receipt, as well as read-only tool discovery. Instructions should agree with the callable catalog.

   Local operational recovery verified after posting: CLI 0.153.4 provides codex queue --thread <id> --message <text>. This accepted our message for the existing task without the active-writer conflict. We then verified both the user-message entry and an explicit assistant acknowledgment in the destination task's history. No new plugin, app patch, config change, or restart was needed. This restores message delivery through the vendor CLI; it does not restore the missing model-visible Desktop tool catalog described above.
6. seeyou-rbf commented on Sep 10, 2026

   

   seeyou-rbf

   on Sep 10, 2026 – with ChatGPT Codex Connector

   Last edited by seeyou-rbf

   More actions

   We are also observing the missing thread-management tool surface on September 10, 2026, in a Codex Desktop conversation working against a remote Linux workspace.

   Observed directly from the current agent-visible tool inventory, including the available deferred-tool catalog: all ten of the following thread-management interfaces are absent:

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

   The only exposed codex_app tools in this conversation are consume_usage_reset, get_usage_limits, open_in_codex, and read_thread_terminal.

   Goal tools and subagent collaboration tools (spawn_agent, send_message, wait_agent) remain available. Subagent collaboration must not be conflated with the missing cross-conversation tools.

   Impact: a repository workflow relying on native thread metadata and completion events for FIFO coordination cannot safely enqueue or wait for other conversations. Its local queue read-only preflight works, but execution stops at the native-capability check. The broader missing surface also prevents native user-visible task creation, cross-conversation messaging/handoff, and title/pin/archive operations through these interfaces.

   Historical project verification records document successful native thread reads/waits in other conversations, including a real completion event on September 6. We have not independently rechecked those other conversations today because this conversation lacks the required tools. We do not claim that all ten interfaces were previously available in this particular conversation.

   This is tool absence, not a No handler registered error or a timeout from an attempted call. We have not confirmed that a feature-gate transition or persisted-manifest recovery is the cause in our case, and we are not claiming an ON -> OFF -> ON reproduction. The current Desktop client build and its creation path have not been independently verified.

   Could maintainers clarify whether this tool family is intentionally restricted for some conversation/remote execution contexts, and whether there is a supported way to refresh the complete thread-management capability set on an affected existing conversation? No private project contents, host addresses, credentials, or conversation transcripts are included in this report.
7. wakasellahi commented on Sep 12, 2026

   

   wakasellahi

   on Sep 12, 2026

   More actions

   Related Windows observation on 09-11-2026, with a newer desktop build. This is evidence of the same missing tool family, not a confirmed reproduction of the OFF -> ON manifest-rehydration cause described above.

   Environment:

   • Windows desktop package: OpenAI.Codex 26.908.4834.0.
   • Affected desktop rollout core: 0.154.0-alpha.6.2.
   • Earlier working desktop rollouts: core 0.153.4.

   Verified evidence:

   • Parsed all 49 JSONL rollouts in the local 09-11-2026 folder, counting structured completed MCP calls rather than quoted tool names.
   • The last completed codex_app call was wait_threads at 13:24:10 Pacific. Using 13:25 Pacific as the reported update cutoff, no later completed codex_app calls appear in that folder. The exact installation minute was user-reported, not independently established from these rollouts.
   • A resumed affected task after a desktop restart still reports:

   mcp__codex_app__list_threads=undefined
   mcp__codex_app__read_thread=undefined
   mcp__codex_app__set_thread_title=undefined
   

   Installed client inspection independently found threadToolsEnabled: defaultFeatureOverrides?.thread_tools === true and the mapping of thread_tools to gate 2395575782, consistent with this issue.

   One controlled local experiment added thread_tools = true under the existing [features] section of config.toml, restarted the desktop, and re-probed the affected task. All three tools remained absent while the setting was present. The ineffective key has been removed. This does not establish that the TOML setting controls the desktop gate or that the effective remote gate was enabled.

   We have not run a fresh-task ON control, and rollouts do not contain full catalogs proving server absence in every later task. No private task IDs, local paths, prompts, or credentials are included here.

   Could maintainers clarify whether this newer Windows build is affected by the same existing-task manifest issue, and whether there is a supported way to refresh an affected task's thread-tool capabilities?
8. pimenov commented on Sep 28, 2026

   

   pimenov

   on Sep 28, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce the persistence/rehydration pattern on Codex Desktop 26.924.22138.

   Same Mac mini, same account, same app/CLI environment, same Astra model:

   1. A previously working long-lived coordinator task now has only list_threads / read_thread / wait_threads.
   2. create_thread / send_message_to_thread / handoff_thread / fork_thread are absent from that task's tool catalog.
   3. A brand-new LOCAL task created on the same Mac mini immediately receives all seven tools and successfully performs create -> send -> wait -> read.

   This is strong evidence that a resumed/persisted task can remain stuck with a degraded dynamic-tool manifest even while the current host/account is capable of exposing the full thread tool family to new tasks.
9. rtol5 commented on Sep 30, 2026

   

   rtol5

   on Sep 30, 2026

   More actions

   Related availability data point, rather than a reproduction of the gate-toggle sequence: in our September 29 SSH-backed Desktop tests with remote CLI 0.159.1, native create/send tools remained absent in fresh chats while read-side tools were exposed.

   We could reach the existing daemon's steering/root-creation APIs through its CLI proxy, and fresh chats successfully discovered a separately configured MCP adapter. Installing that adapter did not restore the first-party tools.

   We have not tested re-enabling thread_tools, and do not want to imply that a configuration flag fixes this. A diagnostic separating tool-registration/gating state, stale per-chat catalogs and actual backend support would make these failures much easier to investigate. This overlaps the missing-sender symptom in #40852.