Iterating with shadow workspaces

Summary

Cursor’s shadow workspace addresses the problem of letting AI agents iterate on code without disrupting a developer’s active workspace. The design prioritizes LSP usability—especially lints, definition navigation, and language-server interaction—while also requiring independence, privacy, concurrency, universality, maintainability, and speed. A copied in-memory TextModel was rejected because sharing the user’s language server could introduce copied files into references, duplicate declarations, or miss errors. The implemented approach uses a reusable hidden Electron window for the workspace, routing AI edits through Cursor’s processes and returning lints independently of the visible editor. The post treats runnability as a harder future extension, with folder-proxy designs, platform limitations, and network-level independence still open questions.

Takeaways

1. 1

   Copying an in-memory TextModel preserves the user’s file but still exposes the copied file to the same language server, causing issues such as duplicate declarations and misleading references.

2. 2

   The hidden-window implementation isolates AI edits from the visible workspace while reusing Cursor’s existing language-server and extension infrastructure.

3. 3

   Runnability remains unresolved; proposed directions include kernel-level or FUSE-based folder proxies, with macOS, Windows, and network-level independence posing open questions.