[BUG] Restored desktop sessions keep a dead env_* id: 404 "Environment not found" blocks input after app restart

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 1 comment · opened Aug 9, 2026

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 found during 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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗