App Server turns on an existing thread complete but are not visible in Codex Desktop UI

Open
#33,650 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Quiet
Domain
api, desktop

Research direction

Reproduce with the stdio App Server flow: initialize, then call thread/read, thread/resume, and turn/start for an existing Desktop thread. Compare the received item/agentMessage/delta and turn/completed events with the open Desktop thread. Done requires a decided and documented synchronization behavior, with visibility or supported inspection if turns are intended to appear.

Written by the indexing model from the issue text.

Description

app app-server bug windows-os
What variant of Codex are you using?

Codex Desktop with the standalone Codex CLI App Server over stdio.

Observed CLI/App Server version:

codex-cli 0.144.5
App Server userAgent: Codex Desktop/0.144.5 (Windows 10.0.26200; x86_64)
Platform
Windows 11 / Windows 10.0.26200
App Server transport: stdio
CODEX_HOME: default user Codex home
What issue are you seeing?

When a local bridge uses codex app-server to send a turn/start to an existing Codex thread id, the background turn runs and completes successfully. The bridge receives the final agent message stream and can store it in an external system.

However, the currently open Codex Desktop thread UI for that same thread does not show the background turn, and the visible conversation context does not know the turn happened.

This makes the thread behave like a background/remote worker rather than a visibly synchronized conversation. The work succeeds, but the human looking at the Desktop thread has no reliable indication that a turn was received, answered, or completed.

Steps to reproduce
  1. Start codex app-server using stdio transport.
  2. Initialize the App Server client.
  3. Call thread/read for an existing Desktop thread id.
  4. Call thread/resume for the same thread id.
  5. Call turn/start with a short prompt on that same thread id.
  6. Read item/agentMessage/delta notifications and turn/completed from the App Server client.
  7. Confirm that the answer stream is received and the turn completes.
  8. Open or watch the same thread in Codex Desktop.
  9. Observe that the Desktop UI does not show the background turn, and the visible conversation context does not include it.
Expected behavior

Please clarify whether App Server turns against an existing thread id are expected to synchronize with the Desktop UI.

If they are expected to be visible:

  • the Desktop thread should show the background turn and final answer;
  • the visible conversation context should reflect that the turn occurred;
  • the user should be able to inspect the turn from the same thread UI.

If they are intentionally background-only:

  • documentation should clearly state that App Server turns may not be UI-synchronized;
  • the Desktop UI should ideally show a background activity marker or notification;
  • App Server should expose stable metadata for background turn provenance and diagnostics;
  • operators should have a supported way to inspect background turns in the UI or logs.
Actual behavior

The App Server client receives a successful answer and turn/completed, but the currently open Desktop thread UI remains unaware of the turn.

In our local proof of concept, the reliable source of truth had to be an external board:

external question board
-> wake event queue
-> bridge dispatcher
-> codex app-server stdio
-> existing thread id
-> agent message stream
-> board comment saved

The external board record shows the work happened, while the visible Desktop thread does not.

Why this matters

This is important for integrations that use App Server as a bridge between local software and Codex:

  • Operators may believe they are using an existing visible thread as the live work record, but the actual background work is not visible there.
  • A human may not know that a background answer was produced unless the integration stores the result elsewhere.
  • For unattended workflows, this makes it hard to audit what happened from the Desktop UI.
  • It also makes it difficult to reason about model/worker provenance, because the visible thread context may not contain the background turn.
Requested improvement

One of these would make the behavior much clearer:

  1. Make App Server turn/start on an existing thread visible in the Codex Desktop thread UI.
  2. Add a Desktop notification or background-turn marker for such turns.
  3. Add an explicit App Server option such as visibleInDesktop: true/false or equivalent documented behavior.
  4. Document that App Server turns are background-only and not guaranteed to appear in the Desktop UI.
  5. Provide a supported activity log/API for inspecting background turns by thread id and turn id.
Additional notes
  • The issue was reproduced using stdio transport, not WebSocket.
  • The background turn itself completed successfully.
  • This is not a request for WebSocket support; it is about Desktop UI/context synchronization or documentation for existing-thread App Server turns.
  • I avoided including local paths, tokens, or private thread content in this public report.
Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.