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

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

• #40852
• #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:

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.