claude-code - 💡(How to fix) Fix [BUG] setupPanel calls realpathSync on workspace path without scheme check, ENOENT on Remote-SSH with extensionKind=ui [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54708Fetched 2026-04-30 06:38:14
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×5commented ×1

Error Message

Error Messages/Logs

Error: ENOENT: no such file or directory, lstat '/System/Volumes/Data/home/<user>' 5. Observe ENOENT toast: "A system error occurred (ENOENT: no such file or directory, lstat '/System/Volumes/Data/home/<user>')"

Root Cause

When the Claude Code extension is configured to run on the UI side (remote.extensionKind: { "anthropic.claude-code": ["ui"] }) against a Remote-SSH workspace, opening the Claude Code panel fails with ENOENT on every launch. The extension calls realpathSync on the workspace folder path without first checking whether the URI scheme is file: or vscode-remote:. With a Remote-SSH workspace, the path (e.g. /home/<user>) lives on the remote, but realpathSync runs on the local Mac filesystem, expanding it through APFS firmlinks to /System/Volumes/Data/home/<user> and ENOENT-ing because that path exists only on the remote.

Fix Action

Fix / Workaround

This setup (UI-side extensionKind) is the workaround documented in #37919 and required for users whose remote host CPU lacks AVX (see #34481, #24562, #20611, and others) where the bundled native binary cannot run on the remote and must run UI-side. So the path translation bug compounds the AVX bug: the workspace-side path crashes from AVX, and the UI-side workaround crashes from path translation. Together they make the extension fully unusable for users with older remote hardware.

Code Example

if (workspaceFolder.uri.scheme === 'file') {
  resolved = fs.realpathSync(workspaceFolder.uri.fsPath);
} else {
  resolved = workspaceFolder.uri.fsPath;  // or use vscode.workspace.fs.stat
}

### Error Messages/Logs

---

### Steps to Reproduce

1. macOS client (Apple Silicon), any Linux remote
2. Local user `settings.json`:
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

Note on duplicates

I expect the auto-triager may close this as a duplicate. Before it does: prior issues #20226 and #20098 covering the same general area were closed as duplicates of #12361, which is an unrelated third-party provider authentication bug closed as "not planned." That dup chain is incorrect. This issue identifies a specific code path (setupPanel to realpathSync) not covered by any prior report. If auto-closed against an unrelated issue, please re-open.

What's Wrong?

When the Claude Code extension is configured to run on the UI side (remote.extensionKind: { "anthropic.claude-code": ["ui"] }) against a Remote-SSH workspace, opening the Claude Code panel fails with ENOENT on every launch. The extension calls realpathSync on the workspace folder path without first checking whether the URI scheme is file: or vscode-remote:. With a Remote-SSH workspace, the path (e.g. /home/<user>) lives on the remote, but realpathSync runs on the local Mac filesystem, expanding it through APFS firmlinks to /System/Volumes/Data/home/<user> and ENOENT-ing because that path exists only on the remote.

This setup (UI-side extensionKind) is the workaround documented in #37919 and required for users whose remote host CPU lacks AVX (see #34481, #24562, #20611, and others) where the bundled native binary cannot run on the remote and must run UI-side. So the path translation bug compounds the AVX bug: the workspace-side path crashes from AVX, and the UI-side workaround crashes from path translation. Together they make the extension fully unusable for users with older remote hardware.

What Should Happen?

setupPanel / createPanel should check the workspace folder URI scheme before calling node:fs.realpathSync. For vscode-remote://... workspaces, either skip the realpath resolution or use vscode.workspace.fs.stat (which is scheme-aware and routes through the appropriate filesystem provider).

Likely fix shape:

if (workspaceFolder.uri.scheme === 'file') {
  resolved = fs.realpathSync(workspaceFolder.uri.fsPath);
} else {
  resolved = workspaceFolder.uri.fsPath;  // or use vscode.workspace.fs.stat
}

### Error Messages/Logs

```shell
From the local Extension Host log when the panel is opened:


Error: ENOENT: no such file or directory, lstat '/System/Volumes/Data/home/<user>'
    at Object.realpathSync (node:fs:2805:29)
    at Object.<anonymous> (node:electron/js2c/node_init:2:5760)
    at Bf.setupPanel (~/.vscode/extensions/anthropic.claude-code-2.1.123-darwin-arm64/extension.js:813:13703)
    at Bf.createPanel (~/.vscode/extensions/anthropic.claude-code-2.1.123-darwin-arm64/extension.js:813:13260)
    at ~/.vscode/extensions/anthropic.claude-code-2.1.123-darwin-arm64/extension.js:873:6668
    at Pg._executeContributedCommand (.../extensionHostProcess.js:503:48683)
    ...

Steps to Reproduce

  1. macOS client (Apple Silicon), any Linux remote
  2. Local user settings.json:
    {
      "remote.extensionKind": {
        "anthropic.claude-code": ["ui"]
      }
    }
  3. Connect to the Linux host via Remote-SSH, open /home/<user> (or any remote workspace) as the workspace folder
  4. Open the Claude Code panel
  5. Observe ENOENT toast: "A system error occurred (ENOENT: no such file or directory, lstat '/System/Volumes/Data/home/<user>')"
  6. Panel renders empty / non-functional

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.123 (extension), package directory anthropic.claude-code-2.1.123-darwin-arm64

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Operating System

macOS (Apple Silicon) client; Debian Linux remote

Terminal/Shell

VS Code Remote-SSH

Additional Information

  • Remote-SSH extension version: 0.122.0
  • VS Code: latest stable
  • The npm-installed Claude Code CLI works correctly on the same remote host (relates to #34481, extension binary requires AVX, CLI does not)
  • Related issues: #37919 (AVX + UI extensionKind, sidebar webview rendering), #34481 (AVX vs. CLI parity), #20226 and #20098 (closed as incorrect duplicates of unrelated #12361)

extent analysis

TL;DR

The issue can be fixed by modifying the setupPanel function to check the workspace folder URI scheme before calling node:fs.realpathSync, handling vscode-remote:// workspaces differently.

Guidance

  • Check the workspace folder URI scheme to determine whether to use fs.realpathSync or an alternative approach for vscode-remote:// workspaces.
  • Use vscode.workspace.fs.stat as a potential alternative for scheme-aware file system operations.
  • Verify the fix by testing the Claude Code panel with a Remote-SSH workspace and checking for the absence of ENOENT errors.
  • Consider the implications of this fix on other parts of the codebase, particularly where file system operations are involved.

Example

if (workspaceFolder.uri.scheme === 'file') {
  resolved = fs.realpathSync(workspaceFolder.uri.fsPath);
} else {
  resolved = workspaceFolder.uri.fsPath;  // or use vscode.workspace.fs.stat
}

Notes

This fix assumes that the issue is solely related to the handling of vscode-remote:// workspaces and that the proposed modification does not introduce other compatibility issues.

Recommendation

Apply the workaround by modifying the setupPanel function to correctly handle vscode-remote:// workspaces, as this is a targeted fix for the identified issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING