Repository navigation
Support remote app-server threads in Desktop thread orchestration #25482
Description
Summary
Remote-native Codex threads can be created on an SSH host, but Codex Desktop's local thread orchestration surface cannot list/read/manage those remote threads.
Repro
- Start from a local Codex Desktop host with an SSH remote configured.
- On the remote host, create a native app-server thread in a remote workspace:
ssh <host> 'cd <remote-workspace> && codex debug app-server send-message-v2 "Reply exactly REMOTE_NATIVE_OK"'-
The remote host creates a real Codex thread with:
- remote
cwd - remote rollout under
<remote CODEX_HOME>/sessions/... - remote workspace instructions loaded
- remote
-
From the local Desktop thread orchestration surface, try to inspect that thread:
read_thread(<remote-thread-id>) -> thread not loaded
list_threads(query: <remote-thread-id>) -> no results
Expected
Codex Desktop should be able to treat remote app-server threads as first-class thread targets:
- list/search remote threads by host/workspace
- read remote thread status and recent turns
- create a remote thread with a specific remote
cwd - send follow-up prompts to a remote thread
- rename/title remote threads
- pin/unpin and archive/unarchive remote threads
Actual
The remote thread exists and is durable on the SSH host, but local Desktop thread orchestration cannot see or manage it. The current workaround is to create a local child thread that runs ssh <host> ..., which works but loses native thread identity, sidebar organization, and remote workspace ownership.
Why this matters
A local Director/orchestrator thread should be able to coordinate work across SSH remote workspaces without falling back to shell-level SSH wrappers.
Related
Related but broader/different:
- Make DevBox / SSH remote repositories first-class in the Codex Mac app #23907
- Codex App remote project conversations disappear from local sidebar, but still exist on the remote server #25092
- Mobile Remote Control does not discover SSH remote project threads despite documented remote development environment support #23062
- Add subproject/workspace organization under a single SSH host project #25454
Activity
github-actions commentedon Jun 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
bakemocho commentedon Jun 2, 2026
This seems related to #25914, but not the same issue.
#25914 is about the local Desktop/app-server case: a local external app-server
client can see persisted thread history, but there is no documented way to
discover and attach to the currently active Desktop UI thread/turn as a loaded,
controllable target.
This issue looks like a remote-side form of a similar targetability boundary:
the remote thread exists and is durable on the SSH host, but the local Desktop
thread orchestration surface cannot list/read/manage it as a first-class thread
target.
It may be useful for the app-server/Desktop contract to explicitly distinguish:
That would help both local-current-thread integrations (#25914) and remote
thread orchestration (#25482) avoid guessing from local files, SSH wrappers, or
sidebar/project state.
yanggs07 commentedon Jun 3, 2026
Adding a concrete current-thread tool-gating repro from #26178, which looks like the same remote thread orchestration boundary from a narrower angle.
In a Codex Desktop remote-backed thread:
codex_app.set_thread_titleis exposed/discoverable in the model tool surface.codex_app.set_thread_titlefor the current thread returns:This means the thread-management tool appears available, but the runtime rejects the call because the thread is classified as non-local. That makes it hard for skills/agents to know whether they can safely rename/pin/archive the current Desktop-visible thread. It is the same shape as #25873 for
automation_update, but with thread-title management rather than automations.A useful fix for this umbrella issue would be either first-class support for remote-backed Desktop thread management, or a capability/status signal so remote threads do not expose tools that will later reject with a local-only runtime error.
evelant commentedon Jun 12, 2026
You can actually connect to those threads with desktop, but only by adding a new "project" with the exact cwd of the thread in the remote ssh target. Only exact matches will show in codex desktop, which makes many remote workflows essentially unusable because it means you must create a new "project" for every single thread started remote unless your remote workflow is single-directory-only, which many are not, such as any parallel workflow.