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:
- Remove
"editor.fontWeight": 300or set it to400, and make sure JetBrains Mono is actually installed on Windows. - Run Developer: Reload Window
Ctrl+R. This forces a re measure, same effect as re saving the config. - 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.