You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New threads hide completed replies until the desktop window is reloaded #27744
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.
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:
Open a new thread under “No project.”
Select Codex and send reply with hello,.
Wait for completion. The app displays only the prompt.
Switch to another thread and return. The conversation appears empty.
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.
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.
Activity
juliusmarminge commentedon Oct 30, 2026
Reproduced on your build's commit and confirmed fixed on
mainby 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, afterv0.1.6-nightly.20261030.3917was cut from97e35bc, 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 requestedGET /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.apps/web/src/components/ChatView.browser.test.tsx) fails on97e35bcwith one/threads/thread-27443/boundedrequest and passes onmain.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.