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

happened to me too on the latest mac desktop nightly

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):

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:

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.

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):

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):

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-…:

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:

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:

All three threads today show the same pattern:

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-…:

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.

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.

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-…:

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):

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.

Same here, and it reproduces every time for me on 0.1.6-nightly.20261030.3917 (macOS 27.0.1, arm64, desktop app, Claude provider, "No project" thread):

1. Create a new thread.
2. Type a message and press Enter.
3. Leave the thread (open another one).
4. Go back to it.

Result: the sidebar shows the generated title and the thread is running, but the timeline is empty with "Send a message to start the conversation."

Confirmed on macOS arm64, desktop and local server 0.1.6-nightly.20261030.3917. History returned thread_not_found at 09:59:21 UTC; the thread was created at 10:00:19. No later history request appears in the available traces. Both runs completed; 2 user and 8 assistant messages are saved, while the desktop shows an empty conversation.

Investigated by Codex (GPT-6 family) via t3 triage.

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

Confirming on macOS 27.0 arm64, desktop nightly 0.1.6-nightly.20261030.3917 with its built-in local server, provider claudeAgent (claude-opus-5-5). This is a single machine with no remote connections. I sent "commit code" and then "commit and push" in a new thread. Only my two messages show. The agent's replies never appear, and the sidebar still lists the thread normally.

Server trace (UTC), thread 1c7d4959-…:

statev2.sqlite has both runs completed, 2 user messages, 2 assistant messages (streaming = 0), 6 command_execution items and 3 reasoning items, all completed. The server state is fine, and only the desktop view is stuck.

One difference from other reports: the user says a reload did not bring the replies back. However, the trace shows no /bounded request for this thread after the 10:02:27 404. That suggests whatever they tried did not rebuild renderer state, for example switching threads, which restores deleted from the resume cache. It may be worth checking that the fix in #27452 also covers that path.

Confirming the same pre-creation history-404 failure on macOS arm64 with Codex, using the Shift+Cmd+N → “No project” scratch-thread flow. This is additional pre-fix evidence for #27443 and coverage worth including when validating #27452; I have not installed or tested that PR.

Environment and observed flow

• Desktop and local server: 0.1.6-nightly.20261030.3917, independently checked from the installed app package and the server's environment API. The failed request's user agent also identifies desktop build 3917.
• OS: macOS 26.3.1 (a), build 25D771280a, arm64.
• Provider: Codex, model gpt-6.1-sol, Extra High reasoning effort.
• Built-in “No project”, scratch workspace, no branch; local loopback server.
• The user opened a new thread with Shift+Cmd+N, entered a prompt and sent it. This is a user-observed occurrence, not an independently repeated deterministic repro.

The supplied screenshot shows the selected thread with its generated title and “Working 2m” in the sidebar, while the central pane says “Send a message to start the conversation.” The composer is empty. The screenshot is omitted because it includes unrelated private sidebar entries.

Correlated evidence for one affected thread

All times below are 2026-10-30 UTC. The thread ID is consistently replaced with <thread-A>; private prompt contents, local paths and unrelated logs are omitted.

The history request precedes actual thread creation by approximately 40.46 seconds. In the available rotated server traces I found no subsequent /bounded request for this thread ID after creation, despite repeated successful thread.visit commands and the later follow-up message.

The native t3_thread_read API returned the initial prompt and both assistant progress messages while the run was active. A later read returned:

• Thread and latest run status: completed; active run: null.
• 49 timeline items, including saved user messages and the final assistant answer.
• The same thread ID throughout; pending request count: 0.

Thus this occurrence is not just an orphaned “Working” badge: the model started, executed tools, produced progress messages, and completed with a persisted final answer while the reported desktop timeline was empty.

Scope of the confirmation

The evidence matches the pre-create 404 → non-recovering client-history state discussed above. It also confirms this can happen in a Codex-backed “No project” thread created through Shift+Cmd+N, without a project or new worktree. I have not traced the initiating client atom in this occurrence, so the runStopAtom trigger attribution comes from the existing investigation/PR, rather than a new instrumented reproduction here.

No app/server restart, renderer reload, configuration change or patch was performed during this investigation. Switching threads and Cmd+R were not validated as workarounds on this machine; the successful Cmd+R reports elsewhere in this issue should not be read as a test performed here.

Please include Shift+Cmd+N → No project → first send in the fix's validation, checking that no server-history load is initiated for the uncreated draft and that the same conversation streams after creation.

Investigated by Codex (gpt-6.1-sol, Extra High) in T3 Code, posted at the user's explicit request.

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

Follow-up to my comment above: fully restarting the T3 Code desktop app brought back the missing replies in thread 1c7d4959-…. So the workaround other reporters describe works here too, and nothing points to a separate path that recovery doesn't cover. The earlier attempt that didn't help most likely only switched threads, which keeps the cached deleted state, rather than rebuilding renderer state.

Also hit on macOS arm64, desktop nightly 0.1.6-nightly.20261030.3917, with Auto balance on and two connected Macs on the same build. This adds a multi-machine variant.

The UI showed "Send a message to start the conversation." The early 404 came from a different environment than the one that created the thread. Mac B also returned a successful snapshot, per the client's HTTP cache. I don't have Mac B's server trace, so I can't rule out an earlier 404 there.

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

Confirming the same symptoms on Windows 11 x64 (10.0.26100), with T3 Code Desktop and its local server both on 0.1.6-nightly.20261030.3917, using the OpenCode provider.

Existing unsettled conversations displayed the correct title but an empty message pane saying “Send a message to start the conversation.” Settled conversations remained readable. The triage conversation itself was also affected.

This concealed a genuine pending clarification question in a parent conversation after its three delegated subagents had completed. The sidebar’s Input badge initially appeared stale, but server-side reads returned the saved messages and confirmed pendingRequestCount: 1. The conversation history was present on the server but not visible in the desktop UI.

Fully closing and relaunching T3 Code restored the conversations. OpenCode had recently been updated, but no causal link has been established. We did not verify the pre-creation history-404 sequence for this occurrence, so this confirms the symptoms and workaround rather than independently confirming the root cause.

Investigated with GPT-6.1 Sol through the OpenCode harness in T3 Code, posted on behalf of the user at their explicit request.

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

Confirming on macOS 27.2 arm64, desktop app and local server 0.1.6-nightly.20261030.3917, Claude provider. Every thread started from a draft in the available traces (6 of 6) got a /bounded thread_not_found before creation, and none subscribed afterwards until the next app restart. A thread created through another path (no pre-create 404) subscribed immediately.

feecd7d8 recovered without a restart, 26 minutes after its run completed at 09:21:57. That fits the deleted resume-cache entry expiring (5-minute idle TTL) once nothing kept the thread state mounted.

The triage thread itself was hidden while the agent waited on a question (the sidebar showed "Input"). Force-quitting to see it cancelled the in-flight run, so Cmd+R is the safer workaround.

Also affected on Windows, T3 Code 0.1.6-nightly.20261030.3917, using Codex. My message appears, but the assistant’s response stays hidden after completion. Ctrl+R makes it appear.

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

Confirming on macOS 27.2 arm64, desktop nightly 0.1.6-nightly.20261030.3917 with its built-in local server (also confirmed via /.well-known/t3/environment), provider claudeAgent (claude-opus-5-5). This is the second time this user has hit it.

Symptom: a thread asking for app-icon concepts ran to completion and "popped back into the inbox". Clicking it in the sidebar showed no content. The DB has everything: the user message, 3 assistant messages, 39 turn items, and a completed run.

Server trace (UTC), thread 2ac38ff5-…:

That matches the parked Effect.never path after setDeleted() in packages/client-runtime/src/state/threads.ts. A second unknown thread ID (likely another draft) got the same pre-create 404 → setDeleted at 11:00:59.

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

Confirming on Windows 11 x64, desktop nightly 0.1.6-nightly.20261030.3917. The app connects through an HTTPS reverse proxy to a background service (also 3917) running in WSL2. Provider is pi (GLM-5.3-Flash). Ctrl+R fixed it.

This case has a much longer gap than other reports: the pre-create 404 came 70 minutes before the thread was created, right after the server's self-update restart. That suggests the draft view's history request also fires when the app reconnects, not only when a draft is opened.

Server trace (UTC), thread 55c267a5-…:

During that time the Android app loaded the same thread normally, getting a /bounded 200 at 10:55:16. The blank view also hid a pending user_input_request from the agent. The sidebar's "Input" badge was the only sign of it.

Sent by Muse Code (muse-wonder-full-1.0) in T3 Code on behalf of the reporter.

Confirming on macOS 27.0.1 (26A434), arm64, desktop Nightly with an additional impact that I don't see covered above: when the stuck thread waits on an approval or a question, there is no UI left to answer it, and the thread cannot settle.

What was observed

• New “No project” (scratch) thread 74ca0690-…, not a project/worktree thread. Sent a first message; the agent started working on the server.
• The conversation lane stayed on the theme background — black in dark mode — showing only “Send a message to start the conversation.” (MessagesTimeline.tsx:1278 empty state). Sidebar and composer rendered normally. In screenshots at 10:20:07, 10:20:44, 10:21:55 and 10:24:47 UTC the sidebar badge for this thread went from Approval to Input, while the center pane never rendered any message, tool activity, approval card, or question card.
• Switching the composer from Supervised to Full access did not recover it. Further user messages were accepted and persisted server-side, but never rendered in that client.
• The agent could not be unblocked from the UI: the reporter had to ask for the pending question to be removed, and could only answer it later by pasting the questions and answers back as plain text after the rollback below.

Server trace for the same thread shows the resulting deadlock (retained server.trace.ndjson, UTC):

Build timeline on this machine (same thread, before/after)

From user-agent strings in the retained traces and the post-rollback spans for 74ca0690-…:

After the rollback to 3904 the same thread became usable again and the run resumed, which corroborates the 3904 → 3917 regression window reported above on a single machine/thread. No data was lost: the server kept the messages and the agent kept working behind the empty view, so this looks client-only, as diagnosed in the issue body.

What I could not verify for this thread

The creation-time spans for 74ca0690-… had already rotated out of the retained traces (and have since rotated further), so I cannot add a direct pre-create /bounded 404 / setDeleted timeline for this specific thread. Classification as this issue is based on the identical symptom, the 3917 build window, and recovery on 3904. On this same machine and build, another thread that day does show the pre-create ordering in retained traces (629fecdf-…: bounded thread_not_found 10:38:32 UTC, threadCreate 10:38:50 UTC). I did verify the cited chain at tag v0.1.6-nightly.20261030.3917 (97e35bcf): boundedThreadSnapshotHttp.ts:101-107 maps EnvironmentResourceNotFoundError to missing, threads.ts:999-1001 does setDeleted() + Effect.never, threads.ts:944-945 parks later attempts while deleted, and #27252 (6b1245c) added useThreadLifecycle.tsx:527 reading runStopAtom(activeThreadRef) → threadDetail.ts:302, where activeThreadRef is non-null for a never-sent local draft while the guarded routeThreadDetailRef other detail reads use stays null until the shell exists.

Suggested regression coverage

Beyond “first message renders”, please cover: (1) a unit case for missing-then-created — a provisional pre-create missing must not stay terminal deleted after thread.create, while an authoritative thread.deleted must still park without retrying forever; and (2) a draft-created thread whose first run requests an approval and a structured question: both cards must render in the timeline and be answerable without Cmd+R, app restart, or rollback, and settling must not fail with “waiting on an approval or question” while that card is invisible. That is the failure mode that made this instance look like a hung black screen and blocked work completely (High severity from the reporter's side).

Scope note on the current fix: #27452 prevents this trigger by gating the run-stop read on the shell-backed detail ref, which is the right immediate fix for the reported flows. As its scope stands, a pre-create missing from any other probe would still become terminal deleted and be retained by the 5-minute resume cache (threads.ts:944-945, 999-1001, 1064-1072), and approval/question rendering after a first send is covered by construction rather than by a render-and-answer regression test yet. A follow-up that distinguishes provisional pre-create missing from an authoritative thread.deleted would close that remaining trap without making genuinely deleted threads retry forever.

Screenshots from 10:20–10:24 UTC are retained locally by the reporter and can be shared on request; they are not attached here because the sidebar shows unrelated private thread titles.

Confirming on macOS arm64 with the desktop app connected to a T3 service on another Mac (Mac mini), both on 0.1.6-nightly.20261030.3917. Provider is Claude. I hit this all the time: when I open a thread, it shows "Send a message to start the conversation." even though the conversation has started. I have to refresh or send the prompt again to see it.

The agent itself was fine. The database on the Mac mini has the thread with 1 user and 1 assistant message, and the run completed. Only the client view was empty.

Server trace from the Mac mini for one affected thread (fcfb92e1-…, times UTC):

This matches the sequence in this issue, with the server on a separate machine from the client.

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

Confirming on macOS 27.0 arm64, desktop app and local server both on 0.1.6-nightly.20261030.3917, provider claudeAgent (claude-opus-5-5). This happens on every new thread, including several started within a minute of each other.

Four threads were affected. Each got a pre-create /bounded thread_not_found about 2 s before thread.create, and none had a /bounded or subscribeThread request afterwards (times UTC):

• ae0bbd45: 404 at 11:27:06, created at 11:27:08
• fb6d566b: 404 at 11:27:11, created at 11:27:13
• 41662cae: 404 at 11:27:17, created at 11:27:18
• ca42a008: 404 at 11:27:54, created at 11:27:56

statev2.sqlite has the user prompt and 2 assistant messages for both ae0bbd45 and fb6d566b. The desktop app shows only "Send a message to start the conversation." I found the same pattern on an earlier thread (a364644f: 404 at 10:52:38, created at 10:52:40).

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

temporary fix: cmd + r or ctrl + r will rebuild the window state and you can view the thread again