[BUG] Edit/MultiEdit fails with "String not found in file" only on manual confirmation (works with auto-accept) — VSCode extension, Windows

Preflight Checklist

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

What's Wrong?

Environment

Claude Code: VSCode extension (not the terminal CLI)
OS: Windows 11 Pro (10.0.22621)
Auto-updated ~4 hours before this report; bug still present
Target files: Markdown, UTF-8 without BOM, CRLF line endings, heavy non-ASCII content (German umlauts ä/ö/ü, guillemets « » ‹ ›)
Summary
Edit and MultiEdit fail with String not found in file. Failed to apply edit. when the edit is confirmed manually in the new edit/diff confirmation window. The exact same edit succeeds when running in accept-edits (auto-accept) mode. Started ~2 days ago, coinciding with the new edit confirmation window.

Key evidence that the file/old_string is correct

The old_string is present byte-for-byte in the file (verified with grep -n — single-line paragraph, matched exactly).
File is UTF-8 (no BOM): first bytes 54 69 74.
File uses CRLF line endings.
The failing old_string was a single-line paragraph (no embedded newlines), so this is not purely a multi-line CRLF splitting issue — a single-line match with umlauts still fails on manual confirm.
Steps to reproduce

On Windows, open a UTF-8 (no BOM), CRLF-terminated .md file containing umlauts/guillemets in the VSCode extension.
With manual edit confirmation (not accept-edits mode), have Claude run Edit replacing an existing paragraph that contains umlauts.
Observe String not found in file. Failed to apply edit. at the confirmation step.
Switch to accept-edits mode and re-run the identical edit → succeeds.
Expected
Manual confirmation applies the same edit that auto-accept applies successfully.

Actual
Manual confirmation reports the string as not found, even though it is present verbatim.

Suspected cause
The manual-confirm path appears to re-read/re-validate the file from disk with different normalization than the auto-accept path — likely an encoding mismatch (UTF-8 read back as Windows-1252) and/or CRLF↔LF handling difference introduced by the new confirmation window.

Workaround
Use accept-edits mode.

What Should Happen?

Manual confirmation of an edit should apply the exact same change that auto-accept (accept-edits mode) applies successfully. When the old_string is present in the file verbatim (verified byte-for-byte with grep), the Edit/MultiEdit tool should locate and replace it regardless of whether the edit is confirmed manually in the diff window or applied automatically. Line-ending style (CRLF vs LF) and non-ASCII content (UTF-8 umlauts, guillemets) should not affect whether the match succeeds, and the manual-confirm path should not re-read or re-encode the file differently than the auto-accept path.

Error Messages/Logs

Steps to Reproduce

On Windows (11), using the Claude Code VSCode extension (not the terminal CLI), open a UTF-8 file without BOM that uses CRLF line endings and contains non-ASCII characters (e.g. German umlauts ä/ö/ü, guillemets « »). A .md file works well.
Make sure edits require manual confirmation (i.e. NOT in accept-edits / auto-accept mode).
Have Claude run an Edit that replaces an existing paragraph containing umlauts, using an old_string that is present in the file verbatim (confirm with grep -n "…" that it matches byte-for-byte).
At the confirmation window, approve the edit.
Observe the failure: String not found in file. Failed to apply edit.
Now switch to accept-edits mode (Shift+Tab) and run the identical edit again → it succeeds.
Reproduces consistently. The only variable that changes the outcome is manual confirmation vs. auto-accept.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.216

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_