Cursor Appears in Wrong Position But Inserts Text at Correct Position

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I click at the end of a line, the cursor visually appears somewhere in the middle of the line instead of at the actual end. However, when I start typing, the characters are inserted at the correct (actual) end of the line, not where the cursor is shown…
This issue has been old for a year and it looks like nobody cares about it… I’m generally new here and this is my first subscription, but this IDE is totally unusable for me like this.
About my config, this is only what I have.

	"editor.cursorBlinking": "expand",
	"editor.cursorWidth": 2,
	"editor.wordWrap": "on",
	"editor.fontFamily": "JetBrains Mono",
	"editor.fontLigatures": false,
	"editor.renderWhitespace": "none",
	"editor.lineHeight": 24,
	"editor.fontWeight": 300,
	"editor.fontSize": 14,

And sometimes when I resave the same config, the cursor goes back to the right position.

Steps to Reproduce

  1. Open any file.
  2. Click at the end of a long line of text.
  3. Observe that the cursor appears in the middle of the line.
  4. Type any character.
  5. The character appears at the actual end of the line, not where the cursor was shown.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.12.10 (user setup)
VS Code Extension API: 1.128.0
Commit: 24a12dbd9cabf48956ce5bb3dbd234e41385b3d0
Date: 2026-07-16T03:15:48.538Z
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.256
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. This is a known bug in how the editor Monaco and VS Code measures monospace character widths. The caret position is calculated from the measured glyph width, and if the font isn’t available at measurement time or the metrics don’t match, the caret can look shifted. Insertion still happens at the real column, so the text lands in the correct place. Re saving the config helps because it forces a font re measure.

In your config, the main suspect is "editor.fontWeight": 300. The Light variant of JetBrains Mono often isn’t installed on Windows and gets silently replaced by another font with different glyph widths. Try this in order:

  1. Remove "editor.fontWeight": 300 or set it to 400, and make sure JetBrains Mono is actually installed on Windows.
  2. Run Developer: Reload Window Ctrl+R. This forces a re measure, same effect as re saving the config.
  3. To narrow it down, temporarily switch to a default font like Consolas and or set "editor.wordWrap": "off", then see if the drift goes away.

Related threads with the same breakdown:

Root cause is upstream in VS Code and Chromium font rendering, so it’s hard to fully fix on our side, and there’s no ETA. But the workarounds above usually remove the drift. Let me know if it helped, especially if the caret still shifts even on a default font with no custom fontWeight.

6

The same issue happens when I set “editor.fontWeight” to “normal” or when I remove that line. Just to be clear, VSCode doesn’t have this problem with same font.

7

Thanks for checking. The fact that VS Code on the same machine with the same font behaves fine is a useful detail, it narrows things down.

To pinpoint it more accurately, could you please confirm a couple of things:

  1. Does the drift still happen if you temporarily switch to a fully default font like Consolas, remove editor.fontWeight, and set "editor.wordWrap": "off"? I’m specifically asking for this exact combo, to rule out both the font and line wrapping.
  2. What Windows display scaling are you using 100, 125, or 150 percent, and what’s your current window or editor zoom level Ctrl+= or Ctrl+-? Fractional DPI scaling is a common trigger for subpixel caret drift, and a zoom difference between Cursor and VS Code could explain the mismatch.

This class of issue is known, but I’ll also log this specific case where VS Code is OK and Cursor is not on the same machine. I can’t give an ETA for a fix, but your answers above will help me describe it more clearly to the team. If you can share the results for item 1 and your scaling and zoom settings, that’d be great.

8

Well something is definitely wrong here. I notice that actually fontWeight is completely ignored for some fonts. Example:
"editor.fontFamily": "JetBrains Mono",
"editor.fontWeight": 300,

This works fine in VSCode and this is basically JetBrains Mono Light, but in Cursor this does not work for some reason. I need to define the font like “editor.fontFamily”: “JetBrains Mono Light”,

Definitely something under the hood is wrong here regarding fonts. And about Consolas and disabled wordWrap, I can’t reproduce the same issue.

But "editor.wordWrap" doesn’t matter if it’s ON or OFF with other fonts like JetBrains.

9

Thanks, this is exactly the detail that clears everything up. You got it right: in Cursor, a numeric editor.fontWeight (300) for JetBrains Mono doesn’t pick up the Light variant the way VS Code does, so it falls back to a different face with different glyph metrics. That’s why the caret drifts on long lines. The fact that there’s no drift with Consolas and with no fontWeight also confirms it.

The working workaround you already found is to set the variant explicitly via the family:

"editor.fontFamily": "JetBrains Mono Light"

and not rely on a numeric editor.fontWeight. This fixes both the caret desync and the ignored weight issue.

I’ve logged this specific case with your isolation steps. This is a known class of issue, I can’t give a precise ETA for a fix, but the workaround above should get things back to normal. If you hit another font where weights behave the same way, post it here, it helps us narrow the issue down.

11

Yes, after a few days of testing, I can confirm that "editor.fontFamily": "JetBrains Mono Light" works fine, so the problem is fontWeight. Maybe this will help someone because this looks like a problem not just for me.