Repository navigation
Remote-started Codex thread does not receive codex_app thread-management tools #26907
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.602.40724
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
When starting a Codex thread remotely from my MacBook against my Mac Studio, the agent does not get access to codex_app thread-management tools like create_thread, list_threads, read_thread, etc. A thread started directly on the Mac Studio does receive those tools.
e.g.:
Remote-started thread only received:
codex_app.read_thread_terminal
Mac Studio-started thread received:
codex_app.create_thread
codex_app.fork_thread
codex_app.handoff_thread
codex_app.list_threads
codex_app.read_thread
codex_app.send_message_to_thread
codex_app.set_thread_pinned
codex_app.set_thread_archived
codex_app.set_thread_title
plus automation_update, read_thread_terminal, and workspace dependency tools
MacBook can also manage it's own threads. Remote-started threads should receive the same app/thread-management codex_app tools as equivalent local Codex App threads, or the difference should be documented/intentional.
Checked the metadata of direct vs. remote threads, and they were identical:
originator: Codex Desktop
cli_version: 0.137.0-alpha.4
source: vscode
cwd: same
model: gpt-5.5
reasoning_effort: high
same sandbox/approval mode
So this appears to be a per-thread dynamic tool manifest difference, not a model, sandbox, cwd, repo, or app-version difference.
What steps can reproduce the bug?
Prompt w/ "Please create a new Codex app thread" in two separate threads:
- One in the Codex app directly from your primary machine
- One in the Codex app from another machine that is remotely connected to the primary machine
What is the expected behavior?
Both threads should have the ability to create and manage Codex threads.
Additional information
No response
Activity
github-actions commentedon Jun 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
kweiberth commentedon Jun 7, 2026
I had Codex dig into both the public
openai/codexrepo and the installed Codex Desktop bundle. Maybe this is helpful?In the public repo, the app-server does not synthesize
codex_appdynamic tools. It only accepts the client-provideddynamicToolsarray onthread/start, validates it, persists it, and passes it into the thread:codex-rs/app-server-protocol/src/protocol/v2/thread.rs:ThreadStartParams.dynamic_toolscodex-rs/app-server/src/request_processors/thread_processor.rs:dynamic_tools.unwrap_or_default(), thenvalidate_dynamic_tools(...), thenStartThreadOptions { dynamic_tools: core_dynamic_tools, ... }So if a thread starts without
create_thread,list_threads, etc., the missing tools were already absent from the Desktop/client-sidethread/start.dynamicToolsmanifest.I also inspected the installed Desktop app’s extracted/minified bundle. In
webview/assets/app-server-dynamic-tools-DdL_KkKV.js, the thread-management tools are created by a factory that includes:fork_threadhandoff_threadcreate_threadlist_threadsread_threadsend_message_to_threadset_thread_pinnedset_thread_archivedset_thread_titleBut the exported dynamic-tool builder gates those tools roughly like this:
That explains the observed behavior: a thread started directly on the Mac Studio passes this local-host check and gets the full
codex_appthread-management tool set. A thread started from a MacBook controlling the Mac Studio hashostIdfor the remote Mac Studio, but the controlling Desktop context is notkind: "local"for that host, so the thread-management tools are filtered out before thread/start is sent. The only tool left isread_thread_terminal.Suggested fix: do not gate thread-management dynamic tools solely on host_config.kind === "local". For remote/proxied hosts, include the thread-management tools when the controlling client can route/service those calls for the target host and features.thread_tools is enabled.
ThibaultCastells commentedon Jun 12, 2026
I’m seeing what looks like the same Remote Control / codex_app boundary, but as a runtime refusal rather than only a missing-tool manifest. Here is what Codex says about it:
From a Remote Control session,
codex_apptools can be discoverable, but calls fail with local-thread guard errors, e.g.:I also saw the same class of failure for automation/workspace tools:
I’m intentionally omitting local paths and full thread IDs from this public report. The important shape is:
This suggests the issue is broader than automation_update. The local-only guard appears to be evaluated against the Remote Control caller host rather than the target thread/owner host. That would explain both cases:
This seems related to #26178, where set_thread_title was exposed but refused at runtime.
johnsilvavlogs commentedon Jun 17, 2026
Additional evidence from a recurring macOS Desktop / Remote Control occurrence on 2026-06-17.
Surface: a Codex Desktop session controlled through the remote/mobile surface for
Johns-MacBook-Pro.local. The thread started without visible thread-management tools from the beginning.Local versions/state:
26.611.62324, build4028(matches current appcast at the time of testing)26.3arm64codex-cli 0.140.0-alpha.19state_5.sqlite: created2026-06-17 15:06 BRT,cli_version=0.140.0-alpha.19,model=gpt-5.5,reasoning_effort=xhighthread_dynamic_toolsrows for the affected thread:0list_threads read_thread create_thread fork_thread send_message_to_thread set_thread_title set_thread_pinned set_thread_archived handoff_thread Codex thread management) returned only unrelated Vercel toolbar/GitHub review-thread tools; nocodex_appthread-management tools were exposed to the agent.The stronger new signal is a stale Remote Control app-server version rejection in the Desktop logs. The current Desktop repeatedly tried to connect to an older remote-control host and rejected it as below the minimum app-server version:
Same version-rejection pattern appeared earlier in the day as well (
00:43Z,13:40Z,14:48Z,17:33Z,17:38Z,17:55Z). The localremote_control_enrollmentstable only showed the newerJohns-MacBook-Pro.localenrollment, so the rejectedenv_e_6a0761...host looks like a stale/bootstrap Remote Control connection rather than the currently installed app bundle.This seems to add another concrete axis to this issue: a remote-controlled thread can start with no
codex_appthread-management manifest while Desktop also has a rejected stale Remote Control app-server host (0.137.0-alpha.4) below the current minimum (0.139.0). Ideally, Desktop should either ignore/prune stale below-minimum remote hosts before constructing the dynamic tool manifest, or surface a clear recoverable state instead of silently starting the agent withoutcreate_thread/list_threads/read_thread.Local containment applied on this machine: the global npm-installed
@openai/codexwas also stale (0.135.0) even though the app bundle was current, so I updated the global CLI to0.140.0. That removes one possible below-minimum app-server launch path for future sessions, but it does not repair already-started threads because their dynamic tool manifest is fixed at thread start.Related adjacent symptom: #28080 covers the case where thread tools are exposed and then lose handlers later. This occurrence is the “missing from thread start / remote-control path” shape, so it still looks closest to this issue.
zoomerland commentedon Jun 21, 2026
I can add a Windows + Android reproduction that looks like the same boundary, with a tighter A/B control.
Environment:
A/B result on the same machine/account/build:
Existing Desktop-created thread, later controlled from Android/mobile:
tool_searchexposescodex_app.create_thread,codex_app.list_threads,codex_app.read_thread,codex_app.send_message_to_thread,codex_app.set_thread_title,codex_app.set_thread_archived, andcodex_app.automation_update.Fresh thread created directly from the laptop/Desktop UI:
tool_searchexposes the samecodex_appthread-management tools.Fresh thread created from Android/mobile for the same Desktop host:
tool_searchreturns onlymulti_agent_v1.spawn_agent; there is nocodex_appnamespace and nocreate_thread/list_threads/automation_update.So the differentiator does not appear to be OS, account, app version, or simply “new thread”.
It appears to be the client/path that creates the thread.
The confusing part is that the mobile-created thread still records:
originator: Codex Desktopsource: vscodeSo those metadata fields are not enough to diagnose whether the thread received the local/Desktop app-level dynamic tools.
This matches the earlier local-host gating hypothesis in this issue: a mobile-created thread may be treated like a non-local/proxied creator path, so Desktop filters out thread-management
codex_apptools beforethread/start.dynamicToolsis persisted.Expected behavior:
If the target Desktop host can service
codex_appthread-management calls, a thread created from mobile/remote control should receive the same thread tools as a Desktop-created thread. If this is intentionally unsupported, the UI/tool surface should expose a clear capability reason instead of silently returning only multi-agent tools.zoomerland commentedon Jun 21, 2026
Additional confirmation from a second Windows machine:
A previously existing / Desktop-originated thread on that machine does expose the
codex_app.*tools and was able to create a new mobile-visible project successfully.So this does not appear to be only a machine-level install/version/plugin availability issue. On the same account and target host, the availability of
codex_apptools appears to be per-thread / per-thread-creation-path.Working workaround:
Use an existing Desktop-originated thread with
codex_app.*, or create the controlling thread directly from Codex Desktop UI on the target machine. After that, mobile/remote can continue using that thread and the app-level tools remain available.Failing path:
Threads created from the mobile/remote surface may start without
codex_app.*; those threads cannot perform the same project/thread-management workflow.fujiwarakasei commentedon Jun 30, 2026
Adding user-impact confirmation from a phone-first / desktop-continuation workflow.
The important product issue here is not only the missing tool list. A mobile-created or remote-created Codex thread can look like a normal Desktop-controlled host thread, but its tool surface can differ from a thread created directly from Desktop. That makes the same workflow behave differently depending on where the thread was born.
Current environment where this matters:
26.623.70822, build4559codex-cli:0.142.425.4.0arm64User-visible failure shape:
codex_app.create_thread,codex_app.list_threads,codex_app.read_thread,codex_app.send_message_to_thread,codex_app.set_thread_title, etc. are expected to be available.Expected behavior:
If the target Desktop host can service
codex_appthread-management calls, a thread created from mobile/Remote Control should receive the same thread-management tools as a Desktop-created thread. If that is intentionally unsupported, the UI/model surface should expose a clear capability reason before or at thread creation, instead of silently creating a thread that behaves differently.The current workaround described above -- create the controlling thread directly from Desktop first, then continue from mobile -- is useful, but it defeats the phone-first use case where mobile is supposed to be a reliable control plane for the Desktop host.
AiurArtanis commentedon Jul 6, 2026
Hoping St.Tibo @tibo-openai fixes this bug soon, preferably bundled with a shiny new release and a fresh batch of resets.
kendonB commentedon Jul 26, 2026
They make a big deal on X that codex should be able to control codex but actually it can't
rcbeall1 commentedon Aug 6, 2026
Yup, I have been having the exact same experience for months! It has made it impossible for me to run my workflows the way I want. I have switched to using Cursor Remote Control. I can handle all thread management via the Cursor API. It is a much better experience. Really disappointing that OpenAI has not fixed this!
ropepop commentedon Aug 10, 2026
Same here with a custom-model setup: macOS Codex app with a custom provider. Desktop-created threads get the full tool set, but the same thread opened from mobile remote behaves differently — reduced tool manifest and no middle-step rendering (reasoning/tool calls) even though desktop shows them. This confirms the remote path applies a different tool/render policy than local threads. Related: #32553 (Android), #31370 (mobile-created custom-provider threads), #37598 (remote rendering).
xiaokening commentedon Aug 26, 2026
Additional Windows + SSH reproduction on the current release.
Environment:
OpenAI.Codex 26.820.7780.00.149.1A/B result:
codex_app.send_message_to_threadand sent a unique diagnostic prompt to an idle remote SSH thread.The remote thread reported:
The current Desktop state also shows
codex_appregistered only forhostId = local; there is no correspondingcodex_appcatalog entry for the remote SSH host. The local catalog includessend_message_to_thread,list_threads,read_thread,create_thread,wait_threads, and the other thread-management tools.This isolates the failure from SSH, authentication, the target-thread state, and the message backend: local -> remote delivery works, while a remote SSH thread cannot act as the sender because its dynamic tool manifest lacks
codex_app.This is still reproducible on
26.820.7780.0.moxi000 commentedon Sep 7, 2026
I encountered the same issue. The description above is already clear enough, so I will not add any additional information. I hope the official team can fix this issue as soon as possible.
Malvezio commentedon Sep 15, 2026
Additional iOS Remote + Linux SSH reproduction, observed on 2026-09-15 with
codex-cli 0.153.4.A thread started from iOS Remote did not receive
create_thread,list_threads,wait_threads, orset_thread_archived. A Desktop-originated thread for the same workflow can receive the thread-management tools.User-visible impact: an agent running in the Remote-started thread could not perform the same task-lifecycle operations available from Desktop. In particular, it could not archive the current task through the agent tool, so manual cleanup in the UI was required.
Expected behavior: Remote-started threads should receive the same thread-management tools when the connected host can service them. If that is intentionally unsupported, the capability difference should be surfaced clearly before the agent begins a task-management operation.
pimenov commentedon Sep 28, 2026
Confirmed the remote-vs-local difference on current Codex Desktop 26.924.22138.
Setup:
REMOTE-started new task on the Mac mini (started from the MacBook):
Available:
Missing:
A NEW task started directly/locally on the SAME Mac mini gets the full seven-tool set and successfully performs create_thread -> send_message_to_thread -> wait_threads/read_thread.
This also makes the two-account setup unlikely to be the primary cause, because the Mac mini account can expose the full tool family to a fresh local task; the capability loss appears specifically tied to the remote-started task path.
rtol5 commentedon Sep 30, 2026
Related SSH-backed observation on September 29, remote CLI 0.159.1: fresh Desktop chats exposed read-side peer discovery, but native
send_message_to_threadandcreate_threadremained unavailable. This is a partial-surface variant rather than a reproduction of every tool being absent.The same existing daemon accepted
turn/steerthroughcodex app-server proxy; an active persistent peer received and answered the request. We also created persistent roots viathread/startand ran fresh-chat MCP smoke tests. Native sidebar/catalog parity remained a separate unverified step in the final test.That demonstrates some backend functionality is reachable; it does not establish why Desktop omitted the corresponding tools. Our workaround is a local MCP adapter, not a first-party restoration.
A documented local-versus-SSH capability contract, or a way to diagnose the missing app-owned tool registration, would be particularly useful for coordinating independently existing branch-owner chats.