Implementing a WASI Host for Visual Studio Code

### Overview In this talk, Dirk Bäumer, a long-time Microsoft developer on Visual Studio Code, discusses the engineering efforts behind building a WebAssembly System Interface (WASI) host for VS Code, specifically targeting serverless web environments like vscode.dev and GitHub's web editor (triggered by pressing '.' on a repository). While VS Code on the desktop or via GitHub Codespaces relies on native local or virtual machine compute, vscode.dev runs entirely client-side in the browser. Historically, this meant editing files had syntax highlighting via TextMate grammars compiled to WebAssembly (Wasm), but lacked compute-heavy features like language interpreters, full terminal execution, and language servers for languages like Python, C++, Rust, and C#.

To bridge this compute gap without a backend server, the team turned to WASI Preview 1 (and looking ahead to Preview 2 and the Component Model) to run language runtimes and CLI tools directly in the browser.

### Key Topics - **Client-Side Compute in vscode.dev**: Enabling language runtimes directly in the browser without server instances, enabling code execution, terminals, and interactive REPLs. - **WASI Preview 1 Implementation**: Mapping POSIX file system expectations and WASI system calls onto VS Code's URI-based, asynchronous virtual file system architecture. - **Worker Architecture and Synchronization**: Managing the architectural mismatch between synchronous WASI calls and asynchronous VS Code extension host APIs using Web Workers, SharedArrayBuffer, and Atomics. - **Python and Multi-Language Demos**: Compiling CPython, Linux coreutils (via Rust), Ruby, and PHP to Wasm/WASI to deliver interactive shells and debugging in the browser. - **Real-World Adoption via VS Code EDU**: Applying this serverless Wasm stack to Microsoft's education platform so students can learn and debug Python in the browser without local installations.

### Technical Details - **Bridging Sync WASI to Async VS Code**: VS Code extension APIs are strictly asynchronous and run in an extension host Web Worker (or desktop process) to keep editor UI interactions unblocked. However, WASI APIs are synchronous. To prevent blocking the extension host, Wasm execution runs in a dedicated Wasm Web Worker. When a synchronous WASI call (e.g., `fd_read` or `fd_write`) occurs, the Wasm worker copies data into a `SharedArrayBuffer`, signals via `Atomics.wait`, and yields execution. The extension host worker receives a message, fulfills the operation asynchronously against the VS Code API, writes results back, and wakes the Wasm worker using `Atomics.notify`. - **Cross-Origin Isolation**: Using `SharedArrayBuffer` and `Atomics` requires Cross-Origin Isolation in browsers. Because enabling this restricts any external resource not configured with matching headers (which initially broke even GitHub OAuth avatars and icons), the capability was initially restricted to VS Code Insiders while coordinating with partners. - **File System Semantic Discrepancies**: VS Code file systems use URIs without inherent POSIX semantics (e.g., lacking inodes, file handles, or POSIX-compliant file deletion rules where open files can be unlinked). The team implemented a POSIX layer atop VS Code file systems, mounting workspaces, interpreter files, and core utilities into virtual mount paths. - **Threading and Debugging Constraints**: Using official CPython builds (at tier-3 Wasm support), execution remains single-threaded. This limits debugger capabilities to Python's built-in `pdb`, preventing breakpoints while code is running and restricting native modules requiring dynamic linking. VS Code implemented WASI thread support mapped to Web Workers, ready for future multi-threaded CPython builds. - **Component Model & WIT**: The team hand-coded the low-level data marshalling between Web Workers for Preview 1, but is building WIT parsers and generators to automatically produce TypeScript glue code for WASI Preview 2 and the Component Model.

### Takeaways Implementing a WASI host inside VS Code enables full serverless language execution, terminals, and educational environments in browser-based editors. Overcoming sync-versus-async impedance mismatches and file system semantics requires deliberate synchronization layers like SharedArrayBuffers. As WASI Preview 2, the Component Model, threading, and socket support mature, the team aims to bring full Language Server Protocol (LSP) and Debug Adapter Protocol (DAP) implementations directly into client-side web environments.