[BUG] Restored desktop sessions keep a dead env_* id: 404 "Environment not found" blocks input after app restart
Summary
After restarting Claude Desktop, some restored Code-tab sessions cannot be used: typing a message reports that the environment is no longer available. The app log shows the renderer requesting an env_* environment that the API no longer knows about.
[error] [REACT_QUERY_CLIENT] QueryClient error:
endpoint: /v1/environment_providers/private/organizations/<org>/environments/env_01G93NjcjNXTCvCAsfSVVdLC
method: GET
status: 404
body: {"type":"error","error":{"type":"not_found_error",
"message":"Environment env_01G93NjcjNXTCvCAsfSVVdLC not found."}}
The session is otherwise intact — its cliSessionId still resolves to a transcript on disk, and resuming that id with the standalone CLI works normally. Only the desktop app's binding to the environment is dead.
Environment
- Windows 11 Home 26200
- Claude Desktop
1.26832.0 - Desktop-bundled Claude Code
2.1.221/2.1.222 - Standalone Claude Code
2.1.226 - First-party claude.ai Max authentication, single org
- No managed-settings file
Evidence from the app logs
Across %APPDATA%/Claude/logs/main*.log and claude.ai-web*.log:
- 11 distinct
env_*ids have returned 404 on that endpoint - Spanning 2026-07-01 through 2026-08-09, so this is not a one-off outage
- On 2026-08-08 between 23:26:48 and 23:29:16, four different environment ids 404'd within three minutes (
env_01G93Njcj…,env_01KVRgMcX…,env_01WUbUNAv…, plus a repeat) — consistent with several restored sessions each still bound to a different, now-dead environment
I have not established why the ids go stale, only that they do and that the app keeps using them after a restart instead of re-binding. 423 of my 543 stored desktop session records carry bridgeSessionIds, so most sessions have a bridge attachment of some kind.
Expected
A restored local session should re-bind to a live environment, or the app should surface a "reconnect" action instead of a dead-end error.
Actual
The session is unusable in the app. The only recovery I found is to read cliSessionId out of the session record under %APPDATA%/Claude/claude-code-sessions/<account>/<org>/local_*.json and resume it in the CLI.
Possibly related
- #32746 (closed) —
BridgeFatalError: Environment not foundduring idle remote-control sessions. Same API error, different symptom: that one crashed the CLI mid-session, this one blocks input in a restored desktop session. - #48754 (closed) — Cowork/Dispatch backend dropping env/session records.
- #81669 and #48949 (both open) — Remote Control auto-enable skipped on restored desktop sessions. Different symptom, but the same restore path appears not to re-initialize per-session state.
Happy to pull more log lines or the session-record schema if useful.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗