[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
Workaround ✓ Mentioned in thread ↓
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
- Sidebar in the new section layout, grouped by project.
- 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-storein 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.jsonhavetarget.kind: "local". - Possibly related: #102125, #102088.
4 Comments
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
target.kind: "local", folder exists) is not applied.bootstrapUrlon 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.
source: "restore").localtarget without a variant, the readiness check returnstrueimmediately. Cloud, SSH and pool targets wait for their inventory.localEnvAvailablefrom the composer's start options.localEnvAvailableisfalse.messageForLogging: "epitaxy_preset_target_missing", and the pending apply is cleared instead of retried.The real
localEnvAvailableis!!LocalSessions.start && !disabledByPolicy, which istruehere. This fits the "+" on a project group in the report above, which goes through the same apply path.Suggested fix
localEnvAvailableas unknown in the placeholder options, notfalse.Workaround
Re-select the preset (or Local) in the environment picker after the toast.
Confirming the same toast on macOS, so it is not Linux-specific.
setFocusedSession: sessionId=null,checkTrust, thenLocalSessions.prewarmLocal). The session then spawned normally in a local worktree, so it is cosmetic.Happy to pull anything else from the logs if useful.
Same on Windows 11 (10.0.26200), Claude Desktop 2.37337.1 (MSIX install), Code tab, so this isn't Linux-specific.
SOFTWARE\Policies\Clauderegistry key on this machine, so local sessions aren't disabled by policy.localEnvAvailablefrom the placeholder start options (false), logged asepitaxy_preset_target_missing.Confirming on macOS 27 (Darwin 27.0.0), Claude Desktop 2.37337.1, bundled Claude Code 2.1.295, personal account, no managed settings.
main.logshows only three[oauth-v2] lookuplines and twotemporary query … initializepreflights, with noLocalSessions.prewarmLocal/Starting local session. Re-picking Local from the environment menu right after the toast starts the session normally.remote-tools-devicesocket close/reconnect anywhere near the attempt, so it is not a bridge drop.cc43287c9-CQPh9EJN.jsemits the toast withmessageForLogging: "epitaxy_preset_target_missing"from the pending-apply handler when the rememberedlocaltarget is applied whilelocalEnvAvailable(!!bridge?.start && !policyFlag) is still false. The toast is analytics-only; nothing reachesmain.logorclaude.ai-web.log.persisted.ccd-session-presets.<account>,fileMirrored: true) overwritesccd-session-presets.jsonon apply, so edits to the file on disk do not stick.