[macOS 26.901 / 0.153.4] Persistent Desktop task loses thread-management tools; CLI fallback remains backend-readable

What version of the Codex App are you using?

Desktop bundle metadata: 26.901.51231, build 8109, bundle identifier com.openai.codex (read from Info.plist, not About dialog).
Desktop bundled runtime: codex-cli 0.153.4.
Separately installed CLI: codex-cli 0.153.4.

What subscription do you have?

Not independently verified during this diagnostic; omitted rather than inferred.

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS, local Desktop task).

What issue are you seeing?

A persistent local Desktop task could successfully use built-in task-management tools earlier in the conversation, but later its model-visible tool registry no longer contained create_thread, read_thread, list_threads, or send_message_to_thread. Basic app tools, including navigate_to_codex_page and read_thread_terminal, remained available. The task's instructions still refer to task-management operations.

An actual attempted call to the previously available tool failed before any backend authorization response:

TypeError: tools.mcp__codex_app__send_message_to_thread is not a function

Repeated enumeration of the currently exposed ALL_TOOLS confirmed that the management functions were absent. This is an absent callable-tool surface, not an observed permission-denied response. No tool-discovery/search capability that could expose these missing app tools was available in the affected turn.

What steps can reproduce the bug?

The initiating transition is not yet isolated; the following is an observed diagnostic sequence, not a deterministic fresh-install reproducer:

In an existing local Desktop project task, ask the agent to inspect or create another task.
Enumerate the currently available app tools. The management tools above are absent, while basic navigation tools remain.
Attempt the previously callable task-message tool; observe the TypeError above.
As a separate fallback experiment, run codex exec --json -C <new-git-worktree> <prompt>.
The CLI emits thread.started, turn.started, and actual work output. However, the user cannot find this task automatically under the expected Desktop project and reports difficulty reading it through Desktop.
navigate_to_codex_page returns {"navigated":true} for that ID. This does not establish that the task content rendered or that project membership was assigned.
A read-only App Server diagnostic successfully reads the same persisted task:

{"id":2,"method":"thread/read","params":{"threadId":"<redacted>","includeTurns":true}}

Sanitized result:

{"readSuccess":true,"source":"exec","cwd":"<new-git-worktree>","turnCount":1}

The original Desktop task has source vscode; the fallback task has source exec. Both use paginated history and are not archived. A read-only local metadata check returned null project_id for both, including the existing Desktop project task, so null alone is NOT evidence of the cause. No state/history database was modified.

What is the expected behavior?

Supported Desktop task-management tools should remain available consistently, or the app should explicitly explain why they are unavailable and how to restore access.
Instructions should not promise an app tool surface that the active turn cannot discover or call.
Please clarify the supported path for creating a Desktop-visible, project-associated task. We do not assume codex exec must provide the same project association as the Desktop creation API.
A navigation acknowledgement should not be interpreted as proof of readable content or successful project association; an actionable UI error would help distinguish these cases.

Additional information

This installation has records of 0.153.4 tasks beginning September 7, and successful task-management calls earlier in this persistent conversation on September 8. Consequently, we have NOT established that a CLI update caused the failure. Desktop update timing, model/provider routing, feature flags, and task restoration remain hypotheses requiring controlled comparison.

The local config selects gpt-6-astra and provider identifier openai-http; this identifier alone does not establish a third-party endpoint or the actual route used for every Desktop turn. No provider endpoint or credentials are attached. No model/provider A/B test was performed.

The task itself is readable through App Server, so we do NOT claim transcript loss/corruption. We also do not claim a filesystem-permission problem, a confirmed regression in a specific release, or that changing repository rules can restore missing system tools.

Related reports: #31366 (older-task tool exposure), #33637 (model-dependent exposure), #37075 (provider-dependent exposure), #41404 (browser policy affecting tools), #40865 (missing replacement tools). Please consolidate if this is the same defect; this report adds the current macOS 26.901/0.153.4 observations and the successful backend-read versus Desktop/CLI fallback distinction. Unlike #43742, no duplicate-ordinal/history-projection failure has been established here.

No raw transcripts, task IDs, private project names/paths, repository source, credentials, databases, or unredacted logs are attached. No app restart, downgrade, permission expansion, or state-database repair was performed as part of this diagnostic.

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

Windows scheduled automation omits list_threads although codex_app reports ready #43487
Regression: headless SSH tasks lose thread messaging and delegation tools after Desktop update #42973

Powered by Codex Action

Adding another macOS reproduction from a newer Desktop build.

Environment

macOS 15.6.1, Apple silicon (arm64)
ChatGPT Desktop 26.903.71938, build 8576
Bundled Codex runtime 0.153.4
Model: gpt-5.6-sol

Observed behavior

A fresh Desktop task does not expose create_thread, fork_thread, list_threads, read_thread, wait_threads, send_message_to_thread, or the related pin/archive/title tools. Runtime enumeration confirms these functions are absent rather than returning an authorization error.

The affected session metadata has no dynamic_tools field and uses originator codex_work_desktop:

Affected session: 01a08b68-072e-7d20-9106-69c4e48437c9

For comparison, an older local Desktop session created with 0.147.0-alpha.6.5 persisted the codex_app dynamic namespace with the complete thread-management tool set and successfully invoked create_thread:

Previously working session: 01a033d6-ee34-7bc3-b04d-4fc7c90e1e35

I also checked local session metadata across this installation. All observed sessions created with 0.153.2 or 0.153.4 omit the older dynamic_tools metadata, including normal local-project sessions whose originator is Codex Desktop; therefore this does not appear limited to a single projectless conversation. Older alpha-runtime sessions are mixed, with some containing the full namespace and some not, consistent with conditional or intermittent injection.

This is consistent with the missing callable-tool surface reported here. It does not establish whether the cause is Desktop packaging, server-side eligibility, or runtime registry construction. No raw transcript, repository content, credentials, or private file paths are attached.

Additional observation from a task running on a remote Linux host on September 10, 2026: the task-management tool surface was partially available. Follow-up read-only inspection of the installed Windows Desktop bundle identifies a specific tool-transport gap that matches this observation.

Observed tool availability

Operation	Exposed
`list_threads`	Yes
`read_thread`	Yes
`wait_threads`	Yes
`set_thread_title`	Yes
`create_thread`	No
`fork_thread`	No
`handoff_thread`	No
`send_message_to_thread`	No
`tool_search`	No

The task's instructions still described create_thread and instructed the assistant to use it when asked to create a new task. Registry enumeration found no callable creation tool. No creation call was made, so no backend permission-denied response was observed. A subsequent side conversation independently found the same partial availability.

Follow-up bundle findings

Inspected app: Windows ARM64, package.json version 26.903.71938, build 8576 (Windows package 26.903.9818.0). The reporting task ran on the remote Linux host with bundled runtime 0.153.4, source vscode, and paginated history. These are separate from the macOS versions in the issue title.

The renderer contains an explicit exclusion set for the legacy dynamic-tool path:

new Set([
  "automation_update",
  "create_thread",
  "send_message_to_thread",
  "fork_thread",
  "handoff_thread"
])

The relevant code path is:

Creation inputs set usesDesktopMcp using a predicate that accepts only the current local host (host_config.id matches and host_config.kind === "local").
Registration uses an empty dynamic-tool list for Desktop MCP tasks, and applies the exclusion filter above to non-MCP tasks. MCP tasks instead receive mcp_servers.codex_app.enabled_tools.
The Desktop MCP launcher returns immediately for non-local host configurations: if (e.kind !== "local") return []. Thus the remote task loses these five legacy tools without getting the automatically configured local MCP replacement.
Dispatch also rejects these five tools through the dynamic path. The bundled error text says:

This app tool is no longer available through dynamic tools. Use the codex_app MCP server. If that server is unavailable on this host, task delegation is unavailable.

This is a code finding, not an error observed from an attempted call in the reporting task.
The Thread Coordination instructions are included based on the separate thread_tools feature flag, rather than the final transport-specific catalog. This explains why instructions can still request unavailable operations.

Verification and scope

Read-only inspection of the reporting task's initial session_meta.dynamic_tools confirmed that all five excluded tools, including automation_update, were already absent at task creation, while reading/listing tools were present. The initial developer message nevertheless contained the creation instructions. This particular task therefore does not demonstrate tools disappearing later within its lifetime.

An isolated Node VM check of the actual extracted filter, using the saved catalog plus the five excluded names as input, reproduced the saved catalog exactly. A separate check of the extracted host predicate selected MCP for a local host and rejected the remote host. This is verification of the extracted logic, not a full end-to-end reproduction.

For source lookup in this build:

webview/assets/app-initial-f094ef01c64d.js: filter nkt, exclusion set ikt, local-host predicate $O, and usesDesktopMcp registration/dispatch logic.
.vite/build/main-CMBCj4XL.js: Desktop MCP launch function SO with the non-local early return.
.vite/build/src-B6LqG3ek.js: instruction assembly function u$, gated by threadToolsEnabled.

Conclusion: the current bundle's migration to MCP-only delegation tools explains this remote-task availability split with high confidence. A complete fix would need a supported remote MCP path or a supported remote fallback covering both registration and dispatch; instructions should also reflect actual capabilities.

This does not establish that the original broader macOS report has the same cause, explain the separate absence of tool_search, or identify the release that introduced the migration. The exact frontend build at the reporting task's creation time was not independently established. The user recalled prior availability, but an earlier successful call was not verified.

No app files, configuration, permissions, or history were modified. No restart or CLI fallback was attempted. No private project information, credentials, or raw transcripts are included.

Additional Windows reproduction on Desktop 26.908.4834.0

I am seeing the same missing thread-management tool surface on a newer Windows build.

Environment

Observed: September 12, 2026
Platform: Microsoft Windows NT 10.0.26200.0, x64
Microsoft Store ChatGPT/Codex installed version: 26.908.4834.0
Microsoft Store listing showed “Last updated”: September 11, 2026
codex --version from the current PATH: codex-cli 0.154.0-alpha.6.2
- This is the CLI visible on PATH; I have not established that it is the runtime bundled with the Desktop app.
Context: existing local Codex Desktop project task
Model and subscription: not independently verified during this diagnostic

Reproduction

In an existing local Codex Desktop task, ask the agent to create a new user-owned Codex task that should appear in the sidebar.
The agent checks its callable tool registry for the documented task-management operations.
The task-management tools and their discovery mechanism are absent.
The agent cannot create the requested task.
Creating the task manually through the sidebar succeeds and the new task appears normally.

Confirmed missing callable tools

A direct enumeration of the active task's exposed tool registry returned no matches for:

create_thread
fork_thread
list_threads
read_thread
wait_threads
send_message_to_thread
handoff_thread
set_thread_title
set_thread_archived
set_thread_pinned
tool_search

This was not an observed permission denial or approval-modal failure. The callable functions were absent, so no thread-management call reached the backend and no approval prompt appeared.

A background subagent was available, but it was intentionally not used because it is not equivalent to creating a user-owned, sidebar-visible Codex task.

Expected behavior

When explicitly asked to create a new user-owned Codex task, the Desktop session should expose create_thread, or provide a working discovery path through tool_search.

Actual behavior

The agent had no callable or discoverable task-management interface and had to report that the task could not be created. Manual sidebar creation continued to work.

Scope and uncertainty

The installed version and Microsoft Store update date are confirmed from the Store UI, but this does not establish that the September 11 update caused the regression. Packaging, task restoration, feature flags, model routing, and server-side tool injection remain unverified.

No configuration changes, downgrade, database edits, or alternate task-creation fallback were performed.

Related issue:
Issue #30233
Issue #33585

Same issue on Windows: task-management tools missing

I am experiencing this in Codex Desktop on Windows, in a local project without Remote SSH.

Versions identified in the application logs:

Desktop release: 26.911.61220
App-server/CLI: 0.155.0-alpha.2.6

The agent cannot access:

list_threads
list_archived_threads
create_thread
read_thread
wait_threads
send_message_to_thread

No tool_search capability is available either. The agent checked its exposed tool registry and found none of these tools.

File access, local commands, web search, and other connector tools work. This is not a permission-denied error — the task-management tools are absent.

Manual task creation through the Desktop UI works, but a newly created task also lacks these tools.

The issue persists after:

restarting the application;
restarting Windows;
updating the application;
creating a new task manually.

Windows reproduction with a confirmed working/broken build boundary.

Environment:

Windows 11, Codex Desktop
Current installed package: 26.915.3509.0
Current Desktop client reported to app-server: 26.915.31029
Current bundled CLI: 0.155.0-alpha.9
Bundled codex-app-tools: 0.1.4

Observed timeline:

Desktop 26.903.61454 / CLI 0.153.4: Desktop logs show the singular codex_app MCP server entering starting and then ready. Thread-management calls including create_thread worked.
Beginning with Desktop 26.908.40834: the same persistent campaign/project workflow no longer exposed create_thread, list_threads, set_thread_title, send_message_to_thread, etc.
Current 26.915.3509.0: still affected.

Current-task diagnostics:

Desktop logs show codex_apps (plural connectors service), node_repl, and the artifact-template picker reaching ready.
There is no startup-status event or startup attempt for codex_app (singular task-management bridge).
Model-visible ALL_TOOLS contains none of the thread-management tools.
The bundled codex-app-tools plugin is present and its MCP manifest defines create_thread, fork_thread, handoff_thread, and related tools.
The active app-server process command line explicitly includes:
plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true
but the singular server is nevertheless absent from the resolved per-thread MCP configuration.
No codex_app child process is launched and there is no failure event; it is silently omitted.

Storage/path checks:

CODEX_HOME is redirected to another local drive.
The default %USERPROFILE%\.codex path is a valid junction to that state directory.
File IDs match through the junction, and the bundled marketplace/plugin is correctly materialized in the active state directory.
The older working Desktop build used the same redirected-home arrangement, so this does not appear to be a drive-placement or filesystem-permission issue.

Expected:
The singular codex_app bridge should be loaded when Desktop explicitly enables it, or Desktop should surface a startup/configuration error explaining why it was omitted.

This Windows evidence appears to corroborate the missing callable-tool surface described in this issue and narrows the local regression interval from 26.903.61454 (working) to 26.908.40834 (affected). No raw transcripts, private project names, credentials, or unredacted logs are included.

Additional Windows reproduction: Desktop 26.915.3509.0 / CLI 0.155.0-alpha.9

Observed on September 18, 2026, in a local Windows Codex Desktop project task (the task itself is not hosted through Remote SSH).

Versions verified locally

Installed Windows package: OpenAI.Codex 26.915.3509.0 (Get-AppxPackage).
codex --version: codex-cli 0.155.0-alpha.9. The resolved executable is under the Desktop-managed local Codex bin directory.

Observed behavior
The user explicitly asked one existing task to read another existing task's latest requirements and send it a completion notification. Direct enumeration of the active task's callable tool registry found none of:

read_thread
send_message_to_thread
create_thread
list_threads
wait_threads
tool_search

The injected Desktop instructions still describe these task-coordination tools and tell the agent to discover/use them. Local command execution, file access, web search, and GitHub connector tools work. This is a missing callable-tool surface, not a tool call rejected by an approval dialog.

Fallback results

Reading the target's local saved history was possible.
codex exec resume <target-id> ... failed with already has an active writer. This is reported only as a fallback limitation; it is not evidence of the cause of the missing tools.
codex queue --thread <target-id> --message <notification> succeeded and returned Queued message <message-id> for thread <target-id>.
Only queue acceptance was confirmed; target consumption/processing was not independently verified.

This corroborates the Windows build reported above: native task read/send tools are absent even though the CLI can accept a message for the existing task.

The user recalls this working before a client update, but we have not established a controlled working/broken version boundary on this installation or inspected the Desktop MCP startup configuration. No claim is made that this update is the proven cause.

Please investigate the missing task-management tool registration and ensure Desktop guidance matches the tools actually exposed. Private task IDs, paths, message contents, and credentials are omitted.

High-impact regression: native task / worktree-chat handoff is unavailable

This is a regression, not a feature request. The desktop app previously let an agent create a user-owned task in a separate worktree and return an Open chat handoff. That workflow is now unavailable, which blocks delegating independent work without manually recreating the task and losing the sidebar handoff.

Current environment

ChatGPT for macOS 26.917.51856 (build 10492)
Bundled Codex CLI: 0.155.0-alpha.16
Models tested: gpt-6-sol and gpt-5.6-terra

Actual behavior

The native task tools are absent from the agent's actual tool registry: create_thread, fork_thread, send_message_to_thread, and handoff_thread are all unavailable. There is no permission prompt or error to act on; the agent cannot create a user-owned task at all.

The bundled app contains codex-app-tools, but the desktop startup logs show only server=codex_apps status=ready; there is no startup entry for the singular codex_app server that exposes the native task-management tools. The local Codex config has no disabling override.

Reproduction attempts

Fully quit and restart the desktop app.
Switch the active task from gpt-6-sol to gpt-5.6-terra.

Neither restores the missing tools.

Regression evidence

On the same Mac, archived Codex sessions from 2026-08-27 and 2026-08-28 show successful create_thread calls under bundled CLI 0.150.0-alpha.8, including from a non-Git directory. This rules out the current directory and Git worktree state as the cause.

Impact / request

This breaks a core desktop workflow: create isolated work, hand it to a user-owned task, then open that task from the returned handoff. Manual worktree creation is not an equivalent replacement because it does not produce the managed task or its chat handoff.

Please triage this as a regression in desktop tool injection/activation and restore the native task-management tool surface. A diagnostic or supported recovery path would also help affected users immediately.

I ran a controlled retest on October 6, 2026. Native task coordination now works in the Desktop tasks I tested.

My environment:

About: 26.930.51102.
MSIX: OpenAI.Codex 26.930.6422.0, ARM64.
Windows 11 Home 25H2, build 26200.9457, ARM64.
WSL 2.7.11.0; Ubuntu 24.04.1; Linux aarch64; default shell /bin/bash.
Active Desktop-managed WSL executable: codex-cli 0.160.0.

My controlled test:

Create test task A through the normal UI.
From my existing diagnostic task, create test task B with native create_thread: succeeded.
Read A with native read_thread, including from B: succeeded.
Read A one turn per page: both turns were retrieved, ending with hasMore=false.
Use wait_threads on B: succeeded.
Have A send one harmless PING to B with native send_message_to_thread.
Have B send one ACK back with the same native tool.

Both sends were accepted. I checked B's record for the received PING and A's record for the received ACK, so this verifies actual delivery and response rather than queue acceptance alone.

The tested native operations behaved as expected, without invocation errors. I did not use a separate CLI or internal API fallback.

list_threads was callable but I did not invoke it, to avoid enumerating unrelated conversations. App-restart resume behavior and long-term tool retention remain untested. I have not established the original provisioning or plugin-cache cause.

Navigation Menu

Repository navigation

[macOS 26.901 / 0.153.4] Persistent Desktop task loses thread-management tools; CLI fallback remains backend-readable #44044

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Observed tool availability

Follow-up bundle findings

Verification and scope

Additional Windows reproduction on Desktop 26.908.4834.0

Environment

Reproduction

Confirmed missing callable tools

Expected behavior

Actual behavior

Scope and uncertainty

Same issue on Windows: task-management tools missing

Additional Windows reproduction: Desktop 26.915.3509.0 / CLI 0.155.0-alpha.9

High-impact regression: native task / worktree-chat handoff is unavailable

Current environment

Actual behavior

Reproduction attempts

Regression evidence

Impact / request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[macOS 26.901 / 0.153.4] Persistent Desktop task loses thread-management tools; CLI fallback remains backend-readable #44044

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Sep 9, 2026

xiehuan123 commented on Sep 10, 2026

junhaoliao commented on Sep 10, 2026

Observed tool availability

Follow-up bundle findings

Verification and scope

Jadabo3 commented on Sep 12, 2026

Additional Windows reproduction on Desktop 26.908.4834.0

Environment

Reproduction

Confirmed missing callable tools

Expected behavior

Actual behavior

Scope and uncertainty

kacperobrzut commented on Sep 18, 2026

Same issue on Windows: task-management tools missing

BIGBOTCHED commented on Sep 18, 2026

li2go commented on Sep 18, 2026

Additional Windows reproduction: Desktop 26.915.3509.0 / CLI 0.155.0-alpha.9

epose-37 commented on Sep 23, 2026

High-impact regression: native task / worktree-chat handoff is unavailable

Current environment

Actual behavior

Reproduction attempts

Regression evidence

Impact / request

mtk177a commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions