VSCode extension: apply edits to buffer via workspace.applyEdit() instead of writing to disk

Problem

When using Claude Code as a VSCode extension, if the user has unsaved edits in an open file, Claude's edits to that file don't appear in the editor. The user has to choose between their unsaved changes and Claude's changes — they can't coexist.

This happens because the extension writes edits to disk rather than applying them to the editor buffer. When the buffer is dirty (has unsaved changes), VSCode won't auto-reload from disk, so Claude's edits are silently invisible until the user manually resolves the conflict.

Expected behavior

Claude's edits should appear directly in the editor buffer alongside the user's unsaved edits, especially when the changes are in different parts of the file. Both sets of changes should coexist in the buffer and the user can save everything together when ready.

This is a natural workflow when using the extension — you're reading and editing a file while Claude works on a different section of the same file. The extension UX encourages this concurrent editing pattern, but the disk-write mechanism breaks it.

Suggested fix

Use the VSCode workspace.applyEdit() API to apply edits directly to the text document buffer instead of writing to the filesystem. This is the standard pattern for VSCode extensions that modify open documents — it merges cleanly with existing buffer state and doesn't trigger file-watcher conflicts.

Context

The terminal version of Claude Code doesn't have this problem in practice because the workflow naturally separates editing and Claude interaction — you save your file, switch to the terminal, let Claude work, and switch back to a clean reload. The extension removes that separation (which is its strength), but the disk-write behavior doesn't match the concurrent-editing UX it enables.