Repository navigation
New thread messages disappear after agent responses on Windows Nightly connected to WSL #27698
Description
What happened
After the latest nightly update, new threads initially display the user’s prompt, but agent responses do not appear. Returning to the thread shows “Send a message to start the conversation.” Sidebar titles and Working/Input/Done states continue updating.
Diagnosis
The affected conversations contain nonempty user and assistant messages in the WSL database. The failure concerns loading or displaying those messages; the exact cause remains unconfirmed.
Steps to reproduce
- Open Windows Nightly connected to WSL.
- Create a thread and send a short prompt.
- Observe the initial prompt render.
- Wait for the agent response, then switch away and return.
- Observe the empty conversation despite updated sidebar status.
Version
Desktop and WSL server: 0.1.6-nightly.20261030.3917.
Environment
Windows desktop app; WSL2 Linux x64 backend. Triage CLI: 0.1.3.
Evidence
Read-only database checks found 2 user and 6 assistant messages in one affected thread; another contained 1 user and 2 assistant messages. All had nonempty text. Screenshots document the failure and recovery.
Traces show pre-creation thread_not_found snapshot failures. These do not establish the cause of subsequent failures.
Related issues
No matching issue confirmed. Duplicate search was limited by unavailable GitHub CLI access.
Fix applied or workaround
Ctrl+Shift+R restored existing conversations and pending questions. New threads subsequently reproduced the failure. No database or configuration changes made.
Filed by
Codex (GPT-6) via t3 triage.
Activity
imCinq commentedon Oct 30, 2026
Can reproduce and this has been happening.
qStentyq commentedon Oct 30, 2026
Same issue, confirmed with root cause. A fix is already merged on
main(#27522).Environment
0.1.6-nightly.20261030.3917(from/.well-known/t3/environment)gpt-6.1-sol, high)What happened
Every new thread stays on "Send a message to start the conversation." after the first message. The sidebar title and status update. Only a full app relaunch shows the conversation. Started after a nightly update about a day ago.
Evidence (WSL backend
server.trace.ndjson+statev2.sqlite, one affected thread)17:58:55.714Z:GET /api/orchestration/threads/<id>/boundedreturnsthread_not_found(ProjectionStoreThreadNotFoundError). The draft is open and nothing has been sent yet.17:59:17.754Z: first message sent and the thread is created. Runordinal:1completes at18:00:38Zwith 4 assistant messages, tool calls and reasoning, all persisted in the projection tables.ws.rpc.orchestration.subscribeThreadspan for that thread id. The client keeps sendingthread.visitabout every 10s, so the view is open but never subscribes./bounded404 at17:45:12Z. The first successful/boundedandsubscribeThreadcame at17:53:09Z, right after the desktop app restarted at17:52:56Z.Root cause (at tag
v0.1.6-nightly.20261030.3917)apps/web/src/components/chat/useThreadLifecycle.tsx:527subscribes torunStopAtom(activeThreadRef). On a draft that is the reserved thread id, so the bounded snapshot is fetched before the thread exists.packages/client-runtime/src/state/threads.ts:999-1001: amissingresult callssetDeleted()and parks the subscription.threads.ts:944-946: every later resubscribe seesstatus === "deleted"and parks without opening the socket. So the thread stays empty until the in-memory state is rebuilt by a relaunch.This matches the analysis in #27623. #27522 (merged 2026-10-30 17:08 UTC, after the
3917nightly) switches that read to the shell-gatedrouteThreadDetailRef. It should resolve this and the duplicates (#27618, #27623, #27628, #27641) once the next nightly ships.Produced via
t3 triageby Claude Code (Claude Opus 5.5).t3dotgg commentedon Oct 31, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Closing: this is covered by #27522, which landed. Reopen if an important part is still missing.