[FEATURE]: Formally support GitHub Virtual Filesystem (vscode-vfs://) workspaces in Claude Code

Summary

Please add first-class, formal support for GitHub Virtual Filesystem (VFS) workspaces (vscode-vfs://github/..., and other virtual/remote URI schemes) to Claude Code and its VS Code extension.

Today, opening a VFS workspace does not just fail gracefully — in some cases it crashes the extension panel entirely (see the related bug report #68913: "Claude Code VS Code Extension Crashes on Windows When a GitHub Virtual Filesystem Workspace Is Open"). That bug asks for a defensive fix (skip/ignore non-file:// schemes so the panel stops crashing). This request goes one step further: rather than only avoiding a crash, we want Claude Code to understand and operate on VFS workspaces as a supported, formally documented mode.

Motivation

• The "Open in VS Code" / github.dev experience mounts repositories over vscode-vfs://github/<owner>/<repo> without a local clone. This is an increasingly common, zero-setup way to browse and lightly edit code.
• Users reasonably expect Claude Code to work in these workspaces, not just refuse to crash.
• Other remote/virtual schemes (ssh://, devcontainer://, WSL vscode-remote://, Codespaces) hit the same class of problems, so a general solution benefits many workflows.

Current Behavior

• The extension stores only the path component of the workspace URI in its IDE lock file (%USERPROFILE%\.claude\ide\<pid>.lock), discarding the scheme (vscode-vfs://) and authority (github). Example lock content:

``json
{ "workspaceFolders": ["\\gregsowell\\ansible-misc"] }
``

• On Windows this path is treated as relative to the current drive, so fs.realpathSync / lstat resolves it to C:\gregsowell\ansible-misc, throwing ENOENT and crashing the panel (claudeVSCodeSessionsList). Full details in #68913.

Proposed Behavior / Requirements

1. Preserve the full workspace URI (scheme + authority + path) everywhere Claude Code records or reasons about workspace folders — including the IDE lock file — instead of storing a bare, ambiguous path.
2. Route file access through the VS Code filesystem API (vscode.workspace.fs) rather than Node's local fs when the workspace is virtual, so reads/edits work against vscode-vfs:// content.
3. Guard all local-only fs operations (lstat, realpathSync, etc.) behind a scheme check, so non-file:// workspaces never fall through to local-path resolution. (This also resolves the crash in #68913.)
4. Clearly communicate capabilities/limitations in VFS mode — e.g. which features (running commands/terminals, git operations) require a real local checkout, and degrade gracefully with a helpful message instead of erroring.
5. Cover the general case: handle vscode-vfs://, vscode-remote:// (WSL, Codespaces, SSH), and devcontainer:// consistently, not just GitHub VFS.
6. Document VFS/remote workspace support in the Claude Code docs.

Acceptance Criteria

• Opening a vscode-vfs://github/<owner>/<repo> workspace on Windows, macOS, and Linux loads the Claude Code panel without error.
• Claude Code can read (and, where the scheme permits, edit) files in a VFS workspace via the VS Code FS API.
• Features that genuinely require a local checkout fail gracefully with a clear explanation rather than a crash.
• Behavior is verified across vscode-vfs://, Codespaces/WSL remote, and devcontainer workspaces.

Related

• Bug: #68913 — the crash-avoidance fix. This issue tracks the broader, formal VFS support that builds on it.