What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.707.91948 (build 5440), bundling codex-cli 0.144.5.
What subscription do you have?
ChatGPT paid subscription. The exact tier is not exposed in the current Codex task.
What platform is your computer?
Darwin 25.5.0 arm64 arm (macOS 26.5.2, build 25F84; Apple Silicon).
What issue are you seeing?
After updating to the unified Codex/ChatGPT Desktop app, a coordinator task lost the complete first-party control surface required to manage existing user-owned Codex tasks and heartbeat automations.
This is broader than a failure to create a new task. The affected gpt-5.6-sol task cannot read existing tasks, send instructions to them, inspect their latest status, receive/manage native task handoffs through the intended APIs, or migrate an existing heartbeat automation.
The model-visible codex_app namespace contains only:
load_workspace_dependenciesnavigate_to_codex_pageread_thread_terminal
The following first-party tools are missing or unreachable:
create_threadfork_threadlist_threadsread_threadsend_message_to_threadhandoff_threadset_thread_titleset_thread_pinnedset_thread_archivedautomation_update
There is no usable tool_search path to discover these deferred tools. The underlying app-server schemas for the thread operations still exist, and the Desktop task guidance still describes the task-management capabilities, but the tools are not present in the callable manifest.
This prevents a real Desktop project-coordinator workflow from operating. It is not equivalent to a generic subagent workflow: the target tasks are existing user-owned tasks visible in the Desktop sidebar, with their own state and direct-report expectations.
What steps can reproduce the bug?
- Update the Codex/ChatGPT Desktop app to
26.707.91948 (build 5440, bundled CLI 0.144.5).
- Fully quit the Desktop app.
- Relaunch the app.
- Create a brand-new local task after the relaunch.
- Select
gpt-5.6-sol with xhigh reasoning.
- Ask the task to perform any of the following native Desktop operations:
- read the latest state of an existing sidebar task;
- send a message to an existing sidebar task;
- list or inspect existing tasks;
- update an existing heartbeat automation so it targets the current task.
- Observe that
read_thread, send_message_to_thread, list_threads, and automation_update are unavailable.
- Inspect the available
codex_app tools and observe that only load_workspace_dependencies, navigate_to_codex_page, and read_thread_terminal are exposed.
The problem survives a complete app restart and creation of a new task. It is therefore not limited to an old resumed task.
Affected task/session ID: 019f6abd-aea9-7092-af62-d6a5232d76e9.
What is the expected behavior?
A fresh local Desktop task that is eligible to coordinate other user-owned tasks should receive a consistent, callable first-party task-management surface.
At minimum, the model should be able to discover and invoke:
list_threadsread_threadsend_message_to_threadcreate_threadset_thread_titleset_thread_archivedautomation_update
If the tools are intentionally deferred, tool_search must be available and capable of discovering them. If the product no longer permits these operations, the app should expose an explicit capability/policy message instead of silently removing tools that were previously available.
Using codex exec, codex exec resume, moving the Codex window, or spawning background subagents is not an equivalent workaround. Those paths do not restore normal sidebar task ownership, cross-task status reads, direct message delivery, or native heartbeat management.
Additional information
The same coordinator workflow worked before the unified Desktop update and failed after the update/relaunch. This points to a tool exposure/discovery regression rather than a repository, project, or account configuration problem.
Related issues:
This issue is being filed separately because the user-visible failure is the loss of the complete existing-task coordination and automation-management control plane, not only task creation or third-party MCP tools.
An English in-product feedback report was also submitted: 019f6acb-93db-7cd3-a646-0f2b16ecf82a.
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App
26.707.91948(build5440), bundlingcodex-cli 0.144.5.What subscription do you have?
ChatGPT paid subscription. The exact tier is not exposed in the current Codex task.
What platform is your computer?
Darwin 25.5.0 arm64 arm(macOS 26.5.2, build 25F84; Apple Silicon).What issue are you seeing?
After updating to the unified Codex/ChatGPT Desktop app, a coordinator task lost the complete first-party control surface required to manage existing user-owned Codex tasks and heartbeat automations.
This is broader than a failure to create a new task. The affected
gpt-5.6-soltask cannot read existing tasks, send instructions to them, inspect their latest status, receive/manage native task handoffs through the intended APIs, or migrate an existing heartbeat automation.The model-visible
codex_appnamespace contains only:load_workspace_dependenciesnavigate_to_codex_pageread_thread_terminalThe following first-party tools are missing or unreachable:
create_threadfork_threadlist_threadsread_threadsend_message_to_threadhandoff_threadset_thread_titleset_thread_pinnedset_thread_archivedautomation_updateThere is no usable
tool_searchpath to discover these deferred tools. The underlying app-server schemas for the thread operations still exist, and the Desktop task guidance still describes the task-management capabilities, but the tools are not present in the callable manifest.This prevents a real Desktop project-coordinator workflow from operating. It is not equivalent to a generic subagent workflow: the target tasks are existing user-owned tasks visible in the Desktop sidebar, with their own state and direct-report expectations.
What steps can reproduce the bug?
26.707.91948(build5440, bundled CLI0.144.5).gpt-5.6-solwithxhighreasoning.read_thread,send_message_to_thread,list_threads, andautomation_updateare unavailable.codex_apptools and observe that onlyload_workspace_dependencies,navigate_to_codex_page, andread_thread_terminalare exposed.The problem survives a complete app restart and creation of a new task. It is therefore not limited to an old resumed task.
Affected task/session ID:
019f6abd-aea9-7092-af62-d6a5232d76e9.What is the expected behavior?
A fresh local Desktop task that is eligible to coordinate other user-owned tasks should receive a consistent, callable first-party task-management surface.
At minimum, the model should be able to discover and invoke:
list_threadsread_threadsend_message_to_threadcreate_threadset_thread_titleset_thread_archivedautomation_updateIf the tools are intentionally deferred,
tool_searchmust be available and capable of discovering them. If the product no longer permits these operations, the app should expose an explicit capability/policy message instead of silently removing tools that were previously available.Using
codex exec,codex exec resume, moving the Codex window, or spawning background subagents is not an equivalent workaround. Those paths do not restore normal sidebar task ownership, cross-task status reads, direct message delivery, or native heartbeat management.Additional information
The same coordinator workflow worked before the unified Desktop update and failed after the update/relaunch. This points to a tool exposure/discovery regression rather than a repository, project, or account configuration problem.
Related issues:
create_threadand thedirect+ Responses Lite deferred-tool discovery problem.codex_appthread-management surface.automation_updateexposure across local Desktop tasks.This issue is being filed separately because the user-visible failure is the loss of the complete existing-task coordination and automation-management control plane, not only task creation or third-party MCP tools.
An English in-product feedback report was also submitted:
019f6acb-93db-7cd3-a646-0f2b16ecf82a.