Bug: StrReplace tool strips UTF-8 BOM from files

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The StrReplace tool in Cursor removes the UTF-8 BOM (Byte Order Mark) when editing files, even if the file originally had UTF-8-BOM encoding. This causes issues for projects that require UTF-8-BOM encoding (e.g., proprietary systems, legacy codebases).

Actual Behavior

StrReplace strips the BOM and saves as UTF-8 without BOM.

Impact

  • High severity for projects requiring UTF-8-BOM
  • In our case: 102 files across 6-month project required manual BOM restoration after every batch edit
  • Manual PowerShell workaround needed after each edit

Real-World Context

Enterprise ERP project with proprietary language:

  • 102 source files edited to remove sensitive data
  • ALL require UTF-8-BOM for the proprietary compiler
  • Without BOM: compilation errors, incorrect display of special characters (Polish: ąćęłńóśźż)

Proposed Solution

Preserve original encoding (including BOM) when saving files - matching behavior of VS Code, Notepad++, etc.

Workaround

Run PowerShell after each StrReplace batch:

$content = Get-Content $file -Raw -Encoding UTF8
[IO.File]::WriteAllText($file, $content, [Text.UTF8Encoding]::new($true))

Environment: Windows 10.0.26200, Cursor latest version

Steps to Reproduce

  1. Create a test file with UTF-8-BOM encoding using PowerShell:

    $content = “test content”
    [System.IO.File]::WriteAllText(“test.fml”, $content, [System.Text.UTF8Encoding]::new($true))

  2. Verify the file has BOM (first 3 bytes should be EF BB BF)

  3. Use Cursor’s StrReplace tool to edit the file (any string replacement)

  4. Check encoding again - BOM is gone!

Expected Behavior

StrReplace should preserve the original file encoding, including BOM if present.

Operating System

Windows 10/11

Version Information

Version: 2.4.27 (user setup)
VSCode Version: 1.105.1
Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690
Date: 2026-01-31T21:24:58.143Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @IgorS!

Thanks for reporting. This will be fixed in 2.5.

1 Like