Claude Code Extension fails to load on network paths (UNC paths)

[vilpessoa]

Claude Code Extension fails to load on network paths (UNC paths)

Environment

• VS Code Version: Latest (as of May 6, 2026)
• Claude Code Extension Version: 2.1.131-win32-x64
• OS: Windows 10/11
• Network Setup: UNC path (\\spwacd14\Grupos\...) on corporate network

Problem Description

The Claude Code extension fails to load when opening a folder from a network path (UNC path), displaying the error:

Ocorreu um erro ao carregar o modo de exibição: claudeVSCodeSessionsList
ENOENT: no such file or directory, lstat 'G:\Grupos'

What Works ✅

• Extension loads perfectly when opening local folders (C:\Users\vilcimar.pessoa\Downloads)
• Extension authenticates successfully
• All features work in local context

What Fails ❌

• Opening folder from network path: \\spwacd14\Grupos\Suprimentos Inteligência\INTEGRAÇÃO
• Error occurs immediately after folder opens
• Extension attempts to access mapped drive G:\Grupos which doesn't exist
• Even after cleaning cache, workspaceStorage, and reinstalling extension, error persists on network paths

Root Cause Analysis

The extension appears to:

1. Attempt to resolve network paths as mapped drives (e.g., G:\Grupos)
2. Fail when those mapped drives don't exist or are inaccessible
3. Not gracefully handle UNC paths without requiring mapped drives
4. Store references to broken paths in persistent cache that can't be fully cleared

Steps to Reproduce

1. Have a corporate/shared network folder accessible via UNC path: \\server\share\folder
2. Open VS Code
3. File → Open Folder → Select the UNC network path
4. Observe: Extension fails to load with ENOENT error

Expected Behavior

• Extension should load successfully on network paths
• Should either:
  • Resolve UNC paths directly without requiring mapped drives
  • Provide clear error messaging if network access is unavailable
  • Allow user to manually configure network path handling

Actual Behavior

• Extension crashes with cryptic ENOENT error
• References to non-existent mapped drive paths
• No way to resolve without administrative access (to map drives) or moving project to local folder

Workarounds Attempted (All Failed)

• ✗ Reinstalling extension multiple times
• ✗ Clearing all cache folders (workspaceStorage, globalStorage, storage.json)
• ✗ Simplifying settings.json to minimal config
• ✗ Reloading VS Code window
• ✗ Changing folder paths to different network locations
• ✗ Using Explorer "Add to Favorites" and opening from there

Error Logs

Console Output

[Extension Host] Failed to fetch remote embeddings cache
[Extension Host] ENOENT: no such file or directory, lstat 'G:\Grupos'
Error: Ocorreu um erro no sistema (ENOENT: no such file or directory, lstat 'G:\Grupos')
  at Object.realpathSync (node:fs:2805:29)
  at Object.<anonymous> (node:electron/js2c/node_init:2:5760)
  at Zf.resolveWebviewView (c:\Users\vilcimar.pessoa\.vscode\extensions\anthropic.claude-code-2.1.131-win32-x64\extension.js:813:9468)

System Configuration

• Network: Corporate UNC path accessible via \\spwacd14\Grupos\...
• User: Non-administrator (cannot map drives)
• Security: "security.allowedUNCHosts": ["spwacd14"] configured in VS Code settings
• Network Discovery: Disabled on machine (by policy)

Additional Notes

• Extension works flawlessly on local C:\ drive
• The error references G:\Grupos which appears to be a stale cached path
• Even complete uninstall/reinstall doesn't resolve the issue
• Suggests cache corruption or hardcoded path resolution logic that fails on network contexts

Request

Please provide:

1. Native support for UNC paths without requiring mapped drives
2. Better error handling/messaging for network path scenarios
3. Ability to manually configure network path resolution
4. Clear documentation on network folder requirements (if any)

---

Labels: bug, network-paths, unc-paths, windows, extension

[KarchiChen]

The issue is almost certainly in how the extension resolves cwd or workspace root — somewhere in the Node.js layer it's calling something like fs.lstat or path.resolve on the UNC path, which Windows can silently rewrite to a stale mapped drive letter depending on the session context (especially if that drive mapping exists for your user but not for the process/shell the extension spawns). Try checking whether VS Code's integrated terminal inherits your drive mappings by running net use in it — if G: doesn't appear there, that's your smoking gun, and the fix is either forcing UNC path usage throughout or ensuring the spawned process inherits the parent session's drive mappings. The "can't be fully cleared" persistence angle suggests the broken path is being written into something like workspaceStorage keyed by the resolved drive path, so even after reinstall it's re-reading a stale entry — worth grepping your %APPDATA%\Code\User\workspaceStorage for G:\\Grupos to confirm. Filing this with a minimal repro showing the lstat call site in the extension source would help the maintainers pinpoint whether it's vscode.workspace.workspaceFolders[0].uri.fsPath returning the mapped path instead of the UNC path.