I am evaluating whether a phone-oriented custom client built on codex app-server can create or resume threads that later appear in Codex Desktop history.
I do not need exact live-session takeover. I only need thread continuity:
- create or resume a Codex thread from a different client
- return to Codex Desktop later
- see the same thread and appended messages in the desktop app
I ran a local spike and got results that are promising, but confusing relative to the sourceKinds docs.
Environment
- Codex Desktop
0.118.0-alpha.2
- macOS
26.4.0
- local custom client launched via
codex app-server
- custom
initialize.clientInfo.name = codex_mobile_mirror_spike
- custom
thread/start.serviceName = codex_mobile_mirror_spike
Relevant docs
The codex app-server docs say:
thread/list defaults to interactive sources only: cli and vscode
sourceKinds includes appServer
Source:
Reproduction
- Start
codex app-server.
- Send
initialize with a custom client name.
- Call
thread/start.
- Call
turn/start with a unique marker message.
- Call
thread/read, thread/list, and thread/list with sourceKinds: ["appServer"].
- Call
thread/resume and append a second message with turn/start.
What I observed
thread/start succeeded and created thread 019d4fc4-e260-7373-b36a-1ccf899e4d95.
- After the first turn, default
thread/list included that thread with preview:
APPSERVER-SPIKE-20260402-205636: please reply with a short acknowledgement for interoperability testing.
thread/resume also worked, and a second turn appended successfully.
- The surprising part is that the created thread was reported as
source: "vscode" in:
thread/start
thread/read
- default
thread/list
thread/list with sourceKinds: ["appServer"] returned no results before or after the turns, including for this thread.
Why this is confusing
From the docs, I expected one of two things:
- A custom
app-server client creates appServer threads, and Desktop may or may not show them.
- A custom
app-server client creates vscode-like interactive threads, and Desktop shows them.
In practice, my custom client appears to get the second behavior, but the docs do not explain whether that is expected and stable.
Questions
- Is it expected that a custom client using
codex app-server creates threads that are persisted as source: "vscode" rather than source: "appServer"?
- Is Desktop thread-history visibility for custom
app-server clients considered supported behavior, or is this currently incidental?
- If custom clients are expected to appear in Desktop history, should the docs say that explicitly?
- If
appServer is intended to be a real persisted source kind for custom clients, what conditions actually produce it?
Why this matters
This determines whether it is viable to build a phone-native Codex companion client on top of official APIs instead of relying on remote desktop control.
Remote-control approaches such as Sunshine, Moonlight, and RustDesk can move pixels around, but they are poor fits for Codex's split-pane desktop UI on a phone. Thread continuity is a much better product shape if it is officially supported.
Suggested docs clarification
It would help a lot if the docs explicitly answered one of these:
- Custom
app-server clients create Desktop-visible interactive threads by default.
- Desktop only guarantees history visibility for some thread source kinds.
appServer threads are different from Desktop-visible interactive threads, and custom clients need a specific integration path to get Desktop interoperability.
References
I am evaluating whether a phone-oriented custom client built on
codex app-servercan create or resume threads that later appear in Codex Desktop history.I do not need exact live-session takeover. I only need thread continuity:
I ran a local spike and got results that are promising, but confusing relative to the
sourceKindsdocs.Environment
0.118.0-alpha.226.4.0codex app-serverinitialize.clientInfo.name = codex_mobile_mirror_spikethread/start.serviceName = codex_mobile_mirror_spikeRelevant docs
The
codex app-serverdocs say:thread/listdefaults to interactive sources only:cliandvscodesourceKindsincludesappServerSource:
Reproduction
codex app-server.initializewith a custom client name.thread/start.turn/startwith a unique marker message.thread/read,thread/list, andthread/listwithsourceKinds: ["appServer"].thread/resumeand append a second message withturn/start.What I observed
thread/startsucceeded and created thread019d4fc4-e260-7373-b36a-1ccf899e4d95.thread/listincluded that thread with preview:APPSERVER-SPIKE-20260402-205636: please reply with a short acknowledgement for interoperability testing.thread/resumealso worked, and a second turn appended successfully.source: "vscode"in:thread/startthread/readthread/listthread/listwithsourceKinds: ["appServer"]returned no results before or after the turns, including for this thread.Why this is confusing
From the docs, I expected one of two things:
app-serverclient createsappServerthreads, and Desktop may or may not show them.app-serverclient createsvscode-like interactive threads, and Desktop shows them.In practice, my custom client appears to get the second behavior, but the docs do not explain whether that is expected and stable.
Questions
codex app-servercreates threads that are persisted assource: "vscode"rather thansource: "appServer"?app-serverclients considered supported behavior, or is this currently incidental?appServeris intended to be a real persisted source kind for custom clients, what conditions actually produce it?Why this matters
This determines whether it is viable to build a phone-native Codex companion client on top of official APIs instead of relying on remote desktop control.
Remote-control approaches such as Sunshine, Moonlight, and RustDesk can move pixels around, but they are poor fits for Codex's split-pane desktop UI on a phone. Thread continuity is a much better product shape if it is officially supported.
Suggested docs clarification
It would help a lot if the docs explicitly answered one of these:
app-serverclients create Desktop-visible interactive threads by default.appServerthreads are different from Desktop-visible interactive threads, and custom clients need a specific integration path to get Desktop interoperability.References