Codex Desktop open thread view does not refresh after another app-server client appends a turn

Open 💬 4 comments Opened May 8, 2026 by ferminquant
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Open an existing thread in Codex Desktop.
  2. Start a separate local app-server client with codex app-server --listen stdio://.
  3. From that separate client, call thread/resume for the open Desktop thread.
  4. Call turn/start and wait for completion.
  5. Confirm the new turn is visible through the custom app-server client via thread/turns/list or thread/read.
  6. 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21177
  • #21551

Powered by Codex Action

tlmader · 3 months ago

This blocks a workflow we are trying to build: send GitHub PR comments and reviews into the matching local Codex Desktop thread, so the agent working on that PR can see the feedback and respond in context.

We can write the message to the target thread through the stdio app-server path:

codex app-server --listen stdio://
initialize -> initialized -> thread/resume -> turn/start -> turn/completed

That part works. The turn appears in Codex’s local thread files and is readable through the app-server client.

The problem is that Codex Desktop does not automatically refresh an already-open thread after another app-server client writes to it.

That breaks the expected workflow: leave Codex Desktop open, get PR feedback, and let the local agent pick it up. Users should not have to restart Desktop, reopen the thread, or manually refresh anything.

The fix we need is for Codex Desktop to automatically pick up new turns written to the thread it already has open.

yorkartur · 3 months ago

hey, I'm having the same problem, been trying to programatically add messages or start threads onto Codex, but I can't, it takes some minutes to do so, just saying, this enables to create native apps that live within Codex.

Leonccaa · 2 months ago

I’m seeing what looks like the same issue with first-party Codex Remote clients.

Setup:

  • Remote SSH host: private Linux host
  • Remote Codex CLI/app-server: reproduced on 0.139.0, still reproduces on 0.140.0
  • Clients: Codex Desktop on PC + ChatGPT/Codex mobile remote
  • Same account/workspace, same remote host, same thread

Observed:

  • If I send a message from mobile, the PC’s already-open thread does not live-refresh.
  • If I send a message from PC, mobile does not live-refresh.
  • Restarting/reopening either client makes the missing turns appear.
  • On the remote host, the thread state DB and rollout JSONL update immediately, so persistence is working.
  • The failure appears to be live event subscription/fanout between already-open clients.

This started for me around 0.139.0; it previously worked in the same workflow. Updating the remote CLI/app-server to 0.140.0 did not fix it.

This seems consistent with the issue described here: persisted turns are visible after re-read/resume, but active open clients do not receive invalidation/live updates for externally-appended turns.

If first-party mobile remote should be tracked separately from external app-server clients, I can open a separate issue with sanitized logs and reproduction details.