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

[Hedgeinform]

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:

1. 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.
2. 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.

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

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

3. 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.
   

4. 2026-08-26 08:14:52, still before the update: the same rejection reproduced.

5. 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.

6. 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.

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

1. Open a Codex Desktop task backed by a remote Linux host.
2. 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.
3. Observe the migration rejection directing the caller to the codex_app MCP server.
4. Create a fresh Desktop task on the same remote host.
5. Inspect the callable tool inventory.
6. 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

[github-actions]

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

[linonetwo]

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.

[nos1609]

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.

[winoros]

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.

[stuartbrudner-beep]

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.

[arthurlapertosa]

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.

[mattLummus]

+1 This is a really frustrating regression

Happening on MacOS

[Hedgeinform]

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

[stuartbrudner-beep]

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:

1. Confirmed the MCP server advertised create_thread.
2. Created a projectless task using GPT-5.6 Sol with High reasoning.
3. 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.

[xukp20]

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.