Clarify expected codex app-server thread visibility in Desktop history and why custom-client threads are recorded as vscode

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:

• https://developers.openai.com/codex/app-server/#list-threads-with-pagination--filters

Reproduction

1. Start codex app-server.
2. Send initialize with a custom client name.
3. Call thread/start.
4. Call turn/start with a unique marker message.
5. Call thread/read, thread/list, and thread/list with sourceKinds: ["appServer"].
6. 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:

1. A custom app-server client creates appServer threads, and Desktop may or may not show them.
2. 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

1. Is it expected that a custom client using codex app-server creates threads that are persisted as source: "vscode" rather than source: "appServer"?
2. Is Desktop thread-history visibility for custom app-server clients considered supported behavior, or is this currently incidental?
3. If custom clients are expected to appear in Desktop history, should the docs say that explicitly?
4. 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:

1. Custom app-server clients create Desktop-visible interactive threads by default.
2. Desktop only guarantees history visibility for some thread source kinds.
3. appServer threads are different from Desktop-visible interactive threads, and custom clients need a specific integration path to get Desktop interoperability.

References

• Codex App Server docs: https://developers.openai.com/codex/app-server/
• Codex IDE extension docs: https://developers.openai.com/codex/ide/
• Codex repo: https://github.com/openai/codex