## 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 1. Start from a local Codex Desktop host with an SSH remote configured. 2. On the remote host, create a native app-server thread in a remote workspace: ```sh ssh 'cd && codex debug app-server send-message-v2 "Reply exactly REMOTE_NATIVE_OK"' ``` 3. The remote host creates a real Codex thr

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #25092 - #24197 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Support remote app-server threads in Desktop thread orchestration

Open 💬 4 comments Opened Jun 1, 2026 by JiehoonKwak

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

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 but broader/different:

#23907
#25092
#23062
#25454

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

#25092
#24197

Powered by Codex Action

bakemocho · 2 months ago

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:

persisted thread record vs loaded controllable thread;
local app-server process vs remote app-server process;
host/workspace ownership of a thread;
current UI thread vs non-UI/background thread;
unsupported target vs unknown thread id.

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 · 2 months ago

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_title is exposed/discoverable in the model tool surface.
The current thread is visible in the Desktop sidebar.
Calling codex_app.set_thread_title for the current thread returns:

Codex thread tools are only supported for local threads.

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 · 2 months ago

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.