[macOS Desktop 26.820.60940] code-mode tasks omit send_message_to_thread while read tools remain

[alexander-dreyzen]

What version of the Codex App are you using?

• ChatGPT / Codex Desktop: 26.820.60940 (build 7119)
• Bundled CLI: codex-cli 0.150.0-alpha.8
• Prior working CLI/session comparison: 0.149.0-alpha.4.1

What platform is your computer?

• macOS 26.5.2 (build 25F84)
• Apple Silicon / arm64

What issue are you seeing?

After the update to Desktop 26.820.60940 / CLI 0.150.0-alpha.8, code-mode Codex tasks no longer receive the complete first-party thread-management tool family.

The read side remains available and works:

• list_threads
• read_thread
• wait_threads
• title/archive/pin helpers

But the effectful task tools are omitted from the callable tool catalog, including:

• send_message_to_thread
• create_thread
• fork_thread
• handoff_thread
• automation_update

The immediate blocker is send_message_to_thread. In two independently bootstrapped Codex tasks, including a worker and coordinator on the same physical host, the exact result was:

typeof tools.codex_app__send_message_to_thread === "undefined"
TypeError: tools.codex_app__send_message_to_thread is not a function

The destination task was uniquely resolved through the correct remote-ssh-discovered:<host>.local projection. Exact destination readback proved that no message input was created, so this is a missing callable-tool problem rather than target discovery, host routing, or an uncertain delivery result.

A retained session from the same environment on CLI 0.149.0-alpha.4.1 successfully called:

await tools.codex_app__send_message_to_thread({
  threadId,
  hostId,
  prompt,
});

The installed 26.820.60940 bundle still contains the send_message_to_thread tool definition, but the updated app code explicitly filters a sensitive-tool set containing automation_update, create_thread, send_message_to_thread, fork_thread, and handoff_thread from code-mode/deferred catalogs unless separately enabled. There is no user-authored mcp_servers.codex_app entry in config.toml.

This leaves app guidance and installed workflows referring to a native task-send capability that the model cannot call.

What steps can reproduce the bug?

1. Run Codex Desktop 26.820.60940 with bundled CLI 0.150.0-alpha.8 on macOS.
2. Open a code-mode task with an authenticated ChatGPT account.
3. Ask the task to coordinate an existing Codex task.
4. Confirm list_threads, read_thread, and wait_threads are callable.
5. Resolve an exact existing destination using remote-ssh-discovered:<host>.local.
6. Attempt one user-authorized send_message_to_thread.
7. Observe that the tool is absent from the callable catalog / is not a function.
8. Repeat in another independently bootstrapped task; the same omission occurs.

What is the expected behavior?

When a user explicitly requests inter-task communication, Codex Desktop should expose the same native app-owned send_message_to_thread capability that worked in 0.149.

At minimum:

• the app instructions and callable tool catalog must agree;
• an explicitly user-authorized send should not require editing config.toml;
• the read and write halves of the thread-management family should not be silently split;
• if the capability is intentionally unavailable, the app should provide a clear structured diagnostic rather than leaving installed workflows to discover a missing function at runtime.

Impact

This breaks established multi-task coordination that requires a visible, source-accounted native send, including discussion, convergence, and handoff workflows. Raw App Server calls or manual/fallback transports are not equivalent because they do not create the same source event and can violate exactly-once/no-resend guarantees.

Unaffected read-only and helper-backed operations continue to work, which makes the regression particularly confusing.

Additional information

No config.toml change was made. The issue reproduces with the correct host projection and in two independent tasks.

Related but not duplicate:

• Fresh local 0.142.0-alpha.1 sessions no longer receive codex_app thread-management tools #29223 — broader reports of fresh sessions losing the thread-management surface
• Remote-started Codex thread does not receive codex_app thread-management tools #26907 — remote-started threads missing thread tools
• [Windows Desktop 26.820.60940] codex_app thread tools prompt on every call and ignore approval_mode override #40793 — same Desktop/CLI build exposes these tools on Windows but prompts on every call

This report is narrower: on macOS build 26.820.60940, read/list/wait remain callable while send_message_to_thread and the other effectful task tools are omitted entirely.

[mokiYang]

I inspected the Desktop 26.820.60940 app bundle and found a client-side filtering path that appears to explain the exact read/write split.

The bundle defines a filter that removes:

• automation_update
• create_thread
• send_message_to_thread
• fork_thread
• handoff_thread

from both top-level dynamic tools and the codex_app namespace.

During thread-start parameter construction, this filter is applied when the source/current task host is not classified as local. The local-host path instead enables the app-owned codex_app tool names through configuration.

This would explain why read-only tools remain available while the five effectful tools disappear on a remote-SSH host projection. The relevant distinction appears to be the source task's host classification, not the destination thread's resolved host.

The public CLI repository also introduced per-surface MCP exposure controls in commit 51c9ed6 (#36781), which is present in the Desktop-bundled 0.150.0-alpha.8 but not in 0.144.6.