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

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.