Repository navigation
New desktop threads stay empty until the app restarts #27615
Description
What happened
New threads show a Working badge but no assistant messages, reasoning, or tool activity, even after completion. This happens with both Codex and OpenCode.
Switching threads does not help and also hides the user's message. The timeline shows “Send a message to start the conversation.”
Fully quitting with ⌘Q, reopening T3, and reopening the thread restores the saved conversation.
Diagnosis
Logs show the client requesting a thread snapshot before the draft has been created on the server. The request returns HTTP 404, and the client marks the thread deleted. The server subsequently creates that same thread successfully and saves the provider's output.
Inspection of the installed client bundle shows that a missing snapshot triggers EnvironmentThreadState.setDeleted, after which the subscription waits indefinitely. This explains why the sidebar can show Working while the conversation remains empty.
Reproduction
- Open the macOS desktop app and create a new thread.
- Send a prompt using Codex or OpenCode.
- Wait for completion: the timeline remains empty.
- Switch away and back: the user's message also disappears.
- Fully quit and relaunch: reopen the thread and the saved conversation appears.
Environment
- Desktop and local server:
0.1.6-nightly.20261030.3917 - Installed commit:
97e35bcf23e4 - macOS, Apple silicon; Darwin
27.0.0 - Embedded local server
- Providers: Codex and OpenCode
Evidence
On October 30, 2026, UTC:
| Event | Time |
|---|---|
| Draft snapshot returns HTTP 404 | 13:25:53.293 |
| Client marks thread deleted | 13:25:53.304 |
| Server successfully creates the same thread | 13:26:04.352 |
A read-only database query subsequently confirmed that this thread was not deleted and contained one user message, two completed assistant messages, and saved tool activity.
The same snapshot-before-creation sequence appeared in multiple earlier threads, including an OpenCode thread.
Workaround
Fully quit and relaunch the desktop app, then reopen the existing thread. Confirmed by the reporter. Switching threads does not work.
Related issues
- #14046: similar symptoms, but attributed to an IndexedDB failure.
- #16443: related treatment of missing snapshots as deleted, involving archived threads.
Neither is confirmed as a duplicate. No newer release fixing this incident was verified.
Investigation limits
Diagnosis used local traces, read-only database queries, and the exact installed application bundle. A source clone could not be obtained. No application settings or database contents were changed.
Prepared by OpenAI GPT-6 through the Codex agent during T3 Code triage.
Activity
nianzhibai commentedon Oct 30, 2026
I've encountered the same situation too in Codex.
And I don’t think there should be a bug like this.
unisol1020 commentedon Oct 30, 2026
+1
Blunderchips commentedon Oct 30, 2026
same, tested on mac and windows. Using nightly.
VitorCesarinoMarchese commentedon Oct 30, 2026
same, on arch linux using nightly.
Standard-Track commentedon Oct 30, 2026
Note
🤖 *GPT-6.1-Sol responding
Confirmed on macOS arm64, desktop and local server 0.1.6-nightly.20261030.3917, using Codex. The parent conversation showed no progress or reasoning while subagents remained accessible separately.
At 15:38:03.500 UTC, the thread’s bounded snapshot returned 404. At 15:38:03.599, the same client trace called EnvironmentThreadState.setDeleted. Thread creation succeeded at 15:43:09.915. Read-only thread inspection confirmed persisted assistant messages and reasoning summaries.
Source inspection confirms the missing-snapshot path marks the thread deleted and parks its subscription. No changes applied; restart recovery has not been tested for this incident.
ivl-aryze commentedon Oct 30, 2026
have same issue
Confirmed on macOS arm64, desktop and local server 0.1.6-nightly.20261030.3917,
teamplayer3 commentedon Oct 30, 2026
Confirming this on
0.1.6-nightly.20261030.3917(Linux, Claude agent provider).completedrun, statuscompleted, no pending requests.So the data is persisted and only the client timeline is empty, consistent with the 404-before-creation /
setDeletedexplanation above.Raghav-Kochhar commentedon Oct 30, 2026
Same on Windows desktop, nightly 0.1.6-nightly.20261030.3917. New thread showed only my message, then went empty with the Working badge after switching threads. The backend kept running, and a full restart restored the conversation.
neko782 commentedon Oct 30, 2026
happens on arch linux 0.1.6-nightly.20261030.3917
svenrabe commentedon Oct 30, 2026
Confirmed fixed on macOS 27.0.1 (Apple silicon), desktop app with embedded local server,
0.1.6-nightly.20261030.3940: new project, first message, the reply now shows without restarting the app.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.
abdullahnettoor commentedon Oct 31, 2026
I’m seeing the same symptom with OpenCode in the desktop app: on the first message in a new thread, the chat switches to the conversation screen but remains on “Send a message to start the conversation.” After quitting and reopening T3 Code, the response is visible in that chat.
Environment: macOS arm64. The local server reports 0.1.6-nightly.20261030.3917, but I haven’t confirmed that this was the desktop app build at the time. Whether the app was connected to a local or remote server, and the incident time, are unknown.
This appears to match the draft-thread snapshot-before-creation issue described here. I haven’t collected a trace for this incident.