VSCode: Biome shows incorrect lint errors when files are changed externally

[timohausmann]

Hello, every day I run into this issue: Whenever my external Codex AI agent modifies code I'm working on in VSCode, Biome gets stuck and some ghost errors. When I press Cmd+S, sometimes they resolve, sometimes they get even worse.

In this video, you can see some incorrect lint errors. I hit Cmd+S, and some additional ghost code appears, that is completely broken. Then I hit Cmd+Z and Cmd+S again, and then it's finally correct.

Any idea what is causing this and how I can solve it?

Bildschirmaufnahme.2026-04-23.um.10.34.23.mov

Edit: I also get this when git changes files, e.g. by reseting or pulling. Biome console says:

2026-05-06 13:13:27.014 [info]   Message: failed to access range Range { start: Position { line: 0, character: 0 }, end: Position { line: 492, character: 0 } } in document file:///Users/....tsx LineIndex { newlines: [0, 74, 75, 84, 99, ..., 15997], line_wide_chars: {} }
  Code: -32603 
failed to access range Range { start: Position { line: 0, character: 0 }, end: Position { line: 492, character: 0 } } in document file:///Users/....tsx LineIndex { newlines: [0, 74, 75, 84, 99, ... 15997], line_wide_chars: {} }

Caused by:
    position Position { line: 492, character: 0 } is out of range

[Sir-Sloth-The-Lazy]

This is a known LSP buffer synchronization issue that occurs when files are modified externally while VSCode has them open.

What's happening under the hood:

When your AI agent writes to a file on disk, VSCode detects the change via its file system watcher. If the file has no in-editor unsaved changes, VSCode silently reloads the disk version. But when there is any in-memory buffer state — even just cursor position or undo history — VSCode may keep its stale buffer rather than reloading, and then sends that stale content to the Biome language server via textDocument/didChange LSP notifications. Biome then lints the stale/mixed content, producing ghost errors. The Cmd+Z → Cmd+S cycle works because it fully reverts the buffer to a clean state before syncing.

Workarounds (in order of effectiveness):

1. Use "Revert File" instead of Cmd+Z + Cmd+S

Cmd+Shift+P → Revert File forces VSCode to discard the in-memory buffer and reload from disk cleanly. This is the correct fix when an external process has modified the file.

2. Configure VSCode to auto-reload externally changed files

Add this to your settings.json:

{
  "files.hotExit": "off"
}

And ensure your workspace does not have unsaved changes that would block the auto-reload prompt.

3. Save before your AI agent runs

If you can hook into your Codex agent's workflow, trigger a workbench.action.files.saveAll before the agent starts writing. A clean saved state means VSCode will silently reload the disk version when the agent finishes.

4. Enable autosave with a short delay

{
  "files.autoSave": "afterDelay",
  "files.autoSaveDelay": 500
}

This keeps the editor buffer closer to disk state, reducing the window where a desync can occur.

Is this a Biome bug?

Partially. Biome's LSP extension should handle workspace/didChangeWatchedFiles notifications and reconcile its internal state with the disk version when it detects an external change. If Biome is relying solely on textDocument/didChange (editor-driven updates) and not didChangeWatchedFiles (file system-driven updates), it will always be vulnerable to this desync when external tools modify files. Worth opening a bug report with the video you have if the above workarounds don't fully resolve it.

[ematipico]

This is a known LSP buffer synchronization issue that occurs when files are modified externally while VSCode has them open.

First: LSP, as per name, is a specification, it can't have "synchronization issues".

Second: where is this claim coming from? Without links, we can't verify it.

[timohausmann]

Sadly none of these work.

1.: The revert file command does not help in this case.
2.:files.hotExit is about whether VSCode will ask you about unsaved files upon exit, it makes no difference here.
3. I always save before the agent runs.

Must be some weird edge-case on my system, if everyone had this issue, we would know.