[Desktop Remote SSH] inter-task tools stopped before update; 0.148 lacks codex_app MCP replacement

Summary

In Codex Desktop connected to a remote Linux host, previously working first-party inter-task coordination stopped working before the remote Codex runtime was updated. Updating the remote runtime from 0.145.0 to stable 0.148.0 did not restore the capability.

The failure currently has two observable forms:

A retained Desktop task whose manifest still contains send_message_to_thread reaches the old dynamic-tool handler, but the handler now rejects the call with a migration message telling the caller to use the codex_app MCP server.
A fresh Desktop user task on 0.148.0 retains read-only task tools (list_threads, read_thread, wait_threads) but omits the effectful inter-task tools (create_thread, send_message_to_thread, and handoff_thread). No callable codex_app MCP replacement or tool_search discovery path is present.

This report intentionally does not claim that 0.148.0 caused the initial regression. The first failure was recorded while the remote runtime was still 0.145.0; the update was attempted as a possible fix and did not fix it.

Environment

Surface: Codex Desktop
Execution host: remote Linux over Codex Remote SSH (remote-ssh-discovered:<host>)
Model in both the working and failing retained task: gpt-5.6-sol
Remote runtime before the manual update: codex-cli 0.145.0
Remote runtime after the manual update: stable codex-cli 0.148.0
Desktop About-dialog build and Desktop host OS are not exposed inside the remote task
No user-authored mcp_servers.codex_app configuration is present

Exact task IDs and raw transcripts are intentionally omitted from the public report. They can be supplied through a private support or in-app feedback channel if needed.

Observed timeline (UTC)

All successful and rejected sends below came from the same retained Codex Desktop task, used the same gpt-5.6-sol model, the same remote host projection, and the same destination task.

2026-08-25 15:00:06, runtime 0.145.0: send_message_to_thread succeeded and returned { "threadId": "<target>" }.
2026-08-25 15:38:22, runtime 0.145.0: another send succeeded and returned { "threadId": "<target>" }.

2026-08-26 07:11:17, before the runtime update and still on 0.145.0: the same tool and destination failed with:

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.

2026-08-26 08:14:52, still before the update: the same rejection reproduced.
The remote runtime transition occurred later: Desktop-created task metadata still recorded 0.145.0 at 08:46:12; newly created task metadata recorded 0.148.0 starting at 09:49:36.
2026-08-26 09:57:37: a fresh Desktop user task on 0.148.0 was created. Its callable codex_app catalog contains:
- list_threads
- list_archived_threads
- read_thread
- wait_threads
- title/pin/archive helpers
But it omits:
- create_thread
- send_message_to_thread
- handoff_thread
There is also no tool_search and no callable mcp__codex_app__* replacement.
The injected Codex Desktop guidance still instructs the task to search for and use create_thread and send_message_to_thread, so the guidance and callable tool catalog disagree.

Reproduction

Open a Codex Desktop task backed by a remote Linux host.
From a task that still has the legacy dynamic tool definition, call send_message_to_thread for a valid existing task on that same host.
Observe the migration rejection directing the caller to the codex_app MCP server.
Create a fresh Desktop task on the same remote host.
Inspect the callable tool inventory.
Observe that read/list/wait remain available while create/send/handoff are absent, and that the advertised MCP replacement is not available.

Expected behavior

The Desktop task-tool migration should be atomic for Remote SSH hosts:

If dynamic handlers are disabled, the first-party codex_app MCP replacement must already be provisioned and callable.
A user-authorized task should be able to create a normal user-owned Desktop task and send a visible message to an existing Desktop task.
The read and write halves of the task-management surface should not be silently split.
App guidance must match the callable tool catalog.
If policy intentionally removes these capabilities, Codex should expose a structured capability diagnostic instead of referring to an unavailable MCP server.

Impact

This breaks established user-owned multi-task orchestration:

coordinator tasks cannot create worker tasks;
workers cannot send completion callbacks to the coordinator;
migration-coordination notifications cannot be delivered;
spawn_agent is not an equivalent replacement because it creates an internal subagent rather than a user-owned Desktop task;
codex exec is not an equivalent replacement because the resulting backend session is not reliably registered or navigable in the Desktop sidebar.

Causality boundary

The available evidence supports a task-tool routing/provisioning regression, but not a specific triggering release:

The first failure occurred on 0.145.0 before the user updated.
Stable 0.148.0 did not restore the bridge.
The exact rejection text indicates an intended migration from dynamic tools to codex_app MCP, while the replacement is absent on this Remote SSH path.

Related reports:

Codex app cannot create a new task from a devbox after create_thread tool migration #39978 — exact dynamic-tools-to-codex_app-MCP rejection on a remote devbox; closed without a public resolution
[macOS Desktop 26.820.60940] code-mode tasks omit send_message_to_thread while read tools remain #40852 — fresh report where read/list/wait remain but effectful task tools are omitted
Codex Desktop coordinator loses thread read/send and automation tools after 26.707.91948 update #33598 — earlier broader loss of the Desktop coordinator control surface

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

[macOS Desktop 26.820.60940] code-mode tasks omit send_message_to_thread while read tools remain #40852
Codex app cannot create a new task from a devbox after create_thread tool migration #39978

Powered by Codex Action

I can confirm the same failure on another Codex Desktop Remote SSH workflow today (2026-08-26 UTC).

Environment visible from the remote task:

remote Linux execution host
codex-cli 0.147.0
user explicitly authorized sending a follow-up to an existing user-owned Desktop task
the destination was another Remote SSH task on a different saved host

The read side continued to work throughout:

list_threads resolved the exact destination and host projection
read_thread returned its current turn and tool history
wait_threads returned valid cursors and status transitions

The caller's deferred tool catalog also advertised codex_app__send_message_to_thread with its full schema. However, every invocation returned exactly:

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.

There was no callable mcp__codex_app__send_message_to_thread replacement. This reproduced multiple times before a network interruption. After the destination Remote SSH host reconnected, list_threads and read_thread again resolved the task successfully, but send_message_to_thread still returned the same migration rejection. That reconnect result helps rule out destination discovery, destination availability, and user authorization as causes.

Operational impact in this case was significant: a coordinator could observe a deployment worker and receive its progress, but could not wake the now-idle worker after the connection recovered. The only safe workaround was asking the human to open the destination task and send the continuation message manually. handoff_thread would not be an equivalent workaround because it mutates checkout/worktree placement, and internal subagents are not user-owned Desktop tasks.

No task IDs, internal hostnames, credentials, repository names, or deployment endpoints are included here. I can provide a sanitized tool transcript through a private channel if maintainers need it.

Additional sanitized Remote SSH variant where the regression expands beyond the effectful half of the task-tool family.

Environment:

Codex Desktop controlling a remote Linux task
remote task session metadata: codex-cli 0.147.0
long-lived retained task; target task was idle and remained resolvable from the controlling Desktop session

Inside the affected remote task, the agent performed a direct ALL_TOOLS inventory search for:

list_threads
read_thread
wait_threads
send_message_to_thread

None of those native task tools were present. The only search result was an unrelated Codex Security cancellation tool whose description happened to contain the phrase "Codex thread". The agent therefore correctly reported that the native coordination tools were not exposed and did not use an app-server, rollout, or repository fallback.

As a control, from another Desktop task in the same controller session, exact read_thread and wait_threads calls against the affected remote task and host projection succeeded. They resolved the task as idle/completed. This rules out a disconnected host, missing task, or bad host selection as the reason for the target task's reduced tool surface.

This extends both variants already documented here:

unlike the issue body's fresh 0.148 task, the read side was also absent;
unlike the earlier 0.147 report where read/list/wait worked and only send hit the migration rejection, this retained 0.147 task had no callable read, wait, list, or send tool at all.

Expected: first-party task-tool migration and per-task injection should be atomic. A Remote SSH task should not receive Desktop coordination instructions while the entire corresponding native tool family is silently omitted.

No task IDs, hostnames, addresses, repository names, paths, prompts, credentials, or account data are included.

The issue can be solved by downloading the previous Windows build from the OpenAI CDN https://persistent.oaistatic.com/codex-app-prod/releases/26.810.7004.0/ChatGPT-x64.msix and then reinstalling it:

Add-AppxPackage `
  -Path "$HOME\Downloads\ChatGPT-x64.msix" `
  -ForceUpdateFromAnyVersion `
  -ForceApplicationShutdown

It's a bug in the new app.

Reproduced on local Windows Desktop, not Remote SSH.

Desktop: 26.820.7780.0
App-server: 0.150.0-alpha.8

Existing local task advertises legacy dynamic list_projects,
create_thread, and fork_thread tools. Every invocation returns:

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

Full app restart and Windows reboot did not help. Logs show the
app-server connected, thread_tools enabled, the request reaching
the dynamic renderer, and success=false. The direct codex_app MCP
replacement is not exposed to the task.

This broadens #40865 from Remote SSH to Windows Desktop/local host.

I am seeing this too on Windows Codex Desktop with a managed Remote SSH host. Fresh remote tasks keep list_threads, read_thread, and wait_threads, but lose send_message_to_thread, create_thread, fork_thread, and handoff_thread. The same local Desktop task can still send a message to the remote task successfully, so the connection and destination are healthy. This appears to match the missing codex_app replacement/injection problem described here.

+1 This is a really frustrating regression

Happening on MacOS

Update — 2026-08-27: reproduced in a fresh task on stable 0.150.1 after SSH restart

I tested the remote-runtime update and a full SSH reconnection as possible recovery steps. They did not restore the bridge. This update does not change the causality boundary in the issue body: the initial regression was first observed before the remote runtime was updated.

After updating the remote host and restarting the SSH-backed Desktop connection, I created a brand-new Desktop task on the same Remote SSH project rather than reusing a retained task.

Confirmed from the fresh task:

installed Codex CLI: 0.150.1
running app-server: 0.150.1
the fresh task's own session metadata records cli_version: 0.150.1
codex queue is available

The inter-task bridge is still unavailable:

no callable codex_app__create_thread
no callable codex_app__send_message_to_thread
no callable codex_app__handoff_thread
no codex_tui namespace or other callable replacement for these operations

Direct probes returned:

TypeError: tools.codex_app__create_thread is not a function
TypeError: tools.codex_app__send_message_to_thread is not a function

No new task was created, and no callback/message could be delivered.

This rules out the following as sufficient explanations or recovery steps:

a stale retained-task manifest alone
the previously installed 0.145.0 or 0.148.0 remote CLI
an old app-server process surviving the update
an SSH reconnect/restart being required to provision the replacement tools

The evidence continues to point to Desktop-side tool projection/provisioning for the Remote SSH task surface rather than the remote CLI/app-server version. Official OpenAI documentation also still describes Remote as supporting starting new chats and sending follow-up instructions: https://learn.chatgpt.com/docs/remote-connections

I worked around it by explicitly registering the bundled Codex app-tools MCP server in ~/.codex/config.toml:
[mcp_servers.codex_app]
command = "cmd.exe"
args = [
"/d", "/s", "/c", "call",
'C:\Users<user>.codex\plugins\cache\openai-bundled\codex-app-tools<version>\scripts\launch_codex_app_tools_mcp.cmd',
'C:\Users<user>.codex\plugins\cache\openai-bundled\codex-app-tools<version>\server.mjs'
]
enabled = true
default_tools_approval_mode = "approve"
startup_timeout_sec = 10
tool_timeout_sec = 3600

[plugins."codex-app-tools@openai-bundled"]
enabled = true
After restarting Codex, I tested from a newly created task:

Confirmed the MCP server advertised create_thread.
Created a projectless task using GPT-5.6 Sol with High reasoning.
Confirmed the child task ran successfully and replied, “Task delegation is working.”
One wrinkle remained: an older, long-running task continued resolving create_thread through the retired dynamic-tool shim, apparently because its tool registry was established before the configuration change. Newly created tasks used the MCP server correctly.
For that existing task, I temporarily invoked the configured MCP server through the app-provided CODEX_APP_TOOLS_PIPE_PATH and CODEX_THREAD_ID. That allowed calls to list_projects, create_thread, set_thread_title, and read_thread. This was only a compatibility workaround; the preferred solution is for existing tasks to refresh their tool registry and resolve create_thread through the configured codex_app MCP server automatically.

I published an experimental workaround for the Linux/Remote SSH variant of this issue:

https://github.com/xukp20/codex-app-task-channel

It connects directly to the Unix socket owned by the running Codex Desktop App Server rather than starting a separate app-server daemon, so created and resumed tasks remain visible in the Desktop sidebar.

It provides fallback create/fork/read/message operations when built-in task tools such as create_thread or send_message_to_thread are missing or reject the call. It also exposes guarded per-task configuration including model, reasoning effort, service tier, context window, and auto-compaction threshold.

I validated it against Codex CLI/App Server 0.150.1 on a Linux Remote SSH host. It is unofficial, experimental, Unix-socket-only, and potentially sensitive to App Server protocol changes. The built-in tools remain preferred whenever they work.

One safety caveat: if a built-in mutating tool returns an ambiguous handler error, inspect task state before retrying through the fallback to avoid duplicate delivery.

Seems that the latest app now works.

@winoros

@winoros Which version? Still receiving this error with latest update available (macOS Version 26.825.41651)

"This app tool is no longer available through dynamic tools. Use the codex_app MCP server."

@winoros Which version? Still receiving this error with latest update available (macOS Version 26.825.41651)

"This app tool is no longer available through dynamic tools. Use the codex_app MCP server."

My Windows app version is 26.825.51511. Seems that it's higher than 41651...

A concrete user-experience consequence of this missing effectful task surface:

I am trying to use one supervisory ChatGPT Work conversation on iOS to coordinate GitHub work across paired Remote hosts. Native Remote lets me enter a host-specific conversation, but the supervisory conversation cannot create or hand off a task to a named connected host, send follow-ups, wait for completion, or receive the result back. I therefore have to switch among conversations and manually relay context, status, and outputs between them.

This becomes more than navigation friction when the remote task reaches GitHub publication. An unattended host may attempt shell-level git push and stop on device-code authentication, even though GitHub is already authorized through the user's connected GitHub app. The user may have dispatched the task precisely because they are away from that computer.

The missing first-party tools described in this issue appear to be the correct primitive. The desired flow is:

From the current supervisory conversation, list eligible connected hosts and saved projects.
Create or hand off a normal user-visible task to a selected host/project.
Send follow-ups and inspect/wait for status without changing conversations.
Return the worker's completion, diff, tests, and blockers to the supervisory conversation automatically.
Allow subsequent publication through the existing authenticated GitHub connection, without exporting its credentials to the host or initiating interactive GitHub authentication there.

This does not require exposing the Remote backend as a public API. A properly provisioned first-party codex_app MCP surface with scoped create_thread, send_message_to_thread, handoff_thread, read/wait, and completion-delivery semantics would address it.

The core product expectation is simple: paired computers should function as dispatchable execution locations within an ongoing conversation, not as separate conversational islands that require the user to act as the message bus.

@Hedgeinform

@Hedgeinform any reason for not updating #40852 instead of duplicating effort here?

Maintainers: could you confirm whether the Remote SSH task-tool regression in this issue is intended behavior or tracked for remediation? Fresh Remote SSH tasks still expose read/list/wait while create_thread and send_message_to_thread are absent, which prevents first-party task coordination. We have confirmed inbound local-to-remote delivery but not remote-to-task write export. We are intentionally not relying on App Server, custom MCP registration, or manual relay. If a fix is planned, could you share an ETA, target release, or supported temporary mitigation? If this issue is a duplicate, please identify the canonical tracker.

Maintainers: could you confirm whether the Remote SSH task-tool regression in this issue is intended behavior or tracked for remediation? Fresh Remote SSH tasks still expose read/list/wait while create_thread and send_message_to_thread are absent, which prevents first-party task coordination. We have confirmed inbound local-to-remote delivery but not remote-to-task write export. We are intentionally not relying on App Server, custom MCP registration, or manual relay. If a fix is planned, could you share an ETA, target release, or supported temporary mitigation? If this issue is a duplicate, please identify the canonical tracker.

A workaround in the meantime: #40852 (comment)

Still reproducible on Windows Desktop 26.915.31945 + remote 0.154.0

Reproduced again on 2026-09-19 after updating the Microsoft Store ChatGPT/Codex Desktop app to 26.915.31945, updating the Ubuntu remote CLI/App Server to 0.154.0, rebooting, and reconnecting through the app's built-in SSH feature.

In the SSH-backed task:

list_threads works
read_thread works
wait_threads works
retained codex_app__send_message_to_thread still rejects with the exact migration message from this issue:

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.

No singular callable mcp__codex_app__* replacement is present, and readback confirmed that the rejected probe was not delivered.

Full sanitized environment and tool-surface evidence is posted in #42973: #42973 (comment)

This confirms that upgrading the remote runtime to 0.154.0 and the Windows Store Desktop app to the 2026-09-18 build does not yet restore the SSH delegation bridge.

Fair question. I filed #40865 separately because #40852 was initially scoped as a local/macOS code-mode tool-surface report, whereas this report preserved a Remote SSH-specific causality chain: the first rejection occurred on 0.145.0 before the remote CLI update, and fresh tasks after the update still had neither legacy write tools nor a callable codex_app replacement.

The reports have now converged. #40852 has accumulated current Remote SSH reproductions and the most complete temporary bridge information, so I will treat it as the canonical tracker for future evidence rather than duplicate further reports here.

I am not closing #40865 as resolved: it continues to document the Remote SSH routing/provisioning boundary and has a newer independent reproduction after Desktop and remote-runtime updates. Maintainers: please mark one of the two issues as the canonical duplicate relationship if you consider the underlying defect identical; otherwise, please clarify the distinct supported behavior.

Navigation Menu

Repository navigation

[Desktop Remote SSH] inter-task tools stopped before update; 0.148 lacks codex_app MCP replacement #40865

Summary

Environment

Observed timeline (UTC)

Reproduction

Expected behavior

Impact

Causality boundary

Update — 2026-08-27: reproduced in a fresh task on stable 0.150.1 after SSH restart

Still reproducible on Windows Desktop 26.915.31945 + remote 0.154.0

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Desktop Remote SSH] inter-task tools stopped before update; 0.148 lacks codex_app MCP replacement #40865

Description

Summary

Environment

Observed timeline (UTC)

Reproduction

Expected behavior

Impact

Causality boundary

Activity

github-actions commented on Aug 26, 2026

linonetwo commented on Aug 26, 2026

nos1609 commented on Aug 26, 2026

winoros commented on Aug 26, 2026

stuartbrudner-beep commented on Aug 26, 2026

arthurlapertosa commented on Aug 27, 2026

mattLummus commented on Aug 27, 2026

Hedgeinform commented on Aug 27, 2026

Update — 2026-08-27: reproduced in a fresh task on stable 0.150.1 after SSH restart

stuartbrudner-beep commented on Aug 27, 2026

xukp20 commented on Aug 29, 2026

winoros commented on Aug 30, 2026

mattLummus commented on Aug 30, 2026

winoros commented on Aug 31, 2026

OwenTanzer commented on Aug 31, 2026

saidelike commented on Sep 9, 2026

mppcoder commented on Sep 10, 2026

saidelike commented on Sep 10, 2026

nanyeglm commented on Sep 19, 2026

Still reproducible on Windows Desktop 26.915.31945 + remote 0.154.0

Hedgeinform commented on Sep 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions