[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:

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:

• #39978 — exact dynamic-tools-to-codex_app-MCP rejection on a remote devbox; closed without a public resolution
• #40852 — fresh report where read/list/wait remain but effectful task tools are omitted
• #33598 — earlier broader loss of the Desktop coordinator control surface

Start by reproducing the Remote SSH flow with a retained task on 0.145.0 and a fresh task on 0.148.0, then inspect the task-tool provisioning, dynamic-tool routing, and codex_app MCP catalog paths. Compare the callable tools with the injected Desktop guidance and related issues #39978 and #40852. Done means the migration is atomic, or a structured diagnostic explains why task creation and messaging are unavailable.