What issue are you seeing?
I am building a phone/PWA companion client on top of codex app-server so I can continue a local Codex Desktop thread from another device while the PC remains the execution host.
A separate app-server client can successfully resume an existing Desktop-visible thread and append a new turn, but the already-open Codex Desktop thread view does not appear to live-refresh or receive an invalidation for that externally-appended turn.
The turn is persisted and can be read by the bridge immediately. It also eventually appears in Desktop after Desktop later re-reads/resumes the thread, but the timing appears event-driven rather than documented or deterministic.
Environment
- Codex CLI:
0.128.0-alpha.1
- Platform: Windows Desktop app using WSL app-server
- Custom client: local bridge process running
codex app-server --listen stdio://
- Desktop app-server process: launched separately by Codex Desktop over stdio
Reproduction
- Open an existing thread in Codex Desktop.
- Start a separate local app-server client with
codex app-server --listen stdio://.
- From that separate client, call
thread/resume for the open Desktop thread.
- Call
turn/start and wait for completion.
- Confirm the new turn is visible through the custom app-server client via
thread/turns/list or thread/read.
- Return to the already-open Codex Desktop thread view.
Observed behavior
The custom app-server client sees the new turn immediately.
The already-open Desktop thread view does not update immediately. It appears to catch up only later, when Desktop performs its own thread/read / thread/resume again.
Expected behavior
One of the following would make cross-client local continuity much easier to build safely:
- Codex Desktop live-refreshes open thread views when the persisted thread changes.
- App-server exposes a supported request/notification to invalidate or refresh a thread across clients.
- Desktop can connect to a shared app-server transport used by both Desktop and external clients.
- Documentation explicitly states that cross-client live sync is not supported, and that only eventual persisted thread continuity should be expected.
Additional investigation
I looked for a safe nudge path:
codex app-server proxy exists, but the Desktop-launched stdio app-server did not expose /mnt/c/Users/<user>/.codex/app-server-control/app-server-control.sock.
- The open-source app-server code appears to create that control socket only for
--listen unix:// / unix://PATH.
- Calling
thread/read / thread/resume from another app-server connection refreshes that connection, but does not appear to force the already-open Desktop renderer connection to rehydrate.
- I intentionally avoided private stdio pipe writes, direct state edits, item injection, or Desktop app-server restarts because those seem unsafe.
Why this matters
This is the missing piece for a safe phone/PWA companion client for local Codex Desktop sessions. The bridge can already continue the thread through app-server, but Desktop needs a documented/supported way to observe or refresh externally-appended turns.
What issue are you seeing?
I am building a phone/PWA companion client on top of
codex app-serverso I can continue a local Codex Desktop thread from another device while the PC remains the execution host.A separate app-server client can successfully resume an existing Desktop-visible thread and append a new turn, but the already-open Codex Desktop thread view does not appear to live-refresh or receive an invalidation for that externally-appended turn.
The turn is persisted and can be read by the bridge immediately. It also eventually appears in Desktop after Desktop later re-reads/resumes the thread, but the timing appears event-driven rather than documented or deterministic.
Environment
0.128.0-alpha.1codex app-server --listen stdio://Reproduction
codex app-server --listen stdio://.thread/resumefor the open Desktop thread.turn/startand wait for completion.thread/turns/listorthread/read.Observed behavior
The custom app-server client sees the new turn immediately.
The already-open Desktop thread view does not update immediately. It appears to catch up only later, when Desktop performs its own
thread/read/thread/resumeagain.Expected behavior
One of the following would make cross-client local continuity much easier to build safely:
Additional investigation
I looked for a safe nudge path:
codex app-server proxyexists, but the Desktop-launched stdio app-server did not expose/mnt/c/Users/<user>/.codex/app-server-control/app-server-control.sock.--listen unix:///unix://PATH.thread/read/thread/resumefrom another app-server connection refreshes that connection, but does not appear to force the already-open Desktop renderer connection to rehydrate.Why this matters
This is the missing piece for a safe phone/PWA companion client for local Codex Desktop sessions. The bridge can already continue the thread through app-server, but Desktop needs a documented/supported way to observe or refresh externally-appended turns.