Windows VS Code extension crashes Claude Code with "Error: cannot open _claude_fs_right:<file>. Detail: Unable to resolve filesystem provider with relative file path '_claude_fs_right:<file>'"

Same

Same

Same

Same

Same

same

Same

Same here.

same

same

如果你用vscode 或者 cousor，并且安装了claude code扩展，删掉应该就没问题了

还真是这样--，为啥会这样啊，那这个官方的扩展插件的作用是啥

Claude Code CLI works as expected when run from a standalone terminal (e.g., Windows Terminal or Command Prompt outside of VS Code). The issue only occurs when using the CLI inside the integrated terminal in VS Code—that’s where it crashes during the file edit confirmation prompt. Everything functions correctly outside of VS Code.

Just published version 1.0.51 of the VS Code extension, which should resolve this!

UPDATE: we're still seeing some issues with the new version, and will have an update shortly

@ant-kurt just tested the latest version of the extension to see if it had resolved my likely duplicate issue (#3453) and the issue still appears present.

Interesting - I was able to repro this when clicking "Update to v1.0.51", but doing a full uninstall and reinstall of the extension (with a restart of VS Code for good measure) resolved the issue for me. Can you try that?

@ant-kurt uninstalling and reinstalling the extension and then restarting VS Code worked for me.

This is now working for me, though I didn't explicitly do any of the above. I'm sure I restarted VS Code at least a few times since opening this bug.

still doesn't work even after a lot of restarts and reinstalling the extension. I'm using vscode insiders.

same

@ant-kurt tried uninstalling and reinstalling (as well as closing and re-launching VS Code) to no avail. Here's the full crash log when trying to make edits within VS Code while the extension is installed (I've obfuscated some of the directory names):

node:internal/process/promises:394
    triggerUncaughtException(err, true /* fromPromise */);
    ^

Error: cannot open _claude_fs_right:<path_to_file_to_be_edited>. Detail: Unable to resolve filesystem provider with relative file path '_claude_fs_right:<path_to_file_to_be_edited>'
    at Uq2 (file:///<local_user_path>/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:1383:14523)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async iR6 (file:///<local_user_path>/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:1969:12396)
    at async J (file:///<local_user_path>/AppData/Roaming/npm/node_modules/@anthropic-ai/claude-code/cli.js:1969:11106)

Node.js v22.17.0

I will update my own issue with this information too #3453

I have Claude CLI version 1.0.53 and I keep getting this error.

happened to me only with the extension installed, after uninstalling it worked out

happened to me only with the extension installed, after uninstalling it worked out

Doesn't work for me :(

I resolved by removing the Claude Desktop Windows app + VSCode extension followed by:
npm uninstall -g @anthropic-ai/claude-code and then
npm install -g @anthropic-ai/claude-code
and restarting VSCode and re-installing only the VSCode extension. Seems it was the desktop app that broke my instance.

uninstalled the extension (1.0.51) and Claude worked well. I also learned that if claude errors out you can have it resume what it was working on by calling claude --continue (or claude -c) or pick from a previous session by using: claude --resume (or claude-r)

If you install Cluade Code on native Windows and install the Cluade Code extension on VSCode and its branch IDE (the same applies to Cursor), this problem will definitely occur, and the Cluade Code icon will be missing in the IDE.
It can be used normally after uninstalling the extension.
I think there is a problem with the IDE or the extension, and I am waiting for the official update of the extension to fix this bug.

I was able to resolve the issue by disabling the Claude Code extension. Seems to not be working with windows at the moment.

samee:

Claude Code Status v1.0.53

  L Session ID: 24d32c88-f8a0-47b9-98f8-dc34bead39c8

 Working Directory 
  L C:\Users\Flex Computers\OneDrive\Desktop\TestProject

 IDE Integration • /config
 ✔  Connected to VS Code extension
 ⚠ Error installing VS Code extension: 1: 1 Extension 'c:\users\flex' not found.
   Make sure you use the full extension ID, including the publisher, e.g.:
   anysphere.csharp
   Failed Installing Extensions: c:\users\flex

Mine is probably because of space in Flex Computers

Same.

For me uninstall the vs code extension work !

Same issue. Fixed it by uninstalling the VS Code extension.

Same, uninstalling vscode extension indeed solves it.

It worked after I removed the VS Code extension

I don't think uninstalling the extension is a fix. The bug is to do with the VS Code interaction with Claude Code via the extension not working, removing the extension isn't a fix for that.

So far I've tried uninstalling and re-installing the extension multiple times (each time closing VS Code or even restarting the device), as well as uninstalling and re-installing @anthropic-ai/claude-code itself. Neither of these have resolved the issue.

I've also tried starting VS Code as an administrator as the user above suggested, however with no success.

@alexdobson - I'm wondering if this issue is more an artifact of a problem with your initial install via npm? I can confirm that having the Claude Code extension installed in VS code _before_ I actually installed the npm package resulted in those file errors.

After uninstalling the Claude Code extension from VS code and restarting the VS code application, no further issues. Claude is able to create files, commit them for me, etc.

Updating node from 22.16.0 to 24.4.0 fixed this for me. Now it's working inside VS code too.

Fixed it by uninstalling the VS Code extension.

@alexdobson - I'm wondering if this issue is more an artifact of a problem with your initial install via npm? I can confirm that having the Claude Code extension installed in VS code _before_ I actually installed the npm package resulted in those file errors. After uninstalling the Claude Code extension from VS code and restarting the VS code application, no further issues. Claude is able to create files, commit them for me, etc.

Unfortunately, I installed Claude Code first (via) npm, then installed the extension within VS Code afterwards, so I don't think that's the problem for me sadly.

Strangely, as I mentioned in my duplicate of this issues (#3453), after I installed the VS Code extension I installed the extension in Cursor, and in Cursor Claude Code and the extension work perfectly.

Updating node from 22.16.0 to 24.4.0 fixed this for me. Now it's working inside VS code too.

Also, this didn't fix this issue for me either (updated Node to latest current version v24.4.1).

so annoying , anthropic why cant you build a proper interface

so what is the fix? its just wasting our token for nothing

Yet to be fixed....

same.

Cursor Version: 0.50.7
VSCode Version: 1.96.2

Nodejs version: v24.4.1

I updated Nodejs version to the one mentioned above, then run Cursor as Admin and it solved the issue for me.

If you’re getting the error about scripts being disabled, just run this in PowerShell:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

It’ll let claude run without issues. 👍
Also, just a heads up, Claude Code seems to have a bug on Windows when editing files. It messes up the file paths (like c%3A%5C...) and crashes. Reading works okay, but editing doesn't.

Same. Just my two cents: For me it happens on Visual Studio Code but not on Cursor.

Same, uninstalling VS code extension solved the error, but I need this extenstion

The latest version of the plugin, v1.0.56, solved the issue for me: https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code

The latest version of the plugin has also resolved the issue for me too.

Cursor uses open-vsx which is still on version 1.0.29 (https://open-vsx.org/extension/Anthropic/claude-code), until Anthropic publishes the update, the extension needs to be installed manually via vsix file to make it work in cursor

Cursor uses open-vsx which is still on version 1.0.29 (https://open-vsx.org/extension/Anthropic/claude-code), until Anthropic publishes the update, the extension needs to be installed manually via vsix file to make it work in cursor

It works for me now in Cursor. To download vsix Extension from Marketplace:

PowerShell
Invoke-WebRequest -Uri "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/anthropic/vsextensions/claude-code/latest/vspackage" -OutFile "claude-code.vsix"

Command line (if you have curl)
curl -L "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/anthropic/vsextensions/claude-code/latest/vspackage" -o claude-code.vsix

this is now working for me when using the "Command Prompt". I still have the problem in Powershell and git bash

Windows Path Encoding Crash - File Edit Operations Broken

52 comments. Assigned to @ant-kurt. Reopened after claimed fix didn't work.

Root Cause

Claude Code's internal filesystem provider uses VSCode's custom URI scheme _claude_fs_right: but fails to properly encode Windows paths.

Broken path format:

_claude_fs_right:c%3A%5Cprojects%5CTennisText%5CCLAUDE.md

Problem: The colon (:) after _claude_fs_right conflicts with Windows drive letter colon (C:).

Why This Happens

VSCode filesystem providers expect URIs like:

scheme://authority/path

But Claude Code generates:

_claude_fs_right:c:\projects\...

This is invalid - needs to be:

_claude_fs_right://localhost/c:/projects/...

Immediate Workaround

Option 1: Use Forward Slashes (partial fix)

Edit CLAUDE.md to use forward slashes for paths:

# Instead of:
C:\projects\TennisText\file.txt

# Use:
C:/projects/TennisText/file.txt

Option 2: Use WSL (full solution)

# Install WSL2:
wsl --install

# Inside WSL:
cd /mnt/c/projects/TennisText
claude
# Now uses Unix paths, no encoding issues

Option 3: Run from Root Directory (reduces path complexity)

# Instead of:
cd C:\Users\Your Name\Documents\Projects\TennisText

# Use:
cd C:\projects\TennisText  # Shorter path, fewer encoding issues

Technical Fix (For Anthropic Team)

In filesystem provider registration:

// Current (broken):
vscode.workspace.registerFileSystemProvider('_claude_fs_right', {
  // ...
});

// Fixed:
import * as path from 'path';

class ClaudeFS implements vscode.FileSystemProvider {
  stat(uri: vscode.Uri) {
    // Decode Windows paths properly:
    const fsPath = uri.path.replace(/^\/([a-z]:)/i, '$1');  // /c:/path → c:/path
    return fs.stat(fsPath);
  }
  
  readFile(uri: vscode.Uri) {
    const fsPath = this.uriToFsPath(uri);
    return fs.readFile(fsPath);
  }
  
  private uriToFsPath(uri: vscode.Uri): string {
    if (process.platform === 'win32') {
      // Handle Windows drive letters:
      return uri.path.replace(/^\/([a-z]):/i, '$1:');
    }
    return uri.fsPath;
  }
}

Validation Test

After fix, this should work:

const uri = vscode.Uri.parse('_claude_fs_right:/c:/projects/test.txt');
const fsPath = provider.uriToFsPath(uri);
console.log(fsPath);  // Should print: c:/projects/test.txt (not c%3A%5C...)

Why This Was Closed Prematurely

The fix worked for some Windows users but not all. Likely depends on:

• Path length
• Special characters in path
• Windows version (Win10 vs Win11)
• VSCode version

Still broken for users with:

• Paths containing spaces: C:\Program Files\...
• Non-ASCII characters: C:\Users\José\...
• UNC paths: \\network\share\...

Emergency Recovery

If Claude Code crashes on file edit:

# 1. Restart VSCode
# 2. Open integrated terminal
# 3. Use Bash tool instead of Edit:
claude
> Use Bash tool to edit files instead of Edit tool
> Example: `echo "content" > file.txt`

---

This blocks ALL Windows VSCode users from file editing. Should be P0. Suggest comprehensive Windows path handling rewrite, not patchwork fixes.

The incorrect URI's can lead to downstream issues for LSP servers that expect that file URI's are valid URIs as specified by the LSP specification

Many of the interfaces contain fields that correspond to the URI of a document. For clarity, the type of such a field is declared as a DocumentUri. Over the wire, it will still be transferred as a string, but this guarantees that the contents of that string can be parsed as a valid URI.

See https://github.com/astral-sh/ty/issues/1328

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I can confirm I am seeing this in VSCode in linux

The Claude Code VSCode extension is sending file-change notifications to rust-analyzer using a custom URI scheme (_claude_vscode_fs_right:) instead of a proper file:// URI. rust-analyzer tries to parse this as a URL, fails because it's not a valid URL scheme, and panics (rather than gracefully handling the error). Each crash triggers a restart, which immediately hits the same bad notification, creating an infinite crash loop until rust-analyzer gives up after 5 crashes in 3 minutes.