[BUG] Unloadable legacy sessions silently defeat the desktop environment default (falls back to Local)

Edited 2026-08-17. This issue was originally filed as a feature request ("no persistent default environment"). That framing was wrong — a default is derived, and I found the actual cause afterwards. Rewritten below; see the comment for what changed.

Summary

On Windows, the desktop environment picker ("Where Claude runs") had been coming up as Local on every new session, even though ~60 of my last ~65 sessions were WSL sessions in the same folder. Deleting a batch of old, unloadable legacy sessions from the session list fixed it immediately — new sessions now default to WSL: AlmaLinux9 as expected.

So the default-environment derivation works. It was being silently defeated by dead session records, and the failure mode is a quiet fallback to Local rather than any visible error.

What the dead sessions were

Old Windows-path sessions (C:\99calls) sitting at the bottom of the session list. They couldn't be opened; the app offered to import them from CLI sessions, and that import didn't work either. Their CLI-side transcripts still exist on disk (~/.claude/projects/C--99calls, C--99calls-server), so the import source wasn't missing — the import itself failed.

Evidence

Counting the desktop session records in %APPDATA%\Claude\claude-code-sessions before and after the deletion:

| | Before | After |
|---|---|---|
| Total sessions | 98 | 83 |
| wslConfig: null (Local) | 33 | 18 |

15 records removed, all Local, all legacy Windows-path sessions. Nothing else changed — no app restart, no settings edit — and the picker's default flipped from Local to WSL: AlmaLinux9.

The shipped renderer resolves the environment for a new session as o ?? "local" — an unconditional fallback to Local when nothing resolves, with no error surfaced. That's consistent with a broken record short-circuiting the derivation, though I can't confirm the exact path from the minified bundle. The observation is solid; the mechanism is inference.

Why this is worth fixing rather than living with

The wrong default is silent and lands you in a broken toolchain. My repo is Linux-native (PHP 8.4 / MariaDB) and lives in WSL 2. If the picker says Local and I reach the repo through the folder picker — browsing to \\wsl.localhost\AlmaLinux9\home\me\repo, a perfectly valid Windows path — the app starts a Local session there without complaint:

uname -a  →  MINGW64_NT-10.0-26200 ... Msys      # not AlmaLinux
pwd       →  //wsl.localhost/almalinux9/home/me/repo
php       →  /c/xampp/phpX/php                    # Windows PHP, not the project's PHP 8.4
mariadb   →  /c/Program Files/MariaDB 11.4/bin/mariadb
mago      →  not found

The repo's CLAUDE.md loads and its entire documented toolchain is absent — test runner, linter, local database, PostToolUse hooks — and every file operation crosses the 9p share. Across my history this hit 7 sessions, interleaved with working WSL ones, twice within the same hour. Each one is a session that looks fine until something fails strangely.

Repro

Not verified from a clean profile — this is what I did:

1. Have a session list containing legacy sessions that fail to load and fail to import from CLI sessions.
2. Start new sessions in a folder you always open in WSL. Observe the picker defaulting to Local.
3. Delete the unloadable legacy sessions.
4. Start a new session — the picker now defaults to the WSL distro.

Asks

1. Don't let unreadable session records determine the default. Skip records that fail to load rather than falling through to Local, and log rather than swallow it.
2. Make the failed CLI import diagnosable — the transcripts were present, so a message saying why the import failed would have surfaced this weeks earlier.
3. Warn on environment/path mismatch. The picker already validates the other direction — selecting WSL then a Windows folder gives "Folder must be inside the WSL distro. Choose a path under \\wsl.localhost\…". The converse (Local + a \\wsl.localhost\… folder) is at least as likely to be a mistake and gets nothing. Worth doing independently of the above, since it catches the damage whatever the cause.
4. An explicit default-environment setting (e.g. defaultEnvironment: "wsl:AlmaLinux9" in ~/.claude/settings.json) would make the whole class of problem non-silent. Lower priority now that the derivation is known to work.

Relationship to #77750

#77750 asks for admin-side pre-configuration of WSL environments (wslConfigs, deep links, trust pre-grant) for team onboarding, and notes in passing that no default-environment setting exists. This one is a different failure: the existing derivation being corrupted by dead records on an already-configured machine. Ask 4 above is the piece that overlaps.

Environment

• Claude desktop app 1.30096.5.0, Claude Code CLI 2.1.229
• Windows 11 Pro 10.0.26200
• WSL 2, AlmaLinux9
• Incidental note that may help you place the code path: WSL sessions register as ssh-<uuid> projects under ~/.claude/projects/, not as local ones.