After updating to Cursor 3.3.27, the Source Control view mis-renders non-ASCII (UTF-8) file names (e.g. Chinese .md files). Names appear as escaped octal sequences (e.g. \345\256\236\336\346\226\275...) instead of the real characters. Opening the diff shows “Diff content not available” / “This file changed, but a text diff could not be rendered.” for these files.
This started right after today’s update; behavior was OK before.
Actual
File names show as octal-escaped segments.
Diff pane: “Diff content not available” for those files.
Notes / hypothesis
Looks similar to Git path quoting / encoding issues (e.g. core.quotePath or wrong locale when Git output is parsed), possibly a regression in the SCM provider or bundled Git integration after this build.
Thank you.
Steps to Reproduce
Steps to reproduce
Open a Git repository that contains new or modified files whose paths include UTF-8 / Chinese characters (e.g. under docs/tasks/...).
Open Source Control.
Observe file names in the changes list and open the diff for one of these files.
Hey, thanks for the detailed report with the screenshot and environment info. This looks like a classic Git path quoting case. When core.quotePath=true (default), Git escapes non-ASCII characters in ls-files and status output, and if a consumer parses that output as-is, you get exactly what you see in your screenshot.
Try this workaround:
git config --global core.quotePath false
After that, restart Cursor and check the Source Control panel in the same repo. If the names render correctly and the diff opens, that confirms the hypothesis, and we can look on the Cursor side at what changed around 3.3.27.
Let me know if it helped or not. If you can, also share the output of git --version on that machine.
Thanks for the quick reply and the clear explanation.
I ran:
git config --global core.quotePath false
After restarting Cursor, the Source Control view shows the Chinese file names correctly and the diffs open normally for those files, so this matches your core.quotePath hypothesis.
For reference, on this machine:
git version 2.50.1 (Apple Git-155)
Appreciate the workaround; I’ll keep an eye out for a proper fix on the Cursor side if anything regressed in 3.3.27. Let me know if you need anything else from my setup.
Great, thanks for confirming and for the git version. Since core.quotePath=false fixes it, that matches the diagnosis. One of the paths used when reading git status in Cursor is missing a flag that disables escaping. I’ll file this on our side so you won’t need to keep the workaround. I can’t share an ETA for the fix yet, but I’ll post an update in the thread as soon as I have one.
If anything else weird comes up after 3.3.27, drop it here.