# Cursor AI edits corrupt Windows-1252 encoding in C++ projects (even when editor shows 1252) **URL:** \ **Category:** Bug Reports\ **Tags:** inline-edit, c-cpp, windows, review\ **Created:** [February 3, 2026, 12:19pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701 "2026-02-03T12:19:47Z")\ **Posts on this page:** 17\ **Page:** 4
**Author:** ![Leonel\_Silva](https://avatars.discourse-cdn.com/v4/letter/l/eada6e/32.png) [@Leonel\_Silva](https://forum.cursor.com/u/Leonel_Silva)\ **Post date:** [April 1, 2026, 3:41am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/85 "2026-04-01T03:41:43Z")
bugged all files convert auto save utf8 ---
**Author:** ![Leonel\_Silva](https://avatars.discourse-cdn.com/v4/letter/l/eada6e/32.png) [@Leonel\_Silva](https://forum.cursor.com/u/Leonel_Silva)\ **Post date:** [April 1, 2026, 4:00am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/86 "2026-04-01T04:00:51Z")
beta working fix bug **[Cursor AI edits corrupt Windows-1252 encoding](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701)** ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [April 1, 2026, 9:59am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/88 "2026-04-01T09:59:38Z")
Hi @Joyfullservice! The reproducer that @Tomasz_Siedlaczek provided earlier proved quite useful. > [@Tomasz\_Siedlaczek](#): > > [delphi7.7z](https://forum.cursor.com/uploads/short-url/jGhoyRhC2qhF1E9rfbuoghtRcUf.7z) (329 bajtów) > > Hello Ani, > I am sending two files: **Unit1 - kopia.pas** , the original file from the Delphi 7 IDE, and **Unit1.pas** , which was edited and saved by Cursor, despite my request not to modify any comments, messages, etc. > > Regards, > Tomasz If you could provide something similar, we can have another look! ---
**Author:** ![Tomasz\_Siedlaczek](https://avatars.discourse-cdn.com/v4/letter/t/b3f665/32.png) [@Tomasz\_Siedlaczek](https://forum.cursor.com/u/Tomasz_Siedlaczek)\ **Post date:** [April 1, 2026, 2:25pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/89 "2026-04-01T14:25:48Z")
Hi, Since switching to the Beta 2.7.xxx nightly build, the problem has disappeared. The cursor now correctly reads Windows-1250 encoded files and gracefully saves them back using the same encoding 🙂 Because of this, I am no longer able to provide a corrupted file, which is actually the perfect outcome from my perspective. Regards, Tomasz ---
**Author:** ![Joyfullservice](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/joyfullservice/32/98498_2.png) [@Joyfullservice](https://forum.cursor.com/u/Joyfullservice)\ **Post date:** [May 1, 2026, 1:39pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/90 "2026-05-01T13:39:57Z")
Just as an update, this problem still exists in the latest version of Cursor. It is not every time, but occasionally files will still get mangled. Most of the time it is line endings being changed from CRLF to LF, but sometimes the UTF-8 BOM is also stripped. This happens every single day. While there has been some improvement in the newer versions, the problem is definitely not fully resolved. Version: 3.3.0 (user setup) VSCode Version: 1.105.1 Commit: 199f9dfab72daeb2f76c4aad066fd9aeea196d10 Date: 2026-04-30T22:46:00.300Z Layout: editor Build Type: Stable Release Track: Default Electron: 39.8.1 Chromium: 142.0.7444.265 Node.js: 22.22.1 V8: 14.2.231.22-electron.0 OS: Windows\_NT x64 10.0.26100 ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [May 5, 2026, 4:36pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/91 "2026-05-05T16:36:37Z")
Hey @Joyfullservice! If you’re able to share a reproducer like here: > [@Tomasz\_Siedlaczek](#): > > [delphi7.7z](https://forum.cursor.com/uploads/short-url/jGhoyRhC2qhF1E9rfbuoghtRcUf.7z) (329 bajtów) > > Hello Ani, > I am sending two files: **Unit1 - kopia.pas** , the original file from the Delphi 7 IDE, and **Unit1.pas** , which was edited and saved by Cursor, despite my request not to modify any comments, messages, etc. > > Regards, > Tomasz That helps out a ton. I know it’s not trivial since it doesn’t happen everytime, but if you’re able to record a specific instance, what the agent did (what tools ran) and a before/after, it gets us much closer! ---
**Author:** ![Joyfullservice](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/joyfullservice/32/98498_2.png) [@Joyfullservice](https://forum.cursor.com/u/Joyfullservice)\ **Post date:** [May 7, 2026, 1:40pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/92 "2026-05-07T13:40:34Z")
As a further update, I have been able to do some heavy programming work for the last couple of days, and I don’t believe I encountered the issue… Hopefully this means that some of the fixes have been incorporated into the core software. I will let you know if this starts happening again. Version: 3.3.12 (user setup) VSCode Version: 1.105.1 Commit: 75c0dfd29aecf2cc208dbaf761d5cc459c601aa0 Date: 2026-05-06T03:47:52.249Z Layout: editor Build Type: Stable Release Track: Default Electron: 39.8.1 Chromium: 142.0.7444.265 Node.js: 22.22.1 V8: 14.2.231.22-electron.0 OS: Windows\_NT x64 10.0.26100 ---
**Author:** ![Joyfullservice](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/joyfullservice/32/98498_2.png) [@Joyfullservice](https://forum.cursor.com/u/Joyfullservice)\ **Post date:** [May 7, 2026, 5:17pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/93 "2026-05-07T17:17:53Z")
I spoke too soon! The bug bit again, but this time Opus 4.6 was able to get to the bottom of it… # Cursor Auto-Update Restart Rewrites Open Files with LF Line Endings ## Summary When Cursor auto-updates and restarts, files that were open in editor tabs are rewritten to disk with LF (`\n`) line endings, even when `.editorconfig` specifies `end_of_line = crlf` and `.gitattributes` specifies `eol=crlf`. The file content is unchanged — only the line endings are silently converted from CRLF to LF. This causes `git status` to report the files as modified with no actual content differences. This appears to be a session-restoration issue: during restart, the editor reopens previously-open tabs from its internal model (which normalizes line endings to LF internally) and writes them back to disk without consulting `.editorconfig` or `.gitattributes`. ## Environment - **OS** : Windows 10 (10.0.26200) - **Cursor versions** : Observed during update from 3.2.21 to 3.3.12 - **Shell** : PowerShell 7 - **Project** : VBA source files requiring CRLF + UTF-8 BOM for import into Microsoft Access ## Project Configuration `.editorconfig`: ```ini root = true [*] end_of_line = crlf [*.{bas,cls,form,report,qdef,macro,sql,frm,json,xml,txt}] charset = utf-8-bom end_of_line = crlf ``` `.gitattributes`: ```auto *.bas text eol=crlf *.cls text eol=crlf *.sql text eol=crlf # (and similar for other extensions) ``` ## Steps to Reproduce 1. Open a project that has `.editorconfig` with `end_of_line = crlf` and `.gitattributes` with `eol=crlf` 2. Open several CRLF-encoded files in editor tabs 3. Verify `git status` is clean (no modifications) 4. Allow Cursor to auto-update (or trigger a restart that causes session restoration) 5. After restart, run `git status` ## Expected Behavior Files open in editor tabs should be unchanged on disk after the restart. The session restoration should respect `.editorconfig` and `.gitattributes` line-ending settings when writing file content back to disk. ## Actual Behavior All files that were open in editor tabs are rewritten with LF-only line endings. `git status` reports them as modified. `git diff` shows no content changes — only the CRLF-to-LF conversion triggers the modification flag: ```auto $ git diff --stat warning: in the working copy of '...clsDbProperty.cls', LF will be replaced by CRLF the next time Git touches it warning: in the working copy of '...clsDbQuery.cls', LF will be replaced by CRLF the next time Git touches it (etc. for all affected files) $ git diff --numstat (empty — no content changes, only line-ending differences) ``` ## Evidence from Logs ### Cursor update triggered the restart Previous session log (`%APPDATA%\Cursor\logs\20260506T113936\main.log`): ```auto 2026-05-06 11:39:37.062 [info] updateURL .../cursor/3.2.21/... 2026-05-06 11:39:54.586 [info] update#setState checking for updates 2026-05-06 11:39:54.640 [info] update#setState downloading 2026-05-06 11:39:59.367 [info] update#setState downloaded 2026-05-06 11:39:59.368 [info] update#setState updating 2026-05-06 11:42:38.858 [info] Extension host with pid 19296 exited with code: 0 (all extension hosts exit) ``` New session log (`%APPDATA%\Cursor\logs\20260506T114347\main.log`): ```auto 2026-05-06 11:43:48.394 [info] updateURL .../cursor/3.3.12/... 2026-05-06 11:43:48.394 [info] update#setState idle ``` ### File corruption timestamp matches session restore exactly All 7 corrupted files had the **exact same modification timestamp** : `5/6/2026 11:43:52 AM`. The renderer log (`window1\renderer.log`) confirms extension hosts starting at this exact second: ```auto 2026-05-06 11:43:52.056 [info] Started local extension host with pid 25944. 2026-05-06 11:43:52.264 [info] Placing extension(s) anysphere.cursor-retrieval on a separate extension host. 2026-05-06 11:43:52.265 [info] Placing extension(s) anysphere.cursor-always-local, ... 2026-05-06 11:43:52.314 [warning] [ms-python.python]: Cannot register 'python.venvPath'. ... 2026-05-06 11:43:52.623 [info] Started local extension host with pid 25812. 2026-05-06 11:43:52.624 [info] Started local extension host with pid 25508. 2026-05-06 11:43:52.624 [info] Started local extension host with pid 15916. ``` ### Filesync log confirms the corrupted files were in editor tabs The Filesync log (`window1\exthost\anysphere.cursor-always-local\Filesync.log`) shows each corrupted file being synced as a visible editor tab after the restart: ```auto Uploaded file ...clsDbTableDef.cls modelVersion=3 Uploaded file ...clsDbImexSpec.cls modelVersion=3 Uploaded file ...clsDbProperty.cls modelVersion=3 Uploaded file ...clsDbTableData.cls modelVersion=3 Uploaded file ...clsDbQuery.cls modelVersion=3 Uploaded file ...modBuild.bas modelVersion=3 ``` Every file in this list was found with corrupted (LF-only) line endings. ### No agent tool call wrote to these files A thorough review of all agent transcripts confirms that **no** `Write`, `StrReplace`, or shell write command targeted any of these files. The corruption is entirely from the IDE’s session-restoration path — not from agent tooling. ## Affected Files (This Instance) | File | Content change? | In editor tab? | | --- | --- | --- | | `clsDbProperty.cls` | No | Yes | | `clsDbQuery.cls` | No | Yes | | `clsDbTableData.cls` | No | Yes | | `clsDbTableDataMacro.cls` | No | Yes | | `clsDbTableDef.cls` | No | Yes | | `clsDbImexSpec.cls` | No | Yes | | `modBuild.bas` | No | Yes | All files had CRLF before the restart. All had LF-only after. No content differences. Only the line endings changed. ## Impact For this project, CRLF line endings are mandatory — Microsoft Access’s `LoadFromText` API requires them for importing VBA source files. Silent CRLF-to-LF conversion makes the source files unusable for database builds until manually corrected. The corruption is invisible until `git status` is checked, and since the files show no content diff, it’s easy to accidentally commit or overlook. ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [May 7, 2026, 7:57pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/94 "2026-05-07T19:57:02Z")
@Joyfullservice I really want this to be it! I tried to reproduce on Windows 11 with the following setup: - Git repo with `core.autocrlf = false` and `core.eol = crlf` - `.gitattributes` with `* text=auto eol=crlf` and explicit `*.cls text eol=crlf` / `*.bas text eol=crlf` - `.editorconfig` with `end_of_line = crlf` and - 7 VBA source files (`.cls` and `.bas`) written with UTF-8 BOM + CRLF line endings - Committed with clean `git status` After restart, all files remained CRLF Did you have a different update path? Specifically: 1. Was it a background auto-update that prompted you to restart (i.e. Cursor downloaded the update on its own and you clicked a “Restart to Update” notification), versus you manually triggering it from the Help menu? 2. Did the files have unsaved changes (dirty state) at the time of the update, or were they saved but open in tabs? ---
**Author:** ![Joyfullservice](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/joyfullservice/32/98498_2.png) [@Joyfullservice](https://forum.cursor.com/u/Joyfullservice)\ **Post date:** [May 7, 2026, 8:45pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/95 "2026-05-07T20:45:33Z")
Here is what I currently have… A lot of tabs open (mostly plans, but maybe one of the affected files.) I have two Cursor windows open. Leaving the one window open, I close the second window. In the second window, I have 7 files that are showing the mangled LF endings. I open GitHub Desktop, revert all 7 changes so everything is clean. The current state: - One Cursor window open to another project. (This probably doesn’t matter) - All files in the example project are clean with CRLF endings. Reproduce the issue: - I open a new Cursor window to my project folder. - After the window loads, the same 7 files now have the mangled line endings. (I did not run anything or touch any tools. It was simply the loading of Cursor that messed up the files.) - Note that only these seven files were affected. Hundreds of other files are unchanged. These affected files would have been modified by now complete plans that were open in existing tabs. Is there a log file or state representation that would be helpful for you? Or a prompt that I could feed an agent to continue to the search? You can clone the exact project at [GitHub - joyfullservice/msaccess-vcs-addin: Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system. · GitHub](https://github.com/joyfullservice/msaccess-vcs-addin) Thanks! Adam ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [May 11, 2026, 8:16am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/100 "2026-05-11T08:16:30Z")
Adam, we’ve been able to reproduce this on our end using your repo with the exact pattern you described: Agent-edited files get their CRLF endings silently converted to LF on the next workspace open. Only files with prior Agent editing history are affected, which explains why earlier reproduction attempts with clean repos didn’t trigger it. This is being actively investigated by our engineering team. In the meantime, one thing worth trying as a workaround: before closing Cursor, check the **Review panel** (the diff icon in the sidebar) and accept or discard any pending changes from previous Agent sessions. If those cached states are cleared before close, the corruption shouldn’t trigger on the next open. Let us know if that helps reduce the frequency. Thanks for sticking with us on this and for sharing the public repo. ---
**Author:** ![Joyfullservice](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/joyfullservice/32/98498_2.png) [@Joyfullservice](https://forum.cursor.com/u/Joyfullservice)\ **Post date:** [May 11, 2026, 1:34pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/101 "2026-05-11T13:34:42Z")
Thanks for the update, Mohit! I appreciate the efforts on resolving this issue, and I am glad to hear that you are able to clearly reproduce it on your end. That makes troubleshooting a whole lot easier! 😃 ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [May 12, 2026, 9:18am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/106 "2026-05-12T09:18:34Z")
Hey everyone, the line ending conversion issue (where CRLF files were silently rewritten to LF on workspace open) has been fixed in a recent Cursor update. Updating to the latest stable version should resolve this. Let me know if you’re still seeing this after updating! ---
**Author:** ![DamGio](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/damgio/32/117423_2.png) [@DamGio](https://forum.cursor.com/u/DamGio)\ **Post date:** [August 13, 2026, 2:30am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/108 "2026-08-13T02:30:59Z")
Hola Thiago, \_pudiste resolver este tema? Comencé a utilizar Cursor con Delphi y al editar automáticamente los archivos pas si los reescribe rompe el encoding por mas que ponga reglas como el mismo Cursor me ha sugerido hacer. Gracias ! ---
**Author:** ![Bit](https://avatars.discourse-cdn.com/v4/letter/b/ea666f/32.png) [@Bit](https://forum.cursor.com/u/Bit)\ **Post date:** [August 14, 2026, 8:17am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/109 "2026-08-14T08:17:28Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug The Agent patcher appears to cache a file’s original encoding by path. If a Windows-1252 file is converted externally to UTF-8 during the same Agent session, a later patch silently writes it as Windows-1252 again. This can corrupt accented characters and produce invalid UTF-8. The patcher also ignores charset = utf-8 from .editorconfig. ### Steps to Reproduce 1. Create EncodingTest.cs as Windows-1252 without BOM with this content: internal class EncodingTest { private const string AccentedText = “Lo può fare.”; } 2. In a Cursor Agent chat, send this prompt: In EncodingTest.cs, add this field below AccentedText: private const string FirstAsciiText = “First patch.”; 3. Let the Agent apply the change to the file. 4. Using an external editor or script, convert EncodingTest.cs to UTF-8 without BOM. 5. Verify that “ò” is encoded as the UTF-8 bytes 0xC3 0xB2. 6. Add charset = utf-8 under [\*.cs] in .editorconfig. 7. Continue in the same Cursor Agent chat and send this prompt: In EncodingTest.cs, add this field below FirstAsciiText: private const string SecondAsciiText = “Second patch.”; 8. Let the Agent apply the change. 9. Inspect EncodingTest.cs again. The “ò” character has been written as the single Windows-1252 byte 0xF2, so the file is no longer valid UTF-8. ### Expected Behavior The patcher should detect the encoding from the file’s current bytes before every write and honor `.editorconfig`. After a file is converted to UTF-8, later patches should preserve UTF-8 instead of reusing previously cached encoding information. ### Operating System Windows 10/11 ### Version Information Version: 3.16.17 (user setup) VS Code Extension API: 1.128.0 Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0 Date: 2026-08-14T01:41:12.803Z Layout: Agent Window Build Type: Stable Release Track: Default Electron: 40.10.3 Chromium: 144.0.7559.236 Node.js: 24.15.0 V8: 14.4.258.32-electron.0 xterm.js: 6.1.0-beta.291 OS: Windows\_NT x64 10.0.22631 ### Does this stop you from using Cursor Yes - Cursor is unusable ---
**Author:** ![Michael\_Hutter](https://avatars.discourse-cdn.com/v4/letter/m/ac91a4/32.png) [@Michael\_Hutter](https://forum.cursor.com/u/Michael_Hutter)\ **Post date:** [October 6, 2026, 2:15pm UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/112 "2026-10-06T14:15:46Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug Environment: Cursor Agent, Windows, Delphi project (Codepage 1252, no BOM on .pas) ### Steps to Reproduce Steps: 1. Open a .pas file that contains CP1252 umlauts (e.g. byte 0xFC for ü in comments). 2. Ask the agent to apply a small ASCII-only StrReplace (one line changed). 3. Save result. ### Expected Behavior Expected: Only the edited line changes; all other bytes unchanged (CP1252 preserved). Actual: Whole file is rewritten as UTF-8. Unchanged lines with umlauts corrupt: - 0xFC (ü) → 0xFF or similar - 0xDF (ß) → 0x9D Delphi IDE then shows replacement characters. Request: When patching files, preserve original encoding (or honor files.encoding / workspace charset). For partial edits, write bytes for unchanged regions verbatim; encode only new/changed spans in the file’s encoding (CP1252 for our .pas). We work around with PowerShell CP1252 patch scripts + pre-commit verify; we’d prefer native agent/tools support. ### Operating System Windows 10/11 ### Version Information Version: 3.23.23 (user setup) VS Code Extension API: 1.128.0 Commit: 2dac2428994fe34f12658d9ecad1541b98db2c00 Date: 2026-10-05T01:43:43.807Z Layout: Agent Window Build Type: Stable Release Track: Default Electron: 42.10.0 Chromium: 148.0.7778.280 Node.js: 24.18.1 V8: 14.8.178.38-electron.0 xterm.js: 6.1.0-beta.291 OS: Windows\_NT x64 10.0.26200 ### For AI issues: which model did you use? Reproducible with Agent edits (StrReplace/Write); not model-specific. ### Does this stop you from using Cursor Sometimes - I can sometimes use Cursor [cursor-forum-encoding-repro.zip](https://forum.cursor.com/uploads/short-url/wtp4Wu7slHEgDpFBGtGgXleW26X.zip) (2,8 KB) ![DOS](https://us1.discourse-cdn.com/cursor1/original/3X/a/6/a6d5c94844a3521786a57cd880dc63c66a36441a.png) ---
**Author:** ![Michael\_Hutter](https://avatars.discourse-cdn.com/v4/letter/m/ac91a4/32.png) [@Michael\_Hutter](https://forum.cursor.com/u/Michael_Hutter)\ **Post date:** [October 7, 2026, 10:58am UTC](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701/115 "2026-10-07T10:58:06Z")
Merged from #173884 — same root cause on Delphi (.pas, CP1252, no BOM). Attached repro pack: minimal SampleUnit + Compare-Cp1252Bytes.cmd (see zip in merged post). Byte pattern: 0xFC/0xF6/0xE4 → 0xFF, 0xDF → 0x9D on unchanged lines after ASCII-only Agent StrReplace. We use `"files.encoding": "windows1252"` in `.vscode/settings.json` (workspace-wide). Zip includes healthy + simulated corruption; I can add before/after from a real Agent StrReplace on request. [cursor-forum-encoding-repro.zip](https://forum.cursor.com/uploads/short-url/2K4SCUYqkmvmuo04x3trSCG4H2t.zip) (4,5 KB) [Previous page](https://forum.cursor.com/t/cursor-ai-edits-corrupt-windows-1252-encoding-in-c-projects-even-when-editor-shows-1252/150701.md?page=3)