I Put the Full VS Code Workbench Inside a Tauri App. It Actually Works.

But is it a good idea?

We’ve all heard the complaints about electron. Most of the time, if you’re doing electron, you can do it right, and it works well. But I wanted to know if you could take the entire VS Code application, not the editor widget but the whole thing, and run it inside a Tauri window backed by Rust instead of Electron.

Not a Monaco text box with syntax highlighting. The actual workbench. File explorer, extensions marketplace, integrated terminal, command palette, keybindings, themes, IntelliSense. All of it. This isn’t “yet another fork” of vscode either. This is an implementation of monaco plus the vscode service APIs to work with open source alternatives through a Rust IPC.

How would it perform? What are the limitations? Is this even a good idea?

So I built it. It’s called Blink. Right now it’s a proof of concept. The code is not good. I’d actually say it’s bad. But hear me out for a sec. The core question is answered. Yes, you can do this. And it was a wilder ride getting here than I expected.

What’s Actually Working

Blink is a Tauri 2 desktop app running the full VS Code workbench through monaco-vscode-api. When you open it you’re not looking at something “inspired by VS Code.” You’re looking at VS Code’s real layout engine, real service architecture, and real extension system running inside a native Rust window.

Here’s what works today.

The full editor surface. Syntax highlighting, IntelliSense (sorta, need to implement some more lsps), go-to-definition, multi-cursor. This is the workbench, not a Monaco widget.

Extensions marketplace. You can browse and install extensions from Open VSX. Python, ESLint, Prettier, GitLens. They install. They activate. They work (sorta, super buggy).

Integrated terminal. A real shell running through Tauri’s native PTY support. You type ls and it runs ls. Actual process spawning through Rust. No WebSocket proxy. No Docker container. The one fun bug here. It seems to activate before the Rust IPC connection is ready? So you need to switch away from the terminal and then back when you first start. But other than that massive weird glaring issue… It works?

AI chat panel. Pluggable to any API key provider. Anthropic, OpenAI, or any OpenAI-compatible endpoint like Ollama. Bring your own key and go. This needs a ton of work, but it’s essentially where I would want to go with this next.

Native file system. Tauri’s Rust backend handles all file I/O. The file explorer reads your actual disk through Rust commands. No Node.js file system shims anywhere.

What you don’t get yet. Git integration needs a backend. The SCM panel renders but it’s not connected. The debugger UI is there but has no DAP router. The test explorer exists but doesn’t run tests. These VS Code service overrides render their UI just fine but they need Rust-side implementations to actually do anything.

The Thing Most People Get Wrong

When people hear “Monaco in Tauri” they think of the Monaco Editor. That’s the text editing component extracted from VS Code. It gives you a text box with syntax highlighting. That’s it. No file explorer. No extensions. No terminal. No command palette. No settings UI. No activity bar.

monaco-vscode-api is a completely different animal. It’s a project by CodinGame that exposes the full VS Code workbench as a set of configurable services. You initialize it with around 40 service overrides and you get the complete VS Code UI running in a browser context.

You import overrides for files, extensions, the extension gallery, the workbench layout, terminal, SCM, debug, testing, chat, search, themes, keybindings, and about 30 others. Each one gives you a piece of the VS Code puzzle. Wire them all together and you have a working IDE.

The catch is that these services expect certain backends to exist. VS Code’s file service expects a file system. Its extension service expects a way to download, extract, and activate VSIX packages. Its terminal service expects a PTY. In Electron, Node.js provides all of this. In Blink, Tauri’s Rust backend has to step up.

Bridging VS Code to Rust

This is where the real engineering challenge lives. Every VS Code service that touches the outside world needs a Tauri implementation.

For the file system, a TauriFileSystemProvider implements VS Code’s file system interface and routes every readFile, writeFile, stat, readdir, mkdir, delete, and rename call through Tauri’s file system plugin down to Rust and then to the OS.

For extensions, when you click “Install” Blink downloads the VSIX from Open VSX, extracts it via Tauri commands, registers it with a local extension server, and fires VS Code’s event system to update the UI. The extension service override file that patches VS Code’s extension management for Tauri compatibility is around 3,650 lines. It’s the gnarliest file in the project. And it works.

For the terminal, Tauri’s shell plugin provides native PTY access. The terminal service override connects VS Code’s terminal UI to actual shell processes spawned through Rust.

The extension host is the most interesting piece architecturally. About 60% of VS Code extensions (themes, grammars, snippets, icon themes) run safely in a Web Worker. The other 40% (debuggers, linters, language servers) need Node.js. Blink uses a dual-host setup. A web worker extension host handles the safe stuff. A Node.js sidecar process communicating via stdin/stdout JSON-RPC handles the rest.

Why Tauri

I’ll keep this short because the Tauri vs Electron debate has been done to death. But there are a few points that matter specifically for an IDE. I will mostly say that this was out of my own curiosity mostly, and I could easily see someone picking one tech over the other for any myriad of reasons (consistency with electron, efficiency with tauri, etc).

Electron bundles Chromium. For an application that’s already running a massive JavaScript application (the entire VS Code workbench), adding Chromium’s overhead on top is redundant. Tauri uses the system’s native webview on macOS so you’re not paying for two browser engines.

Tauri commands are Rust functions. File I/O, process management, PTY handling. These are things Rust is exceptionally good at. The extension installation pipeline downloads archives, extracts them, scans directories, and manages metadata all through Rust’s tokio async runtime. It’s fast.

Binary size. The production Blink .app bundle is dramatically smaller than an equivalent Electron app. The VS Code JavaScript bundle is still large (around 10-20 MB unminified, because it IS the VS Code platform) but the native shell around it is tiny.

The Import That Has to Be First or Everything Dies

One detail I want to call out because it cost me real time.

The @codingame/monaco-vscode-* packages check process.env at import time. In Electron, process exists globally because Node.js is right there. In Tauri, it doesn’t. If any monaco-vscode package loads before you’ve injected a synthetic process object into the global scope, the entire application crashes silently.

The fix is a module called workerSetupEntry that does nothing except set window.process = { env: {} }. It must be the very first import in your application entry point. The first line. Move it down by even one import and you’ll get cryptic runtime errors that have nothing obvious to do with the actual problem.

This is representative of the kind of thing you hit when running VS Code’s internals outside of Electron. The code was written assuming Electron’s environment. Every assumption is a potential landmine. I stepped on a lot of them.

Where This Actually Stands

It’s a proof of concept. It proves that the full VS Code workbench can run inside a Tauri shell with a Rust backend handling the native integrations. The stack is React 19 and Vite 6 on the frontend with the full VS Code workbench running on top via monaco-vscode-api, all inside Tauri 2.

It is not production software. Not yet. The codebase has rough edges. There’s technical debt to pay down. The AI features have their infrastructure registered but need more work. The extension compatibility story for Node.js-dependent extensions needs the sidecar architecture to mature.

But the core thesis is validated. You can have VS Code’s entire feature surface, not an approximation but the real thing, running in a lightweight native desktop app backed by Rust. Extensions install and work. The terminal runs real processes. Files open from your actual file system. Command palette, keybindings, themes, settings. They all function because they’re running the real VS Code services.

What’s Next

The PoC answers the “can you do this” question. The next phase is about what becomes possible when your IDE’s backend is Rust instead of Node.js.

The AI chat panel is already integrated as a VS Code chat agent. The bring-your-own-key approach means you can point it at Claude, GPT-4o, or a local Ollama instance. The slash command system (/plan, /agent, /compose, /apply, /run) is the scaffolding for agentic coding workflows where the AI can read files, propose changes, and execute commands. All routed through Tauri’s Rust backend.

VS Code’s SCM panel renders in Blink today but it’s disconnected. Plugging in git2-rs (libgit2 Rust bindings) would give you native Git operations without shelling out to the git CLI. The Debug Adapter Protocol router is a natural fit for Rust’s async runtime. Custom editors for docx, xlsx, and pptx files using Rust-native libraries are on the roadmap with the editor resolver infrastructure already in place.

There’s a lot left to build. But the hard part, proving that Tauri can actually run the full VS Code platform, is done.

Try It

Code is on GitHub. github.com/bmarti44/blink

You’ll need Node.js 18+, Rust (stable), and Xcode Command Line Tools on macOS. First cargo run compiles around 300 Rust crates and takes about 5 minutes. After that incremental builds are fast.

git clone https://github.com/bmarti44/blink.git
cd blink
npm install
npm run tauri:dev

If you’ve ever wondered what VS Code would look like without Electron, take a look. PRs welcome. If you made it this far, and you want to see more, let me know and I’ll go full steam ahead. If you want to help, also let me know! I think this is super cool, and if you do too, let’s tackle this thing together.