[BUG] Desktop 2.37337.1 (Linux): "Local environment is no longer available" toast on every new session from a project group

Status Open
Maintainer reply None cached
Activity 4 comments · opened Oct 14, 2026

After upgrading claude-desktop from 2.31226.1 to 2.37337.1 (apt, stable) on Ubuntu 26.04 (GNOME/Wayland), every click on the "+" next to a project group in the Code tab sidebar shows a toast: "Couldn't switch environment: the Local environment is no longer available."

Steps

  1. Sidebar in the new section layout, grouped by project.
  2. Click "+" next to any project group.

Expected: a new local session in that folder, with no warning.
Actual: the session is created in the right folder, but the toast appears every time.

Notes

  • The persisted ccd-session-store in Local Storage still has "worker":{"type":"environment","id":"__local__"} with "currentHostKey":"local", and the app keeps writing that value, so the new build seems to no longer recognize its own __local__ id.
  • All session presets in ccd-session-presets.json have target.kind: "local".
  • Possibly related: #102125, #102088.

View original on GitHub ↗

4 Comments

adeturckheim · 10 hours ago

Same bug on macOS (Darwin 25.6), Desktop 2.37337.1, Code tab. It looks like a timing issue, not a lost __local__ id.

What I see

  • Opening a new conversation shows: "Couldn't switch environments: the Local environment isn't available anymore."
  • The session still starts locally and works.
  • The last-used preset (target.kind: "local", folder exists) is not applied.
  • Picking the same preset by hand right after works.
  • No managed config, MDM or bootstrapUrl on this machine. Local sessions are not disabled by policy.

Likely root cause (from reading the shipped bundle)

I read the minified renderer code. I did not instrument it, so please treat this as a lead, not proof.

  1. On landing, the composer restores the last preset (source: "restore").
  2. For a local target without a variant, the readiness check returns true immediately. Cloud, SSH and pool targets wait for their inventory.
  3. The apply step then checks localEnvAvailable from the composer's start options.
  4. Until the draft publishes its real start options (in an effect, one render later), the composer uses a placeholder object. In it, localEnvAvailable is false.
  5. So the check fails against the placeholder. The toast fires with messageForLogging: "epitaxy_preset_target_missing", and the pending apply is cleared instead of retried.

The real localEnvAvailable is !!LocalSessions.start && !disabledByPolicy, which is true here. This fits the "+" on a project group in the report above, which goes through the same apply path.

Suggested fix

  • Treat localEnvAvailable as unknown in the placeholder options, not false.
  • Or make local readiness wait until the real start options are published.
  • Either way, defer the apply instead of dropping it.

Workaround

Re-select the preset (or Local) in the environment picker after the toast.

berniedurfee-amira · 9 hours ago

Confirming the same toast on macOS, so it is not Linux-specific.

  • Claude Desktop 2.37337.1 (macOS 26, Darwin 25.6.0), Claude Code 2.1.295
  • Toast text here: "Couldn't switch environments: the Local environment isn't available anymore."
  • Appeared while the new-session composer was open, about 6 seconds after focus moved off the previous session (main.log shows setFocusedSession: sessionId=null, checkTrust, then LocalSessions.prewarmLocal). The session then spawned normally in a local worktree, so it is cosmetic.
  • Nothing about the toast is written to main.log or claude.ai-web.log, and no environments API error was logged.

Happy to pull anything else from the logs if useful.

rflamenco · 8 hours ago

Same on Windows 11 (10.0.26200), Claude Desktop 2.37337.1 (MSIX install), Code tab, so this isn't Linux-specific.

  • The toast ("Couldn't switch environments: the Local environment isn't available anymore.") appears every time a new session opens.
  • The session still starts locally. My saved local preset shows as selected, and This computer is selectable under Choose environment → Local.
  • No managed-settings file and no SOFTWARE\Policies\Claude registry key on this machine, so local sessions aren't disabled by policy.
  • Reading the shipped bundle matches the analysis in the first comment: the toast fires from the preset-apply check reading localEnvAvailable from the placeholder start options (false), logged as epitaxy_preset_target_missing.
jquezada19 · 2 hours ago

Confirming on macOS 27 (Darwin 27.0.0), Claude Desktop 2.37337.1, bundled Claude Code 2.1.295, personal account, no managed settings.

  • Toast on every plain New session with Local (no preset involved; also with a saved local preset).
  • In my case the start was dropped, not just cosmetic: for the failed attempt main.log shows only three [oauth-v2] lookup lines and two temporary query … initialize preflights, with no LocalSessions.prewarmLocal / Starting local session. Re-picking Local from the environment menu right after the toast starts the session normally.
  • No remote-tools-device socket close/reconnect anywhere near the attempt, so it is not a bridge drop.
  • Same read of the shipped bundle as above: cc43287c9-CQPh9EJN.js emits the toast with messageForLogging: "epitaxy_preset_target_missing" from the pending-apply handler when the remembered local target is applied while localEnvAvailable (!!bridge?.start && !policyFlag) is still false. The toast is analytics-only; nothing reaches main.log or claude.ai-web.log.
  • Side effect worth noting: the renderer's Local Storage copy of the presets (persisted.ccd-session-presets.<account>, fileMirrored: true) overwrites ccd-session-presets.json on apply, so edits to the file on disk do not stick.