Skip to content

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

Closed

Description

@zackbart

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:

18:06:39.357  bounded snapshot request → thread_not_found
18:12:11.559  thread created
18:12:11.566  Codex run requested
18:12:17.697  assistant message saved: "hello,"
18:12:17.722  run completed

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

Related issues

#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.

Activity

  1. juliusmarminge commented on Oct 30, 2026

    @juliusmarminge
    Member

    Reproduced on your build's commit and confirmed fixed on main by 8d012a6 ("fix(web): a new thread's first reply shows without reloading", https://git.cafe/pingdotgg/t3code/pulls/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 https://git.cafe/pingdotgg/t3code/pulls/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 https://git.cafe/pingdotgg/t3code/issues/27443, so I'm closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions