Repository navigation
[macOS Desktop 26.820.60940] code-mode tasks omit send_message_to_thread while read tools remain #40852
Description
What version of the Codex App are you using?
- ChatGPT / Codex Desktop:
26.820.60940(build7119) - 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(build25F84) - 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_threadsread_threadwait_threads- title/archive/pin helpers
But the effectful task tools are omitted from the callable tool catalog, including:
send_message_to_threadcreate_threadfork_threadhandoff_threadautomation_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?
- Run Codex Desktop
26.820.60940with bundled CLI0.150.0-alpha.8on macOS. - Open a code-mode task with an authenticated ChatGPT account.
- Ask the task to coordinate an existing Codex task.
- Confirm
list_threads,read_thread, andwait_threadsare callable. - Resolve an exact existing destination using
remote-ssh-discovered:<host>.local. - Attempt one user-authorized
send_message_to_thread. - Observe that the tool is absent from the callable catalog / is not a function.
- 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.
Activity
mokiYang commentedon Aug 26, 2026
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:
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.
genzorr commentedon Aug 28, 2026
Update: build 7303 static audit + working rollback control
I inspected the current macOS ARM64 production release, Desktop
26.825.32147/ build7303. The bundle contains:0.150.0-alpha.12.2codex-code-mode-host:0.150.0-alpha.12.2codex-app-toolsplugin:0.1.3Static inspection found the same relevant composition still present: the five effectful thread tools are removed from the nonlocal task-start catalog, legacy dynamic calls are rejected in favor of the
codex_appMCP server, and the replacement MCP is provisioned only on the local-host path. A newer bundled CLI therefore does not by itself establish that the Remote SSH regression is fixed.This is not a runtime reproduction on build 7303; no fresh local-plus-Remote-SSH success test was performed on that build.
As a live control, after rolling Desktop back to the previously working
26.818.61809/ build7019, a fresh local task successfully exposedcreate_threadand created a new user-owned task on a managed Remote SSH host. That isolates the recovery to the Desktop stack rather than the remote CLI or connection.The migration should be atomic: legacy effectful tools should not be removed unless the replacement
codex_appMCP server is already provisioned and callable for that task. A useful regression matrix would cover local vs. Remote SSH, fresh vs. retained tasks, and replacement-present vs. replacement-unavailable cases. Related broader report: #40865.scicolonevalentino commentedon Aug 29, 2026
guys I can't work anymore... how did I solve this? :( it's so frustrating!!!
mattLummus commentedon Aug 29, 2026
+1 having the same issue
hillarylinmd commentedon Sep 1, 2026
Reproduced on 2026-09-01 with ChatGPT/Codex Desktop 26.825.51511 (build 7377), macOS 26.4.1 on Apple silicon. The
codexexecutable on the affected host reports version 0.151.0.In a task attached to a Remote SSH project, the read/helper side remained callable and worked (
list_threads,read_thread,wait_threads, title and archive operations), while the effectful thread tools includingcreate_threadandsend_message_to_threadwere absent from the callable tool catalog.A full quit and reopen of the Desktop app restored a previously wedged archive operation, but did not restore
create_threadorsend_message_to_thread. Retesting after relaunch produced the same missing-tool result. This confirms the regression persists on build 7377.Private project path, host name, and thread identifiers are intentionally omitted.
Samvibed commentedon Sep 2, 2026
Additional reproducible evidence from a Linux SSH remote host on the current stable helper:
Environment:
codex-cli 0.152.1after updating the standalone helper and restarting the user servicethread_source=user), not a subagentObserved in the fresh 0.152.1 rollout metadata:
dynamic_tool_count = 20list_threads,read_thread,wait_threads,open_in_codex, title/archive, and sidebar-management toolscreate_thread,fork_thread,handoff_thread, andsend_message_to_thread;automation_updateis also absentHistorical comparison from the same remote host:
0.149.0recordeddynamic_tool_count = 16create_thread,fork_thread,handoff_thread, andsend_message_to_thread, and the cross-thread workflow was usableUpdating/restarting the SSH app-server and then creating a new top-level thread did not restore the tools, so this is not the stale-helper mismatch described in #41759. The tools are already absent from the initial persisted dynamic-tool manifest, before the model can call them.
This appears to extend the reported behavior from macOS code-mode tasks to Linux SSH Remote tasks on 0.152.1. In the degraded state,
open_in_codexcan still send an artifact/tab toward an existing Mac task, but the VPS task cannot create, hand off, fork, or directly message another task.It would be helpful to clarify whether this sensitive-tool filtering is intentional and, if so, which supported configuration or approval gate is expected to re-enable explicitly user-authorized cross-task coordination.
dexcue commentedon Sep 3, 2026
Reproducing this on the latest macOS Codex Desktop available to me as of 2026-09-03, in a normal local Desktop task (not Remote SSH).
The important impact for my workflow is that
spawn_agentis not an equivalent replacement forcreate_thread.I intentionally use
create_threadto create separate user-owned Desktop tasks/workers with clean, isolated context. This allows a coordinator task to delegate narrowly scoped work to several independent tasks without carrying the parent task's full orchestration/context overhead into every worker.With the current Desktop behavior, the coordinator can no longer use the effectful thread-management surface to create those workers. Falling back to native
spawn_agentmaterially changes the execution model and, in my workloads, consumes substantially more tokens because subagents participate in the multi-agent orchestration/context mechanism rather than behaving as independent Desktop tasks.So this regression is not only a UI/task-management inconvenience; it removes a useful cost-control and context-isolation primitive.
Expected behavior:
create_threadwhen the user explicitly authorizes/requests creation of another Desktop task.send_message_to_thread/handoff_threadshould likewise remain available for user-authorized inter-task coordination.spawn_agentas a functional replacement for this use case: internal subagents and independent user-owned Desktop tasks have different lifecycle, context, observability, and token-cost characteristics.This is on macOS Codex Desktop. I can provide the exact About-dialog build/version if maintainers need it for the current release regression matrix.
KyoungsueKim commentedon Sep 6, 2026
I’m seeing a related tool-availability problem in my current Codex desktop session, although the missing tool surface is broader than in the original report.
I asked the agent to inspect the tools actually exposed to the session. It checked both the provided tool definitions and the ALL_TOOLS catalog available through functions.exec.
These tools are all absent:
Unlike the original report, list_threads, read_thread, and wait_threads are also absent in this session. A tool_search discovery tool is not exposed either.
The agent also checked the corresponding JavaScript properties without invoking any actions:
typeof tools.codex_app__send_message_to_thread === "undefined"
The same result was observed for create_thread, fork_thread, handoff_thread, automation_update, list_threads, read_thread, and wait_threads. There were no matching entries in ALL_TOOLS.
Meanwhile, the session’s injected desktop instructions explicitly refer to these thread-management and automation tools and tell the agent to discover and use them. This creates a mismatch between the instructions and the callable capabilities.
Environment:
This confirms that the tools are unavailable to the agent in this session, but does not establish that the underlying cause is identical to this issue. I have not yet verified a before/after version comparison or reproduced it in a second fresh session.
Could this broader omission of both read and write tools be related to the same tool-catalog filtering or exposure mechanism?
saidelike commentedon Sep 9, 2026
Still reproducing with Codex CLI and the running App Server both at
0.153.4on the remote Linux host.SSH-backed tasks retain list/read/wait and title/pin/archive helpers, but lack
create_thread,send_message_to_thread, and a discovery path for their replacements. A fresh SSH-backed task shows the same omission.On local macOS,
mcp__codex_app__create_threadandmcp__codex_app__send_message_to_threadare available. I successfully used that Mac-hosted launcher to create and message a task on the same remote Linux host.This suggests the missing piece is tool exposure to the SSH-hosted launcher; creating and messaging destinations on that host works through the Mac-hosted launcher.
saidelike commentedon Sep 9, 2026
Additional finding on 0.153.4: from the remote Linux host, I connected directly to the running App Server’s Unix socket using its WebSocket protocol. thread/start and turn/start successfully created and messaged a session on that host.
The session appeared under the expected project in my local Desktop app. Follow-up messaging from the remote client worked, and I could open and continue the session directly in Desktop.
The SSH-hosted agent still lacks create_thread and send_message_to_thread. This narrows the observed failure to agent-facing tool availability; the underlying creation, messaging, and Desktop visibility path works.
One integration detail: the remote App Server returned an empty project list, while Desktop associated the new session with the correct saved project.
saidelike commentedon Sep 9, 2026
WORKAROUND
Confirmed a workaround on Linux with Codex CLI/App Server 0.153.4: codex-thread-bridge.
It connects to the existing App Server on the same host. Tested creation, follow-up messaging, isolated Git worktrees, Desktop project visibility, and manual Desktop continuation.
After registering the MCP server on the Linux host and starting a fresh Desktop task, tell the agent:
This is an unofficial workaround; worktrees are bridge-managed, and the native tool availability issue remains.
orosotne commentedon Sep 14, 2026
We are seeing the same missing-tool pattern in another Codex desktop session on September 14, 2026.
Environment:
codex --versionon the remote host reportscodex-cli 0.154.0(the desktop app build has not been verified).Verified in the affected session:
codex_app__list_threadsandcodex_app__read_threadwork; the destination task can be found and read using itsremote-ssh-discovered:…host ID.codex_app__wait_threads,set_thread_title,set_thread_archived, and sidebar helpers are present in the tool catalog.send_message_to_thread,create_thread,fork_thread,handoff_thread, andautomation_updateare absent from the exposed tool catalog (ALL_TOOLS).This matches the read-tools-present / task-send-tools-missing symptom in this issue. We have not independently verified the filtering implementation or established whether SSH contributes to the problem.
Could the maintainers clarify whether this omission is intentional in Code Mode, a regression, or dependent on a feature flag/version, and whether there is a supported way to restore native cross-task messaging?
dex-tripnull commentedon Sep 19, 2026
Corroborating cross-platform occurrence: from a Linux/WSL task launched through Windows Codex Desktop,
list_threads,read_thread, andwait_threadswere callable and resolved the intended task, butsend_message_to_threadwas absent from that task's callable tool catalog. The local Windows Desktop task could still use the native send tool to message the same remote task. This is tool exposure at the SSH-hosted source, not evidence that the destination is unreachable or that a send was rejected. No custom bridge, configuration change, or credential fallback was used. Private host, project, and task identifiers omitted.pimenov commentedon Sep 28, 2026
Confirmed a closely related partial tool-catalog state on current Codex Desktop 26.924.22138, Apple Silicon, Astra.
In an OLD local coordinator task on a Mac mini that previously could manage other Codex threads:
Available:
Missing entirely from the callable catalog:
Important A/B result: a NEW local chat on the SAME Mac mini, same account, same Desktop/CLI environment, and same Astra model receives all seven tools and can successfully create/send/wait/read a child thread.
So this is not an app-version-wide or account-wide lack of capability. It appears to be per-task/session tool-manifest state: an older coordinator remains stuck with the read-only half of the thread API while a fresh task on the same host gets the full effectful tool set.
saidelike commentedon Sep 29, 2026
Workaround above in the time being #40852 (comment)
rtol5 commentedon Sep 30, 2026
Adding an SSH-backed Desktop observation from September 29, with remote CLI 0.159.1 and gpt-6.1-sol. Existing-chat discovery/read tools were exposed, but native
send_message_to_threadandcreate_threadwere absent from the callable catalog. This persisted across fresh chats. Some later bounded read/wait calls also stalled, so read availability is not a blanket reliability claim.We verified a limited workaround through the existing daemon's
codex app-server proxy, using its WebSocket transport:turn/steerwithexpectedTurnIddelivered to an actively running persistent peer, and request-specific readback confirmed the same turn.codex queue --thread ... --message ...accepted deferred input; unloaded targets did not wake in our bounded tests.thread/startcreated persistent independent roots with initial prompts. Fresh chats ran and used our MCP tools; native sidebar/project catalog verification was not re-established in the final run.We wrapped the verified path in a local stdio MCP server with restricted operations and durable idempotency receipts. A fresh chat returned a substantive result to an active coordinator. We started no replacement daemon and passed no target model/permission overrides.
The important use case is a release coordinator contacting existing independent feature-owner chats, preserving each owner's implementation history and branch/worktree context. The coordinator must return findings to those same owners and collect their fixes.
This workaround does not restore native peer provenance: inputs look like user messages, so we add a display-only peer header. It also does not solve unloaded wake-up or all Desktop creation behavior.
Is there a supported way to expose the first-party sender/creation tools for SSH-backed chats? If availability is intentionally restricted, a structured capability diagnostic would help distinguish that from a missing handler or an inaccessible backend.
rtol5 commentedon Sep 30, 2026
Update to my September 29 SSH report: we now have a bounded native messaging workaround using the official Linux Desktop 26.928.21956 alongside the original remote app-server 0.159.1, exposing its unmodified app-tools MCP server through a user-configured binding.
Unlike our earlier queue/steer adapter, this produced actual
codex_delegationprovenance. An existing unloaded owner received the request and returned natively under its original UUID; its model, effort and approval policy matched before/after. The original server and conversations remained in place.This is not restoration of the standard SSH tool catalog. It requires a separate Desktop sidecar; concurrency, restart behavior and VM-to-Mac-local sending remain unqualified. I am putting the detailed version/architecture/test evidence in #42973, which directly covers headless SSH delegation and requests a supported bridge.
Could the supported SSH integration expose this native route without the sidecar? The existing-peer release-coordination workflow needs the original owner's context and native sender identity, rather than replacing owners with new workers.
dprestudiocontable-a11y commentedon Sep 30, 2026
I’m experiencing a related issue on Windows with a Pro account. The app’s update check reports version 26.928.21956, build 12404, prod, up to date.
My existing local chat has codex_app.send_message_to_thread and successfully sent a message to my dot. The dot received it, but has no corresponding native tool to reply to that same local chat. Mentioning the exact local chat with @ did not expose the tool. My computer is connected and authorized.
codex-app-tools@openai-bundled is installed and enabled (0.1.5). A separate diagnostic task started from dot also lacked the sending tool. Reading the local chat works.
A separate attempt through an auxiliary app server failed with “already has an active writer” before turn/start. This may be a separate limitation; no cause has been established.
Feedback ID: 01a0eff1-5733-7046-8751-5861dc6080c5
Is there a supported way to enable the return path from dot to an existing local chat, preserving its history?
acefesan commentedon Oct 6, 2026
I can reproduce the same read/write split in a Linux remote-SSH Codex session:
list_threadsandread_threadare available and successfully show other Codex tasks, butsend_message_to_threadandhandoff_threadare absent from the callable tool catalog. This blocks contacting existing sibling/project threads even though they are discoverable. My session is in a life-tracker workspace; destination threads were in separate nutrition-tracker and dl_bio workspaces. I did not attempt CLI or app-server workarounds.Frequency7032 commentedon Oct 6, 2026
Additional redacted observation on 2026-10-06, from a cloud-backed Codex chat accessed through the desktop app with local and remote Mac project chats visible.
Observed in this session:
codex_app__list_threads,codex_app__read_thread,codex_app__wait_threads, andcodex_app__list_projectsare present in the callable catalog.codex_app__send_message_to_thread,codex_app__create_thread,codex_app__fork_thread, andcodex_app__handoff_threadare absent fromALL_TOOLS.typeof tools.codex_app__<tool>checks for each of those four methods returned"undefined".The user explicitly requested contacting existing chats, then creating replacements in their projects, then creating a replacement cloud chat to test whether it could communicate. All three paths were blocked by the missing callable methods. No send/create call was made, so this is tool exposure rather than a reported delivery failure.
Reproduction in the affected session:
Expected: expose the supported permission-scoped methods for explicitly user-authorized actions, or provide a structured availability explanation and supported recovery route. Read access alone leaves coordination unusable, and missing creation/handoff also blocks testing a fresh replacement.
Current desktop/CLI versions and the root cause were not verified here. This observation does not establish that the older version-specific filtering explanation applies, or that every cloud session is affected.
Privacy: chat IDs, host IDs/names, project names/paths, account details, work topics, and conversation transcripts have been omitted. This is a sanitized capability report only.
D4ttara commentedon Oct 7, 2026
This looks related at the control-plane level to #51805.
This issue shows an effectful first-party capability disappearing from the callable catalog while read-side capability remains. #51805 shows a different manifestation: local execution that had been usable in Chat is no longer callable there, and the task is forced through a Work handoff.
In both cases the key missing primitive is a structured explanation of why an effectful capability is absent: policy restriction, rollout, client/session mismatch, entitlement, or deliberate product routing.
Cross-link: #51805
D4ttara commentedon Oct 8, 2026
A relevant new data point for disappearing capabilities: on Oct 7 my assistant claimed direct local MCP calls were forbidden without Work; on Oct 8 Desktop Commander Remote was directly callable in ordinary Chat again. Different tools from this report, so not proof of the same root cause, but another reason to expose capability/routing decisions clearly. Full evidence: #51805 (comment)
Frequency7032 commentedon Oct 12, 2026
Related runtime send failure (2026-10-12)
I hit a related but distinct failure while using the native
send_message_to_threadcapability from a coordinator task. On multiple explicitly user-authorized attempts to message an existing remote project task, the tool returned:A read-only destination snapshot showed the task idle with no new turn, and a one-minute follow-up check still found it idle. The requested instruction was therefore not delivered. Task IDs, host details, and project names are omitted.
This differs from the missing-tool symptom reported above: here the send method was present and callable, but its submission was rejected as unconfirmed. The exact cause is unknown. Please investigate how the app reconciles prior turn submissions and reports delivery state, and provide a supported recovery path that avoids both silent non-delivery and duplicate sends.