VS Code extension: claudeVSCodeSessionsList panel fails with ENOENT lstat on org name treated as root path

Description

The Claude Code VS Code extension's sessions panel fails to load with the error:

An error occurred while loading view: claudeVSCodeSessionsList

A toast notification reveals the underlying cause:

A system error occurred (ENOENT: no such file or directory, lstat '/fullpressco')

The extension appears to be treating the GitHub org name from the repo path (fullpressco/CVI-AAAS-2026) as if it were an absolute filesystem path (/fullpressco) instead of correctly resolving the repo's actual local clone location. The main claudeVSCodePanel chat view showed an analogous "An error occurred while loading view: claudeVSCodePanel" error before this.

Environment

• Claude Code for VS Code extension version: 2.1.245
• OS: macOS
• Repo: cloned from github.com/fullpressco/CVI-AAAS-2026, opened via VS Code's GitHub integration

Steps to reproduce

1. Open a repo cloned from a GitHub org (e.g. fullpressco/CVI-AAAS-2026) in VS Code.
2. Install the Claude Code for VS Code extension (Anthropic, v2.1.245).
3. Open the Claude Code panel / sessions list.
4. Observe An error occurred while loading view: claudeVSCodeSessionsList, with a toast showing ENOENT: no such file or directory, lstat '/<org-name>'.

Troubleshooting already performed (issue persists through all of these)

• Trusted the workspace (VS Code Restricted Mode was not the cause).
• Fully uninstalled and reinstalled the extension.
• Cleared VS Code's globalStorage/workspaceStorage/cache for the extension.
• Performed a full clean reinstall of VS Code itself (deleted the app, ~/Library/Application Support/Code, ~/.vscode, VS Code caches, preferences) and reinstalled fresh.
• Reinstalled only the Claude Code extension on the fresh VS Code install (no other extensions).
• Backed up and removed the CLI's own ~/.claude directory and ~/.claude.json config, then signed in fresh.

The identical error (claudeVSCodeSessionsList / ENOENT lstat on /<org-name>) reproduces at every stage above, including in a fully clean VS Code + extension + CLI-data environment with no project open. This strongly suggests the bug is in the extension's own path-resolution logic rather than any local/cached state.

Expected behavior

The sessions panel should resolve the actual local path of the opened repo/workspace rather than constructing an invalid absolute path from the GitHub org name alone.