[BUG] VS Code sidebar panel crashes with ENOENT when a workspace history entry points to an unreachable sshfs mount

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?

The Claude Code sidebar panel fails to load with:

An error occurred while loading view: claudeVSCodeSessionsList

Developer Tools console shows an unhandled ENOENT: no such file or directory, lstat '<path>'.

Root cause (confirmed via reproduction): the extension's lock file (~/.claude/ide/<port>.lock) writes out workspaceFolders based on whatever the host editor's workspace API reports as open — including entries from the editor's own recently opened / workspace history state, not just currently open folders. If that history contains a path that was only ever reachable via a remote filesystem mount (in my case, sshfs), and that mount is not currently connected, the extension does not appear to catch the resulting ENOENT gracefully. Instead of skipping the unreachable folder or degrading the sidebar view, the whole claudeVSCodeSessionsList view fails to render.

This is distinct from a simple "stale local path" issue — it specifically affects remote-mount workflows, where a folder path is sometimes valid (mount connected) and sometimes not (mount disconnected), and the extension needs to handle the latter without crashing the panel.

What Should Happen?

Expected: the sidebar loads normally, ignoring or gracefully flagging the unreachable folder.

Actual: the panel fails to load entirely with An error occurred while loading view: claudeVSCodeSessionsList, and the console shows an ENOENT/lstat error against the unreachable mount path.

Error Messages/Logs

Steps to Reproduce

1. Run VS Code Server (code-server) in a Docker container.
2. Use sshfs to mount a folder from a remote host into the workspace, and open/browse that folder at least once so it's recorded in workspace history.
3. Unmount or disconnect the sshfs mount
4. Reinstall or reactivate the Claude Code extension, or restart the extension host.
5. Open the Claude Code sidebar.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code for VS Code v2.1.223

Platform

Other

Operating System

Other Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

Related Issues

This appears to be the same underlying defect reported (and closed as stale, without resolution) in:

• #39436 — An error occurred while loading view: claudeVSCodeSessionsList, ENOENT lstat on a path ("/crexi") that no longer existed on the reporter's machine
• #34628 — ENOENT on a remote SSH host's home directory leaking into the local extension's path resolution when using remote.extensionKind: ["ui"]

Both were closed as stale/not planned without a fix. My reproduction (via sshfs rather than SSH remote extension mode) gets to what I believe is the actual shared root cause: the extension trusts workspace-history paths without verifying reachability, and doesn't handle the resulting filesystem error gracefully when a path is remote-mount-backed and temporarily disconnected. This is a real and fairly common pattern for anyone using sshfs, Remote-SSH, or similar remote-mount workflows across multiple hosts — the fix shouldn't require manually clearing workspace history every time a remote mount is offline.

Environment

• Claude Code VS Code extension (latest)
• code-server running in Docker on a Linux VM
• Remote folders accessed via sshfs from separate Proxmox LXC hosts
• Confirmed via state.vscdb (history.recentlyOpenedPathsList) that the offending path was a previously-opened sshfs-mounted folder, not a locally-created or image-baked path

Suggested Fix

• Wrap the lstat/path-resolution calls used to build claudeVSCodeSessionsList in error handling that skips unreachable folders rather than failing the entire view.
• Optionally surface a non-blocking indicator in the sidebar ("1 workspace folder unavailable") rather than a hard failure.

Reactions

👍 if you've hit this too, especially with sshfs, Remote-SSH, or other remote-mount workflows — this seems more widespread than the "stale" status on the prior two issues suggests.