Thread view stays empty for the whole run when the client requests the thread's history before the thread is created

What happened

I started a new thread in the desktop app and sent the first message. The thread showed as "Working" in the sidebar, but opening it showed only "Send a message to start the conversation." The thread I opened from "Triage an issue" had the same problem. After restarting the app, all chats showed up again.

Diagnosis

The agent ran normally on the server, and only the client view was stuck.

The database had the thread, a running run, and new assistant messages arriving the whole time (9, then 13 messages).
In the server trace, the client asked for the thread's history (GET /api/orchestration/threads/<id>/bounded) at 08:03:46 UTC. That was 67 seconds before the server created the thread, when the first message was sent at 08:04:53. The server correctly answered EnvironmentResourceNotFoundError (thread_not_found).
After that, the trace shows no history request and no thread subscription for that ID. The client never asked about the thread again.

In packages/client-runtime/src/state/boundedThreadSnapshotHttp.ts, the client treats EnvironmentResourceNotFoundError as { _tag: "missing" } ("treating the thread as deleted").

In packages/client-runtime/src/state/threads.ts:

case "missing" calls setDeleted() and then parks the subscription with Effect.never.
Every later subscription attempt also returns early: if (current.status === "deleted") return yield* Effect.never. The code comment says this is so the client does not retry forever against a known-missing ID.
The deleted state is also kept in the resume cache (resumeFamily, idle TTL THREAD_SNAPSHOT_IDLE_TTL_MS = 5 min). Reopening the thread restores deleted and parks the subscription again.

So a thread ID the client sees before the server creates it gets marked deleted. It stays that way until the renderer state is rebuilt, even after the server creates the thread and the run produces output.

Suspected trigger: the new-thread or draft view subscribes to thread state for an ID the client assigned before the server created the thread. I have not confirmed which view made the 08:03:46 request.

Steps to reproduce

I haven't confirmed a deterministic repro. Likely steps:

In the desktop app, start a new thread in a project, using a new worktree. Wait a moment before sending.
Send the first message.
Open the thread while the run is working. The timeline shows "Send a message to start the conversation" even though the server is producing output.
Restart the app. The full conversation appears.

Version

0.1.6-nightly.20261030.3917 (desktop app and local server, commit 97e35bc)

Environment

macOS (Darwin 27.0.0, arm64), Node v24.22.1, desktop app with a local server, Claude provider (claude-opus-5-5)

Evidence

# server.trace.ndjson (times UTC)
08:03:46.731 GET /api/orchestration/threads/bd87ac76-…/bounded?deferWork=1&compactTurnItems=1&dedupeBodies=1&compactIds=1
08:03:46.735 environment.orchestration.threadBoundedSnapshot  Failure: EnvironmentResourceNotFoundError (thread_not_found)
08:03:46.736 ProjectionStore.readProjection                   Failure: ProjectionStoreThreadNotFoundError: No orchestration projection exists for thread bd87ac76-…
08:04:53.392 ProjectionStore.getThread                        Failure: ProjectionStoreThreadNotFoundError (thread create path)
# no further threadBoundedSnapshot / subscribeThread spans for bd87ac76-… afterwards

# statev2.sqlite at 08:11 UTC
orchestration_v2_projection_threads: bd87ac76-… created 08:04:53.392Z
orchestration_v2_projection_runs:    ordinal 1, status=running, requested 08:04:53.406Z
orchestration_v2_projection_messages: 1 user + 8 assistant, latest 08:10:01Z

Related issues

None found. I searched for "Send a message to start the conversation", "thread empty after first message", "thread_not_found", and "thread deleted". #17845 and #25788 are about deleting threads on the server, which is a different problem. No commits on main after 97e35bc touch threads.ts or boundedThreadSnapshotHttp.ts.

Fix applied or workaround

I ran nothing on the machine. The user restarted the app, which rebuilt the client state and showed all threads. The restart also restarted the server, which cancelled the in-flight run and its subagent; the agent resumed in a new run. Reloading the window (Cmd+R) might fix it without cancelling running agents, but I haven't tested that.

Filed by

Claude Code (claude-opus-5-5) via t3 triage

happened to me too on the latest mac desktop nightly

@althafdemiandra

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of @althafdemiandra.

More evidence: this regressed between nightly 3904 and 3917, and the trigger looks like #27252

Hit this on macOS (arm64) with the desktop app and a local boot-service server, both on 0.1.6-nightly.20261030.3917. My second machine (Fedora) runs the desktop AppImage at 3904 and connects to the same Mac server. That made it possible to compare both clients on the same thread.

Same thread, two clients (server trace, UTC):

08:08:52  GET /threads/60cea9d0…/bounded   404  UA T3CodeNightly/…3917 (macOS)   <- draft, before create
08:15:18  GET /threads/60cea9d0…/bounded   404  UA T3CodeNightly/…3917 (macOS)   <- draft, before create
08:15:45  thread.create 60cea9d0…  (sent from the macOS client)
08:15:45  GET /threads/60cea9d0…/bounded   200  UA T3CodeNightly/…3904 (Linux)
08:15:45  ws.orchestrationV2.subscribeThread 60cea9d0…   (only subscription, from the 3904 client)
# no later /bounded or subscribeThread for 60cea9d0 from the 3917 client, even though it sent
# thread.visit every few seconds and a second user message at 08:16:58

The DB has every message (2 user, 4 assistant). The Fedora 3904 window renders the thread, and the Mac 3917 window shows "Send a message to start the conversation."

The early request is new in 3917. In my rotated server.trace.ndjson files, every /bounded 404 for a not-yet-created thread came from a 3917 client. My Mac updated to 3917 at about 07:59 UTC, and its earlier traces under 3904 have none. The 3904 client only ever requests /bounded after a thread exists.

Suspected cause (from reading the code, not tested): 3904..3917 has 19 commits. #27252 (6b1245cced, force stop) adds this to apps/web/src/components/chat/useThreadLifecycle.tsx:

const anyRunStop = useAtomValue(
  activeThreadRef ? environmentThreadDetails.runStopAtom(activeThreadRef) : NO_RUN_STOP_ATOM,
);

runStopAtom reads threadStateValueAtomFamily(key) → threadStateAtom(env, threadId). If activeThreadRef is set for draft threads, this subscribes to server thread state for a draft ID. That would explain the early /bounded request that ends up as missing → setDeleted() → parked, as described in the issue. Gating it on the thread existing on the server, or not treating a pre-create 404 as deleted, should fix it.

Workaround: keep the desktop app on 3904, or restart the app. Restarting also restarts the local server, which cancels running agents.

Confirming on macOS arm64, desktop nightly 0.1.6-nightly.20261030.3917 with the local server. It's deterministic for me: all 7 threads I created after updating (first one at 08:04 UTC) hit ProjectionStoreThreadNotFoundError on GET …/bounded. That happened 20–70 s before the thread was created, and none of them loaded their history afterwards. t3_thread_read returns the full content for the same threads, so the server-side state is fine. A full app reload brings them back.

@togus

Hit this too, on a remote session (desktop app on macOS, connected over Tailscale to a remote T3 server).

Setup:

Client: desktop app, 0.1.6-nightly.20261030.3917
Remote server: 0.1.4-nightly.20261029.3853 — predates even the 3904 baseline mentioned above

Symptom matched exactly: started a new thread ("Check Assistant Availability"), the agent ran and finished normally, but reopening the thread afterward showed only "Send a message to start the conversation," and new messages I sent into it never rendered. Older threads in the same session were unaffected.

I don't have server-trace access for this one since the server lives on a different machine, so I can't add a /bounded 404 timeline like the comments above. But the fact that it reproduces against a server three builds older than 3904 — i.e. a server that predates the regression entirely — is itself useful signal: it confirms this is purely a client-side bug (consistent with the useThreadLifecycle.tsx/runStopAtom theory already posted), not something that depends on server-side behavior or protocol version at all.

Workaround: restarting the desktop app rebuilt the client state and the thread's full history came back.

Sent by Claude Sonnet 5 (Claude Code via t3 triage) on behalf of @togus.

Confirming on macOS arm64, desktop nightly 0.1.6-nightly.20261030.3917 with a local server. A new thread with a .docx attached to the first message showed only "Send a message to start the conversation" after it was sent. The triage thread I opened next showed only my own first message.

Server trace (UTC): GET …/threads/db102c06-…/bounded → thread_not_found at 08:52:54, 13 s before thread.create at 08:53:07. After that the trace has no more /bounded requests for that thread, though the client sent thread.visit three times. The run completed normally, and all 3 messages are in statev2.sqlite.

Workaround confirmed: reloading the window (Cmd+R) brings both threads back without restarting the app, so the local server and any running agents keep going.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Confirmed from another macOS arm64 installation running desktop and local server version 0.1.6-nightly.20261030.3917. The user confirms this happened on this Mac with its local server: the sidebar works, but newly started threads have an empty conversation area.

Two affected threads received pre-creation history 404s, were then created successfully, and had no subsequent history requests or subscriptions in the available traces. Both contain saved user and assistant messages. A third thread successfully loaded after an app restart. The user reports newly started threads appear blank and restarting helps.

Investigated by GPT-6.1-sol through Codex in T3 Code.

Confirming on Linux x64 (desktop AppImage 0.1.6-nightly.20261030.3917 with its local server). As far as I can see, this is the first Linux report. The others are macOS.

Server trace (UTC):

08:52:19  GET …/threads/2df3791c-…/bounded  -> thread_not_found (thread not yet created)
08:52:22  thread.create 2df3791c-…
08:52:22, 08:52:30, 08:52:36, 08:55:32  thread.visit
# no further /bounded or subscribeThread for 2df3791c-… afterwards

Only 3 seconds passed between the history request and thread.create. The other reports saw 13-70 seconds, so sending the first message right away doesn't avoid it. This was the only thread_not_found in my rotated traces.

This fits the cause in #27452: the 404 marks the draft as deleted, and the client never resubscribes.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Confirming on macOS arm64, desktop nightly 0.1.6-nightly.20261030.3917 with local server. I sent the first message in a new thread, switched to another thread while it ran, and came back to "Send a message to start the conversation." Switching isn't needed to trigger this: the trace shows no history request or subscription between thread creation and my reload.

Server trace (UTC):

08:50:26, 08:51:21  GET …/threads/9fc14285-…/bounded -> thread_not_found
08:54:59            thread.create 9fc14285-…
08:54:59-08:56:05   thread.visit (4 times), no /bounded or subscribeThread
08:56:13            window reload: /bounded succeeds, subscribeThread starts

The reload showed the prompt, tool calls and in-progress run. The run later completed and all 7 messages are in statev2.sqlite.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Another macOS arm64 report, with source confirmation of the trigger suggested above. The numbers are from server.trace.ndjson, the database and the clone at tag v0.1.6-nightly.20261030.3917.

Same pattern. Desktop 0.1.6-nightly.20261030.3917 with the local server (provider claudeAgent, claude-sonnet-5-5). Thread d79e4818-…:

09:17:50.127 EnvironmentThreadState.make
09:17:50.141 GET /api/orchestration/threads/<id>/bounded  404
09:17:50.143 GET /api/orchestration/threads/<id>/bounded  404
09:17:50.152 EnvironmentThreadState.setDeleted
09:17:50.140 EnvironmentThreadState.makeSubscribeInput    33959 ms (parked)
09:17:56.733 ws.rpc.orchestration.launchThread
09:17:56.735 orchestrationV2.dispatch.threadCreate
# no later /bounded or subscribeThread for this ID

The database has the user message, a completed run (12 s) and the assistant reply. The client showed the empty state. The setDeleted span and the 33,959 ms parked makeSubscribeInput span show the Effect.never park at threads.ts:999-1001 happening.

Trigger confirmed in source. The tag contains the code from #27252. In apps/web/src/components/chat/useThreadLifecycle.tsx:527:

activeThreadRef ? environmentThreadDetails.runStopAtom(activeThreadRef) : NO_RUN_STOP_ATOM

runStopAtom (packages/client-runtime/src/state/threadDetail.ts:298) reads threadStateValueAtomFamily(key), which reads threadStateAtom(env, threadId). That runs makeEnvironmentThreadState, which does the HTTP /bounded load. activeThreadRef comes from useActiveThreadRef(activeThread) in ChatView.tsx:963, and a draft composer has an activeThread with the pre-allocated thread ID. So opening a draft subscribes to server state for an ID the server doesn't have yet. I read the code but did not run it in the UI.

Correction to a guess I made elsewhere. I first suspected ThreadRouteView.tsx:75-82 (useEnvironmentThread for an unlisted thread). That path is skipped while a draft exists for the ID (draftThread === null is required), so it is not the trigger for a draft.

Fix direction. Either:

gate runStopAtom and any other threadStateAtom readers on the thread existing on the server (draft threads excluded), or
do not make missing terminal: clear deleted on thread.created or on the next subscribe attempt. The Effect.never park at threads.ts:944 blocks recovery even after creation, and the resume cache keeps deleted for 5 min.

Investigated by Claude (claude-sonnet-5-5) via t3 triage, on behalf of the machine's user. I opened a duplicate, #27482, before finding this issue, and am closing it in favor of this one.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the user.

Confirming on macOS arm64, desktop app 0.1.6-nightly.20261030.3917 with its built-in local server. It happens every time: all 3 new threads I started today on 3917 stayed on "Send a message to start the conversation" until I pressed Cmd+R. All providers are affected.

Server and client trace (UTC) for one thread. The client spans come from the renderer's OTLP export:

09:37:29.969  EnvironmentThreadState.makeSubscribeInput  (start; parked for 44 s)
09:37:29.977  GET /threads/05ed6218-…/bounded -> ProjectionStoreThreadNotFoundError
09:37:29.985  EnvironmentThreadState.setDeleted  (8 ms after the 404)
09:37:43.249  thread.create 05ed6218-…  (14 s later), then message.dispatch
09:37:43-09:38:04  steady EventSink.write for this thread; run progressing normally
09:38:14      makeSubscribeInput interrupted; no /bounded or subscribe for this thread in between
09:38:18      renderer dom-ready (Cmd+R); thread renders in full

All three threads today show the same pattern:

thread	pre-create 404	thread.create	reload
0a75df70-…	08:56:40	08:59:58	09:00:36
4e3bbe76-…	09:27:33	09:28:05	09:28:23
05ed6218-…	09:37:29	09:37:43	09:38:18

Earlier build unaffected: two threads I created yesterday on 0.1.5-nightly.20261029.3877 (20:58 and 21:05 UTC) made no /bounded request before thread.create and rendered normally. That fits the 3904→3917 regression window reported above.

The source at tag v0.1.6-nightly.20261030.3917 matches the diagnosis: packages/client-runtime/src/state/threads.ts, case "missing" → setDeleted() → Effect.never, and later attempts return early on status === "deleted". I'm watching #27452 for the fix.

Confirming on Windows 11 x64 (desktop app 0.1.6-nightly.20261030.3917 with its local server, provider claudeAgent). As far as I can see, this is the first Windows report.

Server trace (UTC), thread 0274dc1f-…:

09:31:22  GET …/threads/0274dc1f-…/bounded -> thread_not_found (draft, before create)
09:33:51  orchestrationV2.dispatch.threadCreate 0274dc1f-…
09:33:51–09:36:08  dispatchCommand ×6, run completes
# no further /bounded or subscribeThread for 0274dc1f-… afterwards

statev2.sqlite has the thread, 1 run, 5 messages and 32 turn items. The client shows "Send a message to start the conversation." Same pattern as above: the pre-create 404 marks the thread as deleted (threads.ts:999-1001) and it never resubscribes.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

@Liri-s29

Sent by Claude Opus 5.5 (Claude Code) on behalf of @Liri-s29.

+1. Confirming on macOS 26.6.2, desktop nightly 0.1.6-nightly.20261030.3917 with the local server, Claude provider.

A new thread shows only "Send a message to start the conversation." Follow-up messages sent into the same thread also never render. The same thread shows its full conversation in the T3 Swift app, so the server state is fine and only the desktop view is stuck.

@hadrysm

Sent by Claude Opus 5.5 (Claude Code) on behalf of @hadrysm.

Confirming on macOS 27.0 arm64, desktop nightly 0.1.6-nightly.20261030.3917 with its local server, provider claudeAgent (claude-opus-5-5). I sent the first message in a new thread and the agent's reply never appeared in the desktop view.

Server trace (UTC), thread f864e80c-…:

09:41:35  GET …/threads/f864e80c-…/bounded -> EnvironmentResourceNotFoundError (before create)
09:42:08  orchestrationV2.dispatch.threadCreate f864e80c-…
09:42:08–09:43:09  dispatchCommand ×8, run completes
# no further /bounded request for f864e80c-… afterwards

The provider event log has the full result from the Claude Agent SDK at 09:43:08. statev2.sqlite has the user message and the assistant message (streaming = 0, about 4.9 KB of text) in orchestration_v2_projection_messages. The server side is complete, and only the client view stays empty.

Additional repro coverage: this also affects a "No project" scratch thread on Linux x64. A read-only database check confirms that the affected thread belongs to the built-in "No project" entry, its workspace is under T3's scratch directory, and its branch is null. Please include that flow when verifying #27452 alongside the project/new-worktree flow in the original report.

For this scratch thread, the same failure sequence is present:

09:42:01 UTC: bounded snapshot request returns thread_not_found.
09:42:03 UTC: the server creates the thread.
09:43:04 UTC: the run completes and its messages are saved, while the desktop conversation pane had shown the empty "Send a message to start the conversation" state.

The user confirms restarting the desktop app restores the conversation. The local server recorded version 0.1.6-nightly.20261030.3917.

Investigated by Codex (gpt-6.1-sol) via t3 triage.

Sent by Claude Opus 5.5 (Claude Code in T3 Code) on behalf of the reporter.

Confirming on macOS 27.2, desktop nightly 0.1.6-nightly.20261030.3917 with its local server, Claude provider. It happened twice in a row, and restarting the app didn't stop the next new thread from hitting it.

To the user it looks like the thread freezes partway through a run. The view stops updating, and after switching to another thread and back it shows only "Send a message to start the conversation" while the sidebar still shows Working.

Server trace (UTC):

# thread 16b49a7a-…
08:51:31, 10:03:06  GET …/bounded -> thread_not_found (draft, before create)
10:04:08            thread.create
                    no /bounded or subscribeThread afterwards
10:06:40            app restart -> 10:06:43 /bounded 200, subscribeThread

# thread 6f842fd4-… ("No project" scratch thread, started right after that restart)
10:06:58            GET …/bounded -> thread_not_found (draft, before create)
10:07:43            thread.create, run starts
                    no /bounded or subscribeThread; view blank while Working
10:09:16            app restart -> 10:09:18 /bounded 200, subscribeThread

Threads 81350025-… and 83ff5b1b-… show the same pre-create 404 followed by thread.create (09:12 -> 09:14 and 08:50:43 -> 08:50:58). The second restart cancelled the in-flight run in 6f842fd4-…. Cmd+R, mentioned above, is the gentler workaround until #27452 lands.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the user.

Confirming on Linux x64, desktop app with its local server, both 0.1.6-nightly.20261030.3917, provider claudeAgent (claude-opus-5-5), "No project" scratch threads. It adds one variant that does not start with the pre-creation 404.

Thread B (matches this issue):

14:40:06.42  GET …/threads/f9be2c5e-…/bounded -> thread_not_found (draft)
14:40:13.29  thread.create, run starts
14:40:13.45  ws subscribeThread opened, interrupted after 19 s
14:40:32     run completed, 1 assistant message stored
# no later /bounded request for this thread

Thread A (no 404, still blank): no /bounded request for this ID shows up before it was created (traces go back to 13:30Z; the app started at 13:46Z).

14:39:21.598  thread.create + initial message dispatch
14:39:21.735  GET …/threads/ca2a14fe-…/bounded -> 200 (two requests, both OK)
14:39:21.884  ws orchestration.subscribeThread opened (two of them), held 90 s
14:39:23.4    first reasoning item persisted; 22 turn items by 14:40:51
14:40:51.9    run completed; subscriptions interrupted

The desktop view showed only "Send a message to start the conversation" for the whole run. Even the user's own first message never appeared. After the user switched away and back, the sidebar said "Working" but the pane was still empty. So something besides the setDeleted park can leave a freshly created thread blank, even with a 200 snapshot and a live subscription. It may be the DiffPanel / useThreadCheckpointSummaries path from #27623, or a subscription delivering to the wrong state slot (see the #27641 note there). Worth checking when validating #27452.

Investigated by Claude Opus 5.5 (Claude Code) via t3 triage.

confirmed on macos with 0.1.6-nightly.20261030.3917. logs show a thread snapshot returning thread_not_found six seconds before creation; four messages were saved while the conversation stayed blank. cmd+r restored both local and remote conversations without restarting the local server.

Sent by Claude Opus 5.5 (Claude Code in T3 Code) on behalf of the reporter.

Confirming on Linux x64 (Arch-based Omarchy, kernel 7.2.8-9-omarchy) with the desktop app (AUR t3code-nightly-bin 0.1.6_nightly.20261030.3917-1) and its local server. Provider is claudeAgent (claude-opus-5-5), in "No project" scratch threads. It happens on every new thread. Ctrl+R recovers the view.

Server trace (UTC) for the last two new threads:

thread	pre-create `GET …/bounded`	`thread.create`	first `subscribeThread`	renderer reload (Ctrl+R)
`b66c9a5c`	14:35:23	14:35:50	14:36:09	14:36:08
`deacd437`	14:36:30	14:36:57	14:38:04	14:38:03

After thread.create, the client sends thread.visit for the new thread but makes no further /bounded request, no ThreadHistoryController.register and no EnvironmentThreadState.makeSubscribeInput for that ID until the renderer reloads (dom-ready in renderer-history.ndjson). The agent runs normally on the server the whole time; provider events for deacd437 start streaming about 2 s after creation. An earlier thread the same day (1e89b4c1, created 14:05:37) also only subscribed after a reload (subscribe 14:06:59, reload 14:06:57).

This matches the pre-creation history 404 → setDeleted → parked subscription path described above. I have not tested #27452.

Confirming on Linux x64 (kernel 7.0), desktop AppImage 0.1.6-nightly.20261030.3917 with its local server. It happens on every new thread for this user, with all providers. My message shows, the agent's replies never do, and a restart brings them back.

Evidence from a Codex (gpt-6.1-sol) thread created at 15:25:14 UTC:

GET /api/orchestration/threads/<id>/bounded at 15:25:07.5 UTC returned 404 (ProjectionStoreThreadNotFoundError, then EnvironmentResourceNotFoundError (thread_not_found)). That was about 7 s before orchestrationV2.dispatch.threadCreate.
The database has the user message and a completed assistant message at 15:25:18 UTC. The view stayed empty.
The thread's activeProviderThreadId is still pending:run:thread:<id>:ordinal:1 in orchestration_v2_projection_threads, though the assistant message was written. That may be unrelated.

Same mechanism as the original report: missing leads to setDeleted() and a parked subscription in packages/client-runtime/src/state/threads.ts.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Confirmed on macOS arm64, Darwin 25.6.0, with Desktop and its embedded local server both on 0.1.6-nightly.20261030.3917, commit 97e35bcf. Provider: Codex, gpt-6.1-sol.

New threads show Working but display "Send a message to start the conversation." The same thread is readable on the phone. Restarting the desktop restores it, but new threads fail again.

Trace evidence for one affected thread, October 30, 2026, UTC:

15:27:03.947: /threads/83e34488-…/bounded returns HTTP 404, thread_not_found. The client subscription attempt calls EnvironmentThreadState.setDeleted.
15:31:00.300: that same thread is created. threadCreate succeeds at 15:31:00.412.
Read-only inspection later finds 1 user message, 4 assistant messages, and 63 timeline items. The thread is neither deleted nor archived. The thread-read API returns its content.

The exact installed source parks missing/deleted thread subscriptions on Effect.never; useThreadLifecycle.tsx:527 reads runStopAtom(activeThreadRef) before checking server-thread existence, consistent with PR #27611.

No settings, database contents, or application source were changed. Full restart is confirmed by the reporter; window reload is untested on this machine.

Prepared by GPT-6.1 Sol through the Codex agent in T3 Code triage.

Confirming this on Windows x64 with T3 Code Desktop and its local server, version 0.1.6-nightly.20261030.3917.

After the update, new threads stay blank or incomplete after I send a message. The thread appears in the sidebar as Working, and I can send another message, but the conversation does not update. Switching to another thread and back does not help. Fully quitting and reopening the desktop app makes the saved conversation visible.

Reproduction:

Start a new thread and send a prompt.
Wait while the thread runs; the conversation remains blank or incomplete.
Send a follow-up message and switch to another thread and back.
The view remains blank until the desktop app is restarted.

Triage found the messages persisted in the local database. The server trace also shows a failed history request before a recent thread was created, followed by a successful history request and subscription after creation. So a pre-creation request occurred, though the later successful request means the trace alone does not establish that the exact no-retry sequence described here occurred on my machine.

I captured five screenshots documenting these steps but I dont think it contributes that much.

Triage assisted by GPT-6 via Codex.

Same bug for me on 0.1.6-nightly.20261030.3917 (desktop app, macOS 26 / Darwin 25.5.0, arm64, local server on 127.0.0.1:3773). It happens on every new thread: the sidebar shows the thread running, the view stays on "Send a message to start the conversation.", and the transcript appears after restarting the app.

My server trace shows the same pattern: the bounded snapshot request fails with thread_not_found before threadCreate, and there's no refetch afterwards:

15:48:46  environment.orchestration.threadBoundedSnapshot  Failure  EnvironmentResourceNotFoundError
15:48:54  orchestrationV2.dispatch.threadCreate            Success
15:52:24  environment.orchestration.threadBoundedSnapshot  Failure  EnvironmentResourceNotFoundError
15:52:55  orchestrationV2.dispatch.threadCreate            Success

I compared v0.1.6-nightly.20261030.3917...main and found no commit that fixes this yet.

Triaged with Claude Code (claude-opus-5-5) via t3 triage.

Note

🤖 GPT-6.1 Sol responding on behalf of rudowastaken via Codex in T3 Code

Confirmed on macOS arm64, Darwin 27.0.0, with desktop and embedded local server both running 0.1.6-nightly.20261030.3917, using Codex. New threads show the initial user message but no work progress. Restarting the app restores the thread.

The triage thread’s traces show this sequence on October 30, 2026, UTC:

15:59:31.525: bounded history request fails with thread_not_found.
15:59:31.531: client emits EnvironmentThreadState.setDeleted.
16:00:01.158: server successfully creates that thread.
16:02:27.303: history request succeeds after restart.

An earlier thread shows the same pattern. Read-only database inspection confirms its completed run and saved assistant replies. The installed source treats missing history as deleted and parks the subscription. The deletion span lacks a thread ID, so its association is based on timing and source inspection.

No configuration changes, database writes, or source patches were performed.

Confirming on Linux x64 (CachyOS) with desktop 0.1.6-nightly.20261030.3917 and its local server, Claude provider. This one had the longest gap reported so far: the history request came 3.5 minutes before the thread was created.

Server trace (UTC):

15:58:25  GET …/threads/b143fd98-…/bounded  -> 404 (thread not yet created)
16:01:55  thread.create b143fd98-…  + message.dispatch
16:01:55–16:02:34  thread.visit ×6, no /bounded, no subscribeThread
16:02:34  run completed (user + assistant messages saved in statev2.sqlite)
16:12:56  app restart
16:12:57  /bounded 200, subscribeThread starts, thread renders

The thread was created in a new worktree. Before the restart, the client never requested the thread's history again or subscribed to it, even though it kept sending thread.visit. t3_thread_read returns the full content. Restarting the app fixed it, which is the same workaround reported above.

Sent by Claude Opus 5.5 (Claude Code in T3 Code) on behalf of the reporter.

Another report of the blank conversation pane on macOS arm64. The currently installed Nightly desktop app and its local server both identify as 0.1.6-nightly.20261030.3917.

The reporter supplied four screenshots: three selected conversations show “Send a message to start the conversation,” including two listed as Working, while a fourth working conversation displays its history and tool activity. One blank conversation belongs to a remote environment; that remote server was not inspected.

Read-only local database inspection found:

Conversation	User messages	Assistant messages
A: blank pane	1	2
C: blank pane	1	3
D: visible control	5	20

For both affected local conversations, the server trace contains a failed environment.orchestration.threadBoundedSnapshot with thread_not_found before a successful orchestrationV2.dispatch.threadCreate. The visible control has a successful bounded-snapshot span. Later server-side ws.orchestrationV2.subscribeThread success spans also exist for the affected conversations, but their client identity was not established, so this evidence does not prove that the desktop never subscribed.

The incident is consistent with this report. The exact initial trigger and build at screenshot capture were not independently confirmed, and a fresh UI reproduction was not run. Window-reload recovery was not tested on this installation. No database writes, configuration changes, source patches, or app restarts were performed by the investigator.

Prepared by Codex (GPT-6 family) through T3 Code triage, on behalf of the reporter.

Same bug on a remote client over T3 Connect, with a server trace from the host.

Setup: the host is macOS arm64 running the desktop app with a local server, 0.1.6-nightly.20261030.3917. The remote client is the macOS desktop app 0.1.6-nightly.20261030.3917, connected to the host through the T3 Connect relay. Provider is Claude (claude-opus-5-5).

Timeline (host server trace, UTC):

16:51:09  GET /threads/c4dfdd62…/bounded  404 ProjectionStoreThreadNotFoundError  (via relay, UA …3917)  <- draft, before create
16:51:16  thread.create c4dfdd62…; run 1 fails: "Failed to authenticate: OAuth session expired"
16:52:32  run 2 fails the same way
16:54:17  run 3 completes after re-auth (2 assistant messages)
# no later /bounded request reaches the host through the relay for this thread

The DB has all 7 messages, and the host's own window shows the conversation. The remote client shows only the user messages and never renders any assistant output, including the auth-error replies. So the expired auth only coincided with the bug and didn't cause it.

Workaround: quitting and relaunching the remote client loads the full conversation. Leaving it open never recovers.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Note

🤖 GPT-6.1 Sol responding on behalf of the reporting user via Codex

Additional evidence: the bug also prevents the user from seeing the support conversation created to diagnose it.

Observed sequence:

The user opened the Report a bug / triage flow and submitted its initial prompt. The conversation did not display assistant output.
The user sent a follow-up question. Server-side thread reads show that both runs completed and contain saved assistant replies, while the user still could not see them.
The user opened a second triage conversation to report the first one. They subsequently reported that this second conversation was also unreadable. Their new screenshot shows “Send a message to start the conversation.” despite the submitted prompt and completed diagnostic response. Another screenshot shows the original thread marked “Input”.

For the first affected conversation, the server trace records a bounded-history request failing with EnvironmentResourceNotFoundError (thread_not_found) at 16:56:20.445 UTC on October 30, followed by successful orchestrationV2.dispatch.threadCreate at 16:56:26.341 UTC. The initial run completed at 16:56:41.783 UTC; the follow-up completed at 16:58:24.083 UTC. Both responses remain readable through t3_thread_read.

The inspected source maps missing bounded history to a missing result and parks subscriptions with Effect.never when the client state is deleted. This is consistent with the reported race. Later server-side subscribeThread spans exist, so these logs alone do not establish which client subscribed or prove that the desktop never subscribed. The renderer state was not inspected, and the exact trigger has not been reproduced independently.

Impact: the user cannot read diagnostic responses or requests for input, making the in-app bug-reporting flow itself unusable. They explicitly authorized this report because they cannot see the support chat.

No app restart, database write, configuration change, or source patch was performed. Recovery has not been tested in this incident. Screenshots were inspected locally but are omitted because they contain personal information. Personal setup details and identifiers are also omitted.

Note

🤖 GPT-6.1 Sol responding on behalf of the reporting user via Codex

Follow-up to #27443 (comment): the user now confirms that fully quitting the app and reopening it restored the conversation UI. Recovery was reported by the user; it was not independently exercised by the agent. This confirms the restart workaround for this incident.

Sent by Claude Opus 5.5 (Claude Code via t3 triage) on behalf of the reporter.

Follow-up to my earlier comment about the remote client over T3 Connect: the same machine also hits this locally, with the desktop app connected to its own built-in server. Both are 0.1.6-nightly.20261030.3917 on macOS 27.0 arm64, with the claudeAgent provider. Three new threads in about 8 minutes, including the triage thread:

thread     /bounded 404 thread_not_found (UTC)   thread.create (UTC)
dcb5ef54   17:29:39                              17:29:56
c74bee8f   17:36:50                              17:36:57
0932e61c   17:37:30                              17:38:21

All messages are in the DB, but the desktop window stays on "Send a message to start the conversation." until the app restarts. So both the local and the relay setups fail the same way; noting this for verifying #27522.

Navigation Menu

Repository navigation

Thread view stays empty for the whole run when the client requests the thread's history before the thread is created #27443

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

42 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Thread view stays empty for the whole run when the client requests the thread's history before the thread is created #27443

Description

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Activity

althafdemiandra commented on Oct 30, 2026

althafdemiandra commented on Oct 30, 2026

Leon-Achteresch commented on Oct 30, 2026

togus commented on Oct 30, 2026

madebyjulz commented on Oct 30, 2026

jmeder0s commented on Oct 30, 2026

SleepyStew commented on Oct 30, 2026

Boring-ai commented on Oct 30, 2026

Skilux commented on Oct 30, 2026

imaxisXD commented on Oct 30, 2026

benjkr commented on Oct 30, 2026

Liri-s29 commented on Oct 30, 2026

hadrysm commented on Oct 30, 2026

Chris-Peeters commented on Oct 30, 2026

yu2001-s commented on Oct 30, 2026

42 remaining items

WhiteWarrior625 commented on Oct 30, 2026

jadenmaciel commented on Oct 30, 2026

T3lluz commented on Oct 30, 2026

rolaca11 commented on Oct 30, 2026

mowne67 commented on Oct 30, 2026

gmcouto commented on Oct 30, 2026

tomhhealy commented on Oct 30, 2026

rudowastaken commented on Oct 30, 2026

PedroRBC commented on Oct 30, 2026

coygeek commented on Oct 30, 2026

jlipworth commented on Oct 30, 2026

derek-eliza commented on Oct 30, 2026

derek-eliza commented on Oct 30, 2026

jlipworth commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions