[FEATURE] Support virtual workspaces without breaking native-anchor limited mode

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

We use Claude Code in a VS Code workspace backed by a custom FileSystemProvider, so the workspace URI has a non-file: scheme.

Claude Code for VS Code 2.1.220 currently initializes in our limited-mode setup because the virtual workspace URI's path corresponds to an existing native "agent anchor" directory. The extension derives its working directory from workspaceFolder.uri.fsPath and resolves that directory successfully.

The anchor contains only agent-facing project configuration such as CLAUDE.md, .mcp.json, and skills. The actual workspace content remains virtual and is accessed through VS Code APIs or MCP tools.

This is useful today, but it is incidental rather than a documented contract. A blanket change such as declaring capabilities.virtualWorkspaces.supported: false or rejecting every non-file: workspace would disable Claude Code before a supported replacement is available.

Is first-class VS Code virtual workspace support planned, and can you share a target release or milestone?

Proposed Solution

Please support virtual workspaces as an explicit, documented mode, even if the initial support level is limited:

1. Keep the logical workspace URI separate from the native execution/project root required by the Claude CLI.
2. Use vscode.workspace.fs for virtual resources where practical, and clearly identify features that still require native disk access.
3. Provide an explicit way for a virtual-workspace provider to supply a native agent root for project configuration, MCP discovery, and process cwd.
4. Until that API or first-class VFS support ships, preserve the currently working native-anchor behavior. Please do not deactivate Claude Code for all virtual workspaces or reject all non-file: roots without a replacement in the same release.
5. Declare virtualWorkspaces support as limited and document the limitations rather than disabling the extension entirely.

Alternative Solutions

Cloning or mirroring the virtual workspace to local disk is not always possible and creates synchronization and identity problems.

An MCP bridge can provide domain-specific file and notebook operations, but it is only useful if the Claude Code extension can still initialize, load project-scoped instructions, and connect to the project MCP configuration.

Priority

High - Significant impact on productivity

Feature Category

File operations

Use Case Example

1. A VS Code extension opens a cloud-backed project through a custom FileSystemProvider.
2. The workspace remains virtual, but the provider supplies a small native anchor directory for agent configuration.
3. Claude Code starts with that anchor as its project root, loads CLAUDE.md, skills, and .mcp.json, and performs domain operations through MCP.
4. When first-class VFS support becomes available, virtual file reads and edits can move to vscode.workspace.fs without breaking the existing workflow.

Additional Context

• VS Code virtual workspace guidance: https://code.visualstudio.com/api/extension-guides/virtual-workspaces
• Related broad feature request: #83696
• Related crash report showing the current local-path assumption: #60011

This request is specifically about a safe transition: replacing incidental native-anchor compatibility with a supported contract, without disabling the working limited mode in between.