Older Codex Desktop threads may not expose codex_app thread management tools #31366

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

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

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

   

   github-actionsBot

   on Jul 7, 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 not exposed despite thread creation being available #30233
   • Codex App project thread creation tools are missing #30944

   Powered by Codex Action
3. Eason412 commented on Sep 21, 2026

   

   Eason412

   on Sep 21, 2026

   More actions

   Additional macOS reproduction: restored task reports no coding tools; changing models restores execution

   Adding a related observation from September 21, 2026, rather than opening a duplicate. The old-task/new-task difference resembles this report, but the affected surface is broader than thread-management tools. An identical root cause has not been established.

   Environment

   • macOS 27.0, arm64.
   • Desktop app 26.915.31945, build 9922 (bundle metadata).
   • Runtime recorded in session metadata: 0.155.0-alpha.9.2.
   • Existing local Desktop task; model gpt-6-astra, reasoning medium, provider openai, ChatGPT authentication.
   • A custom model catalog is configured, including a context-window override. Its tool settings are shell_type=unified_exec and tool_mode=code_mode_only. A stock-catalog comparison has not been performed.

   Observed sequence

   1. Restart the Desktop app and resume an existing local coding task.
   2. Submit an ordinary code-change request. The assistant reports that file/terminal/browser or coding/deployment tools are unavailable and performs no tool calls.
   3. A newly created task using the same model can execute commands on the same machine.
   4. Diagnostic follow-ups and reapplying the same model/reasoning settings do not restore execution in the old task.
   5. Change the affected task to gpt-5.6-sol / medium. The same task starts making real functions.exec -> tools.exec_command calls and resumes work.

   The user reports recurrence after app restarts. One restart/recovery episode was inspected directly; the recurrence rate was not independently measured.

   Sanitized diagnostic evidence (times below are UTC)

   • 00:41:40: app-server initialization handshake succeeded.
   • 00:42:36: thread/resume succeeded; returned permissions were danger-full-access / never.
   • 00:45:26–00:45:37: the failed turn completed with zero tool calls. No tool-level permission rejection was observed.
   • 00:46:04: new-session MCP initialization logged available_server_count=5 unavailable_server_count=0 tool_count=258; the new task subsequently executed commands. This does not establish the old task's model-visible tool list.
   • 00:50 and 00:53: follow-up diagnostics still produced no execution. These were delivered through send_message_to_thread; the responses repeated the business plan instead of returning a tool inventory, so the diagnostic delivery path is also a limitation.
   • After the model change, the original task recorded execution-tool calls at 00:56:08, 00:56:31, 00:56:39, and 00:56:43.

   Relevant conversation excerpts (English translations; unrelated business content omitted)

   User: ‘Why does it say I have not provided the relevant tools? I have to start another conversation before it can use them. This happens after restarting Codex.’

   Affected assistant, 00:45:37: ‘The current session has not provided coding and deployment tools. No changes have been made or deployed.’

   Read-only diagnostic request, excerpt: ‘Actually execute pwd using the tools available in this turn. Do not modify files or deploy.’

   Affected assistant, 00:50:54: ‘The current session has no available code-operation tools.’

   Affected assistant after identical model settings were reapplied, 00:53:21: ‘The current session has no available file, terminal, or browser tools. Tool access must be restored before continuing.’

   User: ‘Switching models previously resolved this, but I do not want to switch models in the middle of a task.’

   Recovery observation: After the user authorized a temporary model change, the affected task produced actual execution-tool calls and resumed implementation.

   Expected behavior / remaining uncertainty
   A restored local task should retain its coding tools without requiring a new conversation or a model change. The failed request's complete tool definitions were not captured, so this evidence does not distinguish missing tool injection/runtime state from an incorrect model assessment of its available tools. No claim is made that a specific release introduced the issue.

   A secondary observation during diagnosis: read_thread / wait_threads returned recent turn metadata but empty items/latest assistant messages, while the local rollout contained the actual replies and tool calls. It is not established whether this shares the same cause.

   Only relevant translated excerpts and sanitized log fields are included here; no credentials, private repository content, internal URLs, or complete raw transcripts are published.
4. LinkStartR commented on Sep 26, 2026

   

   LinkStartR

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce this issue: the conversation-renaming skill loaded, but set_thread_title was unavailable, so the agent could not apply the title. The tool was still unavailable on retry.