Home / Blog / Pricing

Pricing

Claude Code "Error editing file": Why It Happens and How to Fix It

Claude Code shows "Error editing file"? The causes reported in GitHub issues, from permission prompts to Windows and mounted drives, plus the fixes.

By Engineer Foodie Desk ✓ Sources checked Nov 9, 2026

8 min read

Error strings, error codes and reported causes checked Nov 9, 2026 in Claude Code GitHub issues #31998, #24151, #29841, #31443, #31258, #91783 and #31000, plus Anthropic’s errors reference. Match-failure causes from the tools reference and issues #11447 and #64479, verified Nov 2, 2026. Workarounds marked “user report” come from issue reporters, not Anthropic. Every source is listed at the bottom. No affiliate links on this page (how we work).

The exact error: Error editing file

This is how it shows up in the terminal, copied from the log block in #31998 (verified Nov 9, 2026):

● [Claude answers my question]
  ⎿  Error editing file

One-line answer: Claude Code’s Edit tool tried to change a file and that tool call failed. The short line is a summary, not the real reason. Anthropic’s errors reference says that for a blocked file edit, “the conversation view shows only a short Error editing file line; the full message appears in the transcript view, which you open with Ctrl+O” (verified Nov 9, 2026).

So step zero is always: press Ctrl+O and read the full message. GitHub’s search showed 16 issues with “Error editing file” in the title on Nov 9, 2026, and they don’t all mean the same thing. It’s The Boy Who Cried Wolf with a twist: sometimes the wolf is real, sometimes the edit landed fine and the label is lying. You have to check which one you got.

If your message instead says File has been unexpectedly modified, that’s a different failure (the file changed between read and edit). It has its own page: File has been unexpectedly modified.

Cause 1: you answered “Yes, but…” at the permission prompt

The cleanest repro is in #31998, titled ‘Claude falsely reports “Error editing file” when you confirm “Yes but…”’ (opened Mar 8, 2026, Claude Code 2.1.71, Linux). The reporter’s words: “If I respond to Claude’s prompt to OK an edit of a file with Yes, additional questions , Claude often answers my question then falsely reports “Error editing file” in orange.”

The trigger in the repro steps: when Claude asks to confirm an edit, you press Tab on “1. Yes” to add a question. Claude answers, then shows the error.

The bot closed #31998 as a duplicate of #24151, “Plan mode: first file write always fails, succeeds on retry” (opened Feb 8, 2026, v2.1.37). That one shows the sibling message:

● Updated plan
  ⎿  Error writing file

and says Claude “Immediately retries and succeeds.” Later comments report it on macOS, Ubuntu 25.10 (v2.1.42) and Manjaro (v2.1.50). #24151 was closed on Apr 5, 2026 as “inactive for too long”, not as fixed.

What this means for you: the error can be a false alarm. Check whether the change is in the file (your diff, your editor) before you ask Claude to redo anything. If the trigger is Tab-amending a “Yes”, the repro only covers that path.

Cause 2: the text Claude tried to replace didn’t match

The Edit tool is an exact string replacement. Anthropic’s tools reference says “A single character of whitespace or indentation difference is enough to miss” (verified Nov 2, 2026). Two open issues show this producing Error editing file:

  • #11447: tab-indented files (opened Nov 11, 2025).
  • #64479: mixed literal and escaped Unicode in a multi-line replacement (opened Jun 1, 2026). User report: the reporter got the change through by having Claude use sed, node or bun from Bash.

Ctrl+O shows whether this is your case. If it is, ask Claude to re-read the file and retry with the exact current text.

Cause 3: Windows file errors such as EEXIST

#31443, “File editing fails with EEXIST error on Windows 11” (opened Mar 6, 2026, Claude Code 2.1.69, VS Code terminal), carries this in its log:

EEXIST: file already exists, mkdir

It was closed as a duplicate of #31258, “Write Tool Fails with EEXIST on Windows OneDrive Directories (Regression in 2.1.69)”. That report quotes:

EEXIST: file already exists, mkdir 'C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>\subdir'

The reporter’s own test: the same write to a non-OneDrive path on the same machine returned “File created successfully”, and they concluded “the failure is path-specific to OneDrive, not a general permissions issue.” The OneDrive folders showed attributes “ReadOnly, Directory, Archive, ReparsePoint”. Both issues were closed by the duplicate bot; neither has an Anthropic fix note.

A related Windows report, #31000 (“Too many error editing file”, v2.1.69), logged the TypeScript language server failing to start (ENOENT ... uv_spawn 'typescript-language-server'). It was closed as a duplicate of #30900, “LSP plugins fail on Windows: spawn() cannot find npm-installed .cmd binaries.”

Cause 4: mounted or remote file systems (SSHFS/FUSE, EPERM)

#91783 is still open as of Nov 9, 2026 (opened Sep 3, 2026, Claude Code 2.1.259, Windows, VS Code extension; labels include area:tools and stale). Title: “EPERM error when writing/editing files on SSHFS/FUSE-mounted filesystem.” The edit “fails with Write failed and an EPERM (Operation not permitted) error.”

User reports from the same issue:

  • “Remote SSH extension works fine as an alternative mount method.”
  • A PowerShell write works, but “causes VS Code to lose edit history/checkpoint for those changes.”
  • “GitHub Copilot edits files on the same SSHFS mount without any issues.”

That PowerShell route is a real trade-off. Two tools writing the same file behind each other’s backs is Too Many Cooks territory: everyone’s singing, nobody knows who changed the lyrics. If you need checkpoints, the reporter’s Remote SSH route is the calmer kitchen.

Separate, documented case: in a worktree-isolated session, a UNC share or /net path gets “This write was blocked because the path is network-shaped …”. Anthropic’s guidance is “Usually nothing”: Claude “retries with the local spelling the message asks for” (errors reference, verified Nov 9, 2026).

Cause 5: the file changed on disk

If a formatter, watcher or your own save touched the file between Claude’s read and its edit, you’ll usually see File has been unexpectedly modified in the full message. Fixes for that live on the File has been unexpectedly modified page; I’m not repeating them here.

Error writing file: same family, which fixes apply

Error writing file is the Write tool’s version of the same short line. It appears verbatim in #24151 (plan mode, succeeds on retry) and #29841, ‘Write tool shows “Error writing file” with relative paths but files are written successfully’ (v2.1.63, macOS: “All files were created correctly on disk with the expected content”). GitHub’s search returned 50 issues mentioning it on Nov 9, 2026. Same approach: Ctrl+O, then check whether the file exists before retrying. The EEXIST (#31258) and EPERM (#91783) reports cover writes too.

Documented messages behind the short line

When Ctrl+O shows one of these, Anthropic’s errors reference (verified Nov 9, 2026) has the fix:

  • File is covered by a Read deny rule in your permission settings and cannot be edited. Fix: “remove or narrow the Read deny rule in /permissions or in settings”.
  • <path> is outside <dirs>; the permissions.blockWritesOutsideWorkingDirectories setting blocks writes outside the working directories.
  • File is not valid UTF-8. It may use a legacy encoding such as Windows-1252, Shift-JIS or GBK, or be binary. (the message goes on to say “Nothing was written.”) Fix: let Claude use a shell command in the file’s encoding, or convert the file to UTF-8. “Before v2.1.296, Edit and NotebookEdit applied such an edit and saved every byte they couldn’t decode as U+FFFD. On those versions, update Claude Code.”
  • Repeated “cannot be safely resolved” on one file: “the path likely runs through a committed symlink whose target contains ..”; ask Claude to edit the target by its real path.

Fixes, in order

  1. Press Ctrl+O and read the full message (errors reference).
  2. Check whether the edit landed. #31998, #24151 and #29841 all describe the error showing on edits or writes that succeeded.
  3. If the full message is a documented one, apply the fix listed above.
  4. If it’s a match failure, have Claude re-read the file; for tabs or tricky Unicode, the #64479 user report used sed/node/bun via Bash.
  5. Windows + OneDrive + EEXIST: per the #31258 reporter, the same write worked outside OneDrive. That’s a user report, not an Anthropic fix.
  6. SSHFS/FUSE + EPERM: per the #91783 reporter, the Remote SSH extension works.
  7. Still stuck: /bug sends a report with a consent screen, and /doctor runs a setup checkup (commands doc, verified Nov 2, 2026). Include your Claude Code version and OS; every issue template asks for them.

Honest frustration: a tool whose whole job is editing files still hides the reason behind a vague “Error editing file” label, and the issues I read were closed by bots, as duplicates or for inactivity, with no fix note. Ctrl+O helps, but most people don’t know it exists. The summary line should say what went wrong.

Here’s what I’d do

FAQ

Why does Claude Code say Error editing file? The Edit tool’s change failed or was blocked; press Ctrl+O to see the full message, which Anthropic says the conversation view hides behind the short “Error editing file” line.

Is Error editing file a bug or my permissions? Either: GitHub issues #31998 and #24151 show it on edits that succeeded, while Anthropic’s errors reference lists permission-setting blocks (Read deny rules, writes outside working directories) behind the same short line.

How do I fix Error editing file on Windows? Check the full message with Ctrl+O; GitHub issue #31258 reports EEXIST only inside OneDrive folders on v2.1.69, with the same write succeeding on a non-OneDrive path (user report).

Did my file get edited anyway? Possibly; issues #31998, #24151 and #29841 report the error on edits or writes that landed, so check your diff before asking Claude to retry.

What is Error writing file in Claude Code? The Write tool’s version of the same short line; it appears verbatim in GitHub issues #24151 and #29841, both on writes that succeeded.

Sources

  1. GitHub anthropics/claude-code #31998 (“Error editing file” after “Yes but…”, v2.1.71): https://github.com/anthropics/claude-code/issues/31998 (verified 2026-11-09)
  2. GitHub #24151 (plan mode “Error writing file”, succeeds on retry; closed inactive Apr 5, 2026): https://github.com/anthropics/claude-code/issues/24151 (verified 2026-11-09)
  3. GitHub #29841 (“Error writing file” with relative paths, files written): https://github.com/anthropics/claude-code/issues/29841 (verified 2026-11-09)
  4. GitHub #31443 (EEXIST on Windows 11): https://github.com/anthropics/claude-code/issues/31443 (verified 2026-11-09)
  5. GitHub #31258 (EEXIST on OneDrive, regression in 2.1.69): https://github.com/anthropics/claude-code/issues/31258 (verified 2026-11-09)
  6. GitHub #91783 (EPERM on SSHFS/FUSE, open): https://github.com/anthropics/claude-code/issues/91783 (verified 2026-11-09)
  7. GitHub #31000 and #30900 (Windows edit errors, LSP spawn): https://github.com/anthropics/claude-code/issues/31000 and https://github.com/anthropics/claude-code/issues/30900 (verified 2026-11-09)
  8. GitHub #11447 (tabs) and #64479 (Unicode in old_string): https://github.com/anthropics/claude-code/issues/11447 and https://github.com/anthropics/claude-code/issues/64479 (verified 2026-11-02)
  9. Claude Code errors reference (Ctrl+O transcript view, Read deny rule, working-directory guard, UTF-8 refusal, worktree path blocks): https://code.claude.com/docs/en/errors (verified 2026-11-09)
  10. Claude Code tools reference (exact-match Edit tool): https://code.claude.com/docs/en/tools-reference (verified 2026-11-02)
  11. Claude Code commands (/bug, /doctor): https://code.claude.com/docs/en/commands (verified 2026-11-02)
  12. GitHub issue search, “Error editing file” in title (16) and “Error writing file” (50): https://github.com/anthropics/claude-code/issues (verified 2026-11-09)

Related reading