Repository navigation
[Bug]: New thread shows empty view until app restart (desktop with Local environment off, paired to background service) #27527
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Run the server as the background service (
t3 service install) on macOS. - In the desktop app, switch off Settings → Environments → Local environment and pair the app with the service at
http://127.0.0.1:3773. - Start a new thread in a project and send the first message.
Expected behavior
The thread view shows the user message and the agent's streaming output.
Actual behavior
The thread shows "running" in the sidebar, but its view stays on "Send a message to start the conversation." The agent runs normally on the server: t3 thread show <id> prints the full transcript. Reloading the window or restarting the app shows the transcript.
The server trace suggests the client fetches the draft thread's snapshot before the thread exists, gets thread_not_found, and does not fetch or subscribe again after thread.create succeeds:
10:34:25.420 GET /api/orchestration/threads/a6eec6a3-…/bounded?deferWork=1&compactTurnItems=1&dedupeBodies=1&compactIds=1
10:34:25.425 environment.orchestration.threadBoundedSnapshot Failure EnvironmentResourceNotFoundError (thread_not_found)
10:35:00.867 orchestrationV2.dispatch.threadCreate Success (thread a6eec6a3-…, driver claudeAgent)
… no ws.orchestrationV2.subscribeThread for a6eec6a3 while the agent runs …
10:40:23.813 environment.orchestration.threadBoundedSnapshot Success (after app restart)
10:40:23.890 ws.orchestrationV2.subscribeThread Success (thread a6eec6a3-…)
It happens on every new thread. Existing threads load normally.
Impact
Major degradation or frequent failure
Version or commit
0.1.6-nightly.20261030.3917 (desktop app and background service)
Environment
macOS (Darwin 27.2), Apple Silicon. Desktop app with Local environment off, paired with a background service on the same machine (T3CODE_HOST=0.0.0.0, port 3773). Provider: Claude (claudeAgent).
Logs or stack traces
From ~/.t3/userdata/logs/server.trace.ndjson; the excerpt is above. I can share fuller spans on request.
Activity
NoLoopsLeft commentedon Oct 30, 2026
Running into the same issue on my machine on Windows 11.
sunjay-dev commentedon Oct 30, 2026
Yes, same problem
voltcrash commentedon Oct 30, 2026
temporary fix: cmd + r or ctrl + r will rebuild the window state and you can view the thread again
timdreesen commentedon Oct 30, 2026
I'm seeing the same issue on Linux, with Settings → Environments → Local environment switched on.
0.1.6-nightly.20261030.3917
on Linux Mint 22.3
KorenKrita commentedon Oct 30, 2026
same
iwaynee commentedon Oct 30, 2026
same problem
0.1.6-nightly.20261030.3917
on macos Version 27.0.1 (26A434)
fmnyikosa commentedon Oct 30, 2026
same here.
0.1.6-nightly.20261030.3917
macos 26.6.2
pablo-kitz commentedon Oct 30, 2026
Same here
0.1.6-nightly.20261030.3917
Windows 11
DEV-DIBSTER commentedon Oct 30, 2026
Can confirm this behavior:
0.1.6-nightly.20261030.3917
Windows 11
DuarteFaria commentedon Oct 30, 2026
Same here
0.1.6-nightly.20261030.3917
macos 26.3
SaultyGoodman commentedon Oct 30, 2026
Corroborating on macOS desktop 0.1.6-nightly.20261030.3917 with a local server, across both Claude and Codex.
Read-only server traces and saved thread state show the same sequence:
thread_not_found.Source inspection matches #27443 and the fix in #27522: the run-stop read introduced by #27252 uses the draft's reserved thread reference. The early 404 marks client thread state deleted and parks its subscription. #27522 gates that read until the server lists the thread.
The introducing commit is included in 3917 and absent from 3904. I have not independently run the regression test or the fixed app; #27522 supplies that test and before/after evidence. This adds corroboration from the affected installation, not a claim of independent verification of the fix.
No original screenshots or raw logs are attached because they contain private workspace and conversation details.
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.