[BUG] Selecting "Local" consistently creates cloud sessions instead

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug: Selecting "Local" consistently creates cloud sessions instead

App: Claude Code Desktop (Windows)
Platform: Windows 10 Pro, Surface device
Date: October 11-12, 2026
Reproduced: 3 times, including after full system restart

Steps to reproduce

1. Open Claude Code desktop app
2. Click + to create new session
3. Select "Local"
4. Choose working directory: C:\ClaudeWorkspace
5. Session opens — UI shows "Local" label and correct directory

Expected behavior

Session runs locally on the machine as user pugwy with access to local files.

Actual behavior

Session runs on a cloud VM. Confirmed by:

• whoami returns desktop-g99eicg\user instead of the local user pugwy
• Local files (CLAUDE.md in the working directory, user config files at C:\Users\pugwy\.claude\) are not found
• Session ID does NOT appear in local session listings (no local_ prefix)
• The session has access to claude.ai web memory but NOT local files

Evidence

• Attempt 1: Selected Local + C:\ClaudeWorkspace. Session could not find CLAUDE.md or memory files. Confirmed cloud via file access failure.
• Attempt 2: After full Surface restart. Selected Local + C:\ClaudeWorkspace. Same result. whoami returned desktop-g99eicg\user.
• Attempt 3: Same as attempt 2. Same cloud VM hostname.

Meanwhile, existing local sessions (created by scheduled tasks/cron) work correctly and show local_ prefix in session IDs.

Impact

• Local configuration files (CLAUDE.md, .claude/ directory, memory files) are inaccessible from the cloud session
• The session presents as "Local" in the UI despite running remotely
• No user-visible indication that the session is actually cloud-based
• Users cannot create new interactive local sessions through the app UI

Workaround

Existing local sessions continue to work. New local sessions may need to be created via the CLI (claude from terminal) rather than the desktop app UI.

What Should Happen?

Session runs locally on the machine with access to local files (CLAUDE.md, .claude/ directory, memory files at C:\Users[user].claude).

Error Messages/Logs

No error messages. The session silently runs on a cloud VM instead of locally. Confirmed by: whoami returns desktop-g99eicg\user instead of the local Windows user. Local files not found. Session ID lacks local_ prefix.

Steps to Reproduce

1. Open Claude Code desktop app (Windows)
2. Click + to create new session
3. Select “Local”
4. Choose working directory (e.g. C:\ClaudeWorkspace)

<img width="1942" height="1036" alt="Image" src="https://github.com/user-attachments/assets/0a2e56a4-7884-48a7-9d96-ad84cd1b76ca" />

1. Session opens — UI shows “Local” label and correct directory
2. Run whoami — returns cloud VM hostname instead of local user
3. Local config files (CLAUDE.md, .claude/) are not accessible

Reproduced 3 times, including after full system restart. Existing local sessions (created via scheduled tasks) work correctly.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Code Desktop (Windows)

Claude Code Version

Claude Code Desktop (Windows)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Meanwhile, existing local sessions created by scheduled tasks/cron continue to work correctly and show local_ prefix in session IDs. Only new sessions created through the desktop app UI are affected. The session presents as “Local” in the UI despite running remotely — there is no user-visible indication.