Sign up
View stargazersSign up

New threads hide completed replies until the desktop window is reloaded#27744

opened14d agobyZzackbart

What happened

New threads appeared stuck across providers while existing threads continued working.

A test Codex thread titled “Reply with Hello” showed only the submitted prompt, although the server had completed and saved the reply. Switching to another thread and returning made the conversation appear empty, with “Send a message to start the conversation.”

View → Reload (⌘R) restored the conversation.

Diagnosis

Confirmed: thread creation, provider execution, and reply persistence succeeded. The desktop client failed to display the saved conversation.

The suspected cause is a premature missing-thread result retained by the client:

  • The client requested the test thread’s bounded snapshot before the thread existed.
  • In the affected build, the snapshot loader maps that result to missing.
  • The thread state then becomes deleted and parks its subscription. The in-memory resume cache preserves this state when reopening the thread.

This mechanism fits the observations, but client runtime state was not directly inspected.

Steps to reproduce

Observed on an already affected desktop session; the initial trigger is not yet deterministic:

  1. Open a new thread under “No project.”
  2. Select Codex and send reply with hello,.
  3. Wait for completion. The app displays only the prompt.
  4. Switch to another thread and return. The conversation appears empty.
  5. Use View → Reload (⌘R). The saved conversation becomes visible.

Version

Desktop and local server: 0.1.6-nightly.20261030.3917
Commit: 97e35bcf23e4dcf34c2dcffadd37c08db0e01e52

Triage CLI only: 0.1.5.

Environment

macOS, Apple Silicon; Darwin 25.6.0. Desktop app connected to its local backend. Instrumented reproduction used Codex; the user reported all new threads affected.

Evidence

For thread c144c336-81bb-46a7-ab19-455451091495, on October 30, 2026, UTC:

text
118:06:39.357 bounded snapshot request → thread_not_found
218:12:11.559 thread created
318:12:11.566 Codex run requested
418:12:17.697 assistant message saved: "hello,"
518:12:17.722 run completed

The saved thread was not deleted. Screenshots show the missing reply and subsequently empty conversation.

#14046 describes completed first turns remaining invisible until reload, but was closed through an IndexedDB recovery fix. This report adds evidence of a pre-creation snapshot miss; a duplicate relationship is not confirmed.

#4647 concerns draft state after failed bootstrap. Here, launch and execution succeeded.

Fix applied or workaround

View → Reload (⌘R) restored the conversation. No database, configuration, or source changes were made.

Filed by

Codex via t3 triage; exact model identifier unavailable.

JJulius Marminge14d ago

Reproduced on your build's commit and confirmed fixed on main by 8d012a688e7cb12fb17a91be68a32734a0efa0b7 ("fix(web): a new thread's first reply shows without reloading", #27522). That fix merged at 17:08 UTC today, after v0.1.6-nightly.20261030.3917 was cut from 97e35bc, so it ships in the next nightly.

What I ran, on two web dev servers with fresh databases, sending reply with hello, to Codex from a new draft:

  • 97e35bc (your build): opening the draft requested GET /api/orchestration/threads/<reserved id>/bounded, and the server answered 404. After sending, the server saved the assistant reply, but the view showed only the prompt. Switching to another thread and back showed "Send a message to start the conversation." This is your report exactly.
  • main @ 6fc9144: opening the draft made no request for the reserved thread id. The reply "hello," appeared without a reload and was still there after switching away and back.
  • The regression test from #27522 (apps/web/src/components/ChatView.browser.test.tsx) fails on 97e35bc with one /threads/thread-27443/bounded request and passes on main.

The cause is the one you identified: a draft subscribed to its reserved thread's detail before the server created it, and the 404 parked the thread as deleted. The fix waits for the server to list the thread before loading its detail. This is the same bug as #27443, so I'm closing this one.