Encoding errors on new files

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the agent creates a new file and writes accented text to it, encoding is not properly handled. This only happens when the agents create the new file. The new file encoding is utf-8.

Steps to Reproduce

Ask the agent to create a new text file and write a paragraph, in Portuguese, with some accents on it. The text generation seems to be correct, as displayed in the reasoning streamed text. However, when the agent finishes writing to the file, the accents on the saved file are corrupted.

Expected Behavior

Text should be written without encoding errors.

Operating System

Windows 10/11

Version Information

Version: 3.5.33 (user setup)
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
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

For AI issues: which model did you use?

All (the issue is not model specific)

For AI issues: add Request ID with privacy disabled

bb0409ec-75f6-419e-ab77-aa2425fe7608

Additional Information

The bug seems to be related to the tool the agent uses to write on the file. The file encoding is correct (UTF-8). This does not happens on latest 2.x version.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report with the Request ID and the note about the 2.x regression. That really helps.

This is a known bug. When creating new files, the agent write tool sometimes detects the encoding from nearby files in the workspace and re-encodes UTF-8 content into Windows-1252, GBK, or another local encoding, which breaks multi-byte characters like Portuguese accents, CJK, and so on. It happens especially often on Windows. We’re tracking the issue, but I can’t share an ETA for a fix yet. Once we have an update, we’ll reply in the thread.

If you find a setup where the bug consistently doesn’t reproduce, like with a specific files.encoding setting or in an empty workspace, please let us know. That’s a useful signal.

7

I am hitting the same issue reported in this thread.

I’ve been working on legacy Eclipse-style Java projects that use Latin-1 / Windows-1252 encoding with CRLF line endings. Whenever Cursor’s Agent edits those files (Write / StrReplace), I get encoding conflicts that corrupt localized string literals, user-facing messages, and comments in the source.

Where does the bug appear (feature/product)?

  • Cursor IDE — Agent tools: Write / StrReplace

Describe the Bug

On Windows, Agent file edits persist text with the wrong byte encoding. The chat shows correct characters, but on-disk bytes are corrupted (mojibake such as Preço / Documentação, or other wrong encodings depending on the case).

This happens both with:

  1. UTF-8 Portuguese content (documentation / rules), and
  2. Legacy Latin-1 / Windows-1252 + CRLF codebases (localized literals, messages, and comments get broken on every Agent edit).

files.encoding, .editorconfig, and manual editor saves do not fix the Agent write path. The problem affects any workspace, including folders outside Git.

Steps to Reproduce

  1. Windows 10/11 (e.g. 10.0.26200), Cursor Agent/Composer.
  2. Either:
    • ask the Agent to create/edit a .md file containing: Documentação — Preço — Análise, or
    • open a legacy project saved as Windows-1252 / Latin-1 (CRLF) and ask the Agent to edit a file that contains accented Portuguese in strings/comments.
  3. Reopen the file or inspect bytes on disk: accents are corrupted.

Control: writing the same content via Node fs.writeFileSync(path, content, 'utf8') (or an explicit Windows-1252 write for legacy files) produces the correct bytes (e.g. UTF-8 c3 a7 for ç).

Expected Behavior

  • Agent tools honor files.encoding / .editorconfig.
  • For existing files: detect encoding on disk (BOM, UTF-8 vs Windows-1252/Latin-1) and write back in the same encoding, preserving non-ASCII bytes and EOL (CRLF when that is the file convention).
  • For new UTF-8 files: UTF-8 without BOM by default.
  • String-to-bytes on the Agent write path must never silently use a wrong/platform default charset.

Screenshots / Screen Recordings

N/A — easiest check is byte inspection or reopening the file after an Agent edit (mojibake visible immediately).

Operating System

  • Windows 10/11

Additional Information

Does this stop you from using Cursor?

  • Sometimes — Agent is unreliable/unusable for Portuguese documentation and for edits in Latin-1 / Windows-1252 legacy projects; we have to reject diffs or repair files outside the Agent.
Version: 3.14.7 (user setup)
VS Code Extension API: 1.128.0
Commit: a758f2241ca99fecf380180b6cbdbbce0f1f42c0
Date: 2026-07-30T06:41:34.009Z
Layout: IDE
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.26200
8

Hey, thanks for the detailed report, especially the control test with fs.writeFileSync(..., 'utf8') and confirming it still reproduces in 3.14.7. That’s a helpful signal.

This is a known issue. When writing files, the agent Write and StrReplace tools sometimes pick up the encoding from nearby files in the workspace and re-encode UTF-8 content into Windows-1252, Latin-1, GBK, or UTF-16, which breaks multi-byte characters like Portuguese accents. This shows up especially often on Windows, and files.encoding or .editorconfig don’t override the agent’s current write path. We’re tracking it, but I can’t share a fix timeline yet. When there’s an update, I’ll post it in the thread.

As a temporary workaround, since your Node control test writes correctly, you can ask the agent to write or edit those files via the terminal with an explicit encoding, for example fs.writeFileSync(path, content, 'utf8') for UTF-8, or an explicit Windows-1252 for legacy files, instead of using the built-in write tool. In that case the bytes stay correct.

If you find a setup where the issue consistently does not reproduce, like a specific files.encoding value or an empty workspace, let me know. That also helps narrow down the cause.

9

Thank you for your response.

Is there an estimate of when we’ll have a package with this fix? I ask this because the proposed workaround is stressful, time-consuming, and impractical: if, every time I interact with the agent, I have to worry about the encoding of the files it’s handling, I’m bound to end up re-encoding them myself, with the agent merely providing the location and the changes to be made—which completely negates the practicality and usefulness of agents in supporting multi-agent development.

Why isn’t this bug being prioritized? You’re overlooking an important use case for your tool: converting legacy applications to modern stacks, and scenarios where this must be done in phases. The problem is that with this type of bug, the tool causes immense setbacks during recovery, and in some scenarios, the loss is irreparable: I’ve had cases where hours of work went down the drain because the Cursor context was lost, and the result had broken encoding. I had to revert the code to HEAD and start all the work over, and once again I ran into encoding issues.

This is unacceptable for a tool of Cursor’s stature. It seems to me that the company doesn’t care about legacy projects, disregarding the potential leverage these very projects hold in today’s competitive market.

And let’s be honest: this isn’t the only mention of issues with identifying or reproducing encoding artifacts here on the forum. The company needs to realize that this is a problem that’s already affecting the product in various ways. If the company doesn’t take this seriously, customers will start looking at other products that are more attentive to or focused on issues like this.

12

I get that the suggested workaround, explicitly writing from the terminal, isn’t a real fix, it’s a hack. And in a streaming workflow with the agent, it really breaks the whole point of automation. I won’t argue with that.

On the ETA, I can’t give a specific date, and I don’t want to make a promise I can’t back up. What I can say honestly is that we’re tracking this issue, and we’ve accounted for the impact, including legacy Windows-1252 or Latin-1 projects and CRLF. The priority has already been raised. As soon as there’s an update, I’ll reply right here in this thread.

Until there’s a fix, to protect your work, keep the files under version control with frequent commits so rolling back to HEAD doesn’t cost you hours. Sounds like you’re already doing that, but just calling it out.

And if you run into a setup where the issue reliably does NOT reproduce, like a specific files.encoding value, an empty workspace, or a particular set of neighboring files in the folder, post it here. That really helps narrow down the root cause.

13

Has anyone else run into this and found a better fix? Would really appreciate any other ideas — thanks so much in advance!

14

Hey @luis_aleb. For now the only reliable workaround is the one described earlier in the thread: ask the agent to write or edit files via the terminal with an explicit encoding, instead of using the built-in Write or StrReplace tool. For example, for UTF-8:

node -e "require('fs').writeFileSync('path/to/file', content, 'utf8')"

For legacy files in Windows-1252 or Latin-1, explicitly set the matching encoding when writing. In that case the bytes stay correct. Unfortunately, files.encoding and .editorconfig don’t override the agent’s current write path.

Until there’s a fix, to avoid losing work, keep your files under version control and commit often. Then rolling back to HEAD won’t cost you hours.

We’re tracking this issue. I can’t share an exact timeline for a fix yet, but once there’s an update I’ll reply right here in the thread. Also, if you find a setup where the issue consistently does NOT reproduce, like a specific files.encoding value, an empty workspace, or a particular set of nearby files, please post it here. That helps narrow down the cause.

15

Same issue on Plan mode (CreatePlan) saving to %USERPROFILE%.cursor\plans*.plan.md on Windows 10.0.26200.

Input to CreatePlan is correct UTF-8 (verified in agent transcript: “sincronização” = bytes C3 A7 C3 A3).
Saved file has literal ? (0x3F): “sincroniza??o” — 213 question marks, zero UTF-8 multibyte sequences.

Related: plan.md thread #162873. This is the ASCII-replacement variant (? per char) rather than mojibake or UTF-16.

16

Hey, thanks for the detailed report and the byte-level check. The ? (0x3F) case instead of mojibake or UTF-16 is a useful detail, I added it to what we’re tracking.

This looks like the same class of issue discussed in the thread. The agent write path is re-encoding valid UTF-8 into the wrong encoding. In your case, for the plan file in %USERPROFILE%\.cursor\plans, it falls back to the system encoding, and characters that encoding can’t represent get collapsed into ?. I’ve shared this with the team and we’re tracking it. I can’t give an exact timeline yet, but I’ll post an update right here when we have one.

To be transparent, the workaround from earlier in the thread, writing via terminal with an explicit encoding, is harder to apply here because CreatePlan generates the file automatically, so you can’t intercept the write. If the plan file ends up corrupted, the most reliable option for now is to recreate it or manually fix the file encoding after it’s generated.

Also, if you find a configuration where the issue reliably does not reproduce, for example a specific files.encoding value, an empty workspace, or a certain set of nearby files, please reply here. That really helps narrow down the cause.

17

Guys, let me be frank with you:

My team and I use Cursor in the evolution of legacy Java projects, and due to the initial configurations of these projects, based on Eclipse, ever since we started using Cursor as a Coding Agent, we’ve had issues with the encoding being Cp1252 for “.java” files and ISO-8859-1 for web files (html, jsp, xml, css, js).

We are forced to use Eclipse and Cursor in parallel in our development, due to the deficiencies of VS Code/Cursor tools compared to Eclipse, but this isn’t the biggest problem.

When the agent is editing the components, even if the workspace has the settings pointing to the correct encoding, the file is completely overwritten, disregarding the original encoding and breaking the project’s localized strings. The rework is infuriating, because the tool should be an accelerator, not a cause of problems.

I’ve already tried to work around the problem in several ways: creating rules in the project with the EditorConfig plugin, avoiding the use of multi-root workspaces (which is counterproductive to our needs), reinforcing the prompt, ensuring better workspace or project configurations; however, none of this matters, as the prompt doesn’t consider any of it.

I’ve been evaluating the possibility of requesting the prompt to create code that implements my requirements, instead of it doing it itself, but that’s a waste of tokens/money.

All I ask of you is that you dedicate more attention to this. It doesn’t seem to me that this fix is ​​so big and impactful that it will hinder the delivery of your product, but I guarantee that not doing it tarnishes the product’s image, demonstrating how much you ignore the needs of your customers.

The links above only appear in a simple internet search, but I’m sure that if we delve deeper, we’ll find complaints in many other places. And of course, many people have already stopped using your tool because of the neglect in resolving something that has been clear for a long time. Is it really that difficult to focus efforts on fixing such an obvious issue?

19

Hey, got it. The details about the legacy stack are helpful: Cp1252 for .java, ISO-8859-1 for web files (html, jsp, xml, css, js), plus the fact that editorconfig, not using a multi-root workspace, and a stronger prompt don’t change anything. That matches what we’re already seeing: files.encoding and .editorconfig currently don’t intercept the agent’s write path, and when a file is overwritten, its original encoding isn’t preserved. I shared this with the team and added it to what we’re tracking.

On priority, I don’t want to hand-wave this away. This isn’t being ignored, the priority has already been raised. I’ll only say what I can stand behind: I don’t have an exact fix date yet, and I won’t promise a specific release. As soon as I have an update, I’ll post it right here in the thread.

Until there’s a fix, the only reliable workaround is the one mentioned earlier in the thread: ask the agent to write or edit files via the terminal with an explicit encoding, not the built-in Write or StrReplace. For legacy files, set the charset the file is already using, for example Windows-1252 or Latin-1:

node -e "require('fs').writeFileSync('path/to/File.java', content, 'latin1')"

I get that this breaks the whole idea of automation in a streaming agent workflow. It’s a workaround, not a solution. That’s why it’s especially important to keep files under version control and commit often, so reverting to HEAD doesn’t cost hours of work.

And if you find a setup where the issue consistently does NOT reproduce, like a specific files.encoding value, an empty workspace, or a particular set of nearby files in the folder, post it here. Those signals really help narrow down the root cause.