# SideX: a Tauri rebuild of the VS Code workbench, early and incomplete

> SideX keeps Visual Studio Code's TypeScript workbench and Monaco editor but swaps the bundled Chromium for Tauri's Rust backend and the OS webview. Core editing, terminal and Git work; the extension host and debugger do not yet.

**Sidenai/sidex** — VS Code rebuilt on Tauri. Same architecture, 96% smaller. Early release.

- Repository: https://github.com/Sidenai/sidex
- Website: https://discord.gg/8CUCnEAC4J
- Stars: 3,005 · Forks: 246
- Language: TypeScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/sidenai-sidex

## What SideX actually solves, and for whom

Visual Studio Code ships an entire Chromium build inside the application. SideX's README makes a specific claim about where that cost sits: memory use comes almost entirely from the bundled browser, not from the editor logic. Tauri replaces that browser with the webview the operating system already provides, WKWebView on macOS and WebView2 on Windows, which is shared with other applications on the machine.

The repository image compares 16.4 MB for SideX against 797.8 MB for Visual Studio Code, and the README sets a target of under 200 MB at idle on macOS. Those are the project's own figures, not an independent measurement, and the README is explicit that real benchmarks will be published once the app is stable enough for them to be meaningful. Treat the comparison as a design goal rather than a verified result.

The audience is narrow and identifiable. This is for engineers who want to read, fork or contribute to a code editor built on Tauri, and for people who care about RSS more than they care about a finished product. It is not yet for a team that needs a debugger on Monday morning. The README states plainly that core editing and the terminal are solid, while the extension host and debugger are still in progress.

## The workbench stays TypeScript; the host moves to Rust

SideX is a port, not a rewrite of the UI. The same TypeScript workbench runs on top of Monaco, and the frontend is built with Vite. What changes is the layer beneath it: a Rust workspace of roughly twenty crates handles the parts that touch the machine.

The Cargo workspace lists the split by responsibility rather than by screen. crates/sidex-text handles the text buffer, sidex-syntax and sidex-textmate cover parsing, sidex-terminal wraps a PTY, sidex-git wraps Git, sidex-lsp wraps language servers, sidex-dap is the debug adapter protocol crate, and sidex-agent is the Rust side of the AI agent. A separate sidex-extension-sdk crate sits inside the workspace, and extensions-rust is excluded from it, which suggests a second extension path that is not part of the main build.

Persistence is SQLite through rusqlite with the bundled and backup features enabled, which is why the README lists SQLite storage and document management under what works. File watching uses the notify crate with macOS FSEvents enabled. The workspace denies unsafe code at the lint level, a deliberate constraint that shapes how the remaining crates can be written.

One detail worth flagging: the Cargo workspace declares version 0.2.0 while package.json declares 0.1.3 and the most recent release is v0.1.2. The Rust and JavaScript sides are versioned separately, so the release tag is not a reliable indicator of what the crates contain.

## Installing SideX and running a first session

The README gives two paths. Development mode clones the repository, installs dependencies and launches Tauri with hot reload. The npm script wraps the Tauri CLI with a local bin directory prepended to PATH.

```bash
git clone https://github.com/Sidenai/sidex.git
cd sidex
npm install
npm run tauri dev
```

Running npm run tauri dev starts the app through the Tauri dev server. The README notes that the agent server is spawned as a child process when the app launches, so if the chat panel reports itself as disconnected, the binary is missing rather than the app being broken.

For a release build, the README gives npx tauri build, which runs the frontend build first. The build script raises Vite's Node heap limit to 12 GB internally, so no NODE_OPTIONS setting is needed on a normal machine.

```bash
npm install
npx tauri build
```

The AI agent needs a separate Go binary. The README specifies Go 1.26 or later, and the build uses the fts5 tag, which enables SQLite full-text search in the server.

```bash
cd sidexai/sidex-server
go build -tags fts5 -o sidex-server ./cmd/server
```

After the binary exists at that path, the app finds it automatically when running from a source checkout. Configuration is optional. The .env.example file lists provider keys such as ANTHROPIC_API_KEY and OPENAI_API_KEY, but states that anything already exported in your shell is picked up automatically, and that keys entered in Settings, Models take precedence over the environment.

## The agent server is a local process, and that is the security model

SideX's coding agent is not a hosted service. On launch the app spawns sidex-server, a Go program, as a child process bound to 127.0.0.1 on a random free port, supervised from src-tauri/src/server.rs and stopped when the app exits. There is no sign-in, no identity provider and no SideX account in the request path.

Credentials are resolved in a fixed order, first match wins, according to src-tauri/src/commands/providers.rs: a key entered in Settings, Models; then an environment variable already present in your shell; then an existing Claude Code or Codex CLI login, opt-in per provider; then a keyless local model server on loopback. Ollama, LM Studio, llama.cpp and vLLM are detected automatically on their default loopback ports, listed in .env.example as 11434, 1234, 8080 and 8000.

Anthropic is called through its native Messages API at /v1/messages. Every other provider, including local servers, is treated as OpenAI-compatible and called at /chat/completions. That is a real constraint: a provider with a non-OpenAI shape needs a native path that does not exist yet.

The security boundary is the loopback binding, and the README treats it as deliberate. SIDEX_BIND_ADDR can widen the address, but the server refuses to start on a non-loopback address unless SIDEX_ALLOW_UNAUTHENTICATED=1 is set. The README's own warning is the important part: an open port on this server means arbitrary code execution for anyone who can reach it. Credentials reach the server only through its process environment, are set fresh on each start or restart, and are never written to a config file or sent to the webview.

The CLI-login option deserves a closer look than the README gives it. SideX talks to Anthropic and ChatGPT using the same client identity those CLIs use, so a connected login can run models, and usage counts against that subscription. The README points at a billed API key as the path that does not depend on a CLI login or the provider's consumer terms. That is a fair warning, and it is the kind of detail that decides whether this feature is usable in a workplace.

## Where SideX falls short today

The extension host is the largest gap. Extensions can be installed from Open VSX, and the README lists that under what works, but the extension host itself is listed as in progress. Installing an extension and running it are different things, and the README does not describe which extension categories currently execute. Anyone whose workflow depends on a language server delivered as an extension should verify this before switching.

The debugger is the second gap. A sidex-dap crate exists in the workspace, which indicates the debug adapter protocol is being built, but the README places the debugger in the same in-progress bucket. For a project that describes itself as an IDE, that is a significant omission, and it is the reason this is not a drop-in replacement for Visual Studio Code.

The memory claims are platform-specific in a way that is easy to miss. The README states that RAM savings are most tested on macOS, where WKWebView is shared with Safari. On Windows it says the picture is more nuanced, that WebView2 memory can look higher depending on how it is measured, and links to an open issue in the Tauri repository. If you are evaluating SideX for Windows, the headline comparison does not transfer cleanly.

Finally, the project is early by its own description. The latest release is v0.1.2, and the README says benchmarks will come once the app is stable enough for them to be meaningful. That is an honest position, and it also means there is no measured evidence yet for the claim the project leads with.

## How SideX differs from running VS Code itself

The obvious alternative is Visual Studio Code, and the difference is architectural rather than feature-level. VS Code ships its own Chromium, so the runtime is identical on every platform and the team controls the rendering engine version. SideX gives that up. It inherits whichever webview the operating system provides, which is why the binary is small and why behavior can differ between macOS and Windows.

The trade is control for size. A pinned Chromium means a bug reproduces the same way everywhere and a fix ships on the project's schedule. A system webview means the rendering engine changes when the OS vendor changes it, and the memory profile depends on what else is using that webview. The README's own Windows caveat is exactly this trade showing up in practice.

The extension ecosystem is the second difference. VS Code's marketplace and its extension host are the reason most people stay. SideX installs from Open VSX and its extension host is unfinished, so the practical overlap between the two is much smaller than the shared Monaco editor suggests.

For a narrower comparison, Tauri itself is the relevant reference point. SideX is one application of the same idea, and the Tauri issue the README links to about WebView2 memory is the general version of the problem, not something specific to this project.

## Licence, maintenance and what an upgrade costs

SideX is MIT licensed, and the Cargo workspace declares MIT for the workspace package as well. That is permissive: you can read the source, fork it, and ship a modified build, provided the licence text travels with it. The README does not discuss trademark or branding, and the repository has no separate contributor licence agreement visible in the top-level entries. None of this is legal advice; if you plan to redistribute a fork, read LICENSE and CONTRIBUTING.md yourself.

The maintenance picture is mixed in a way worth stating precisely. The repository is not archived, and the last push was on 2026-08-26, which is recent. But the release history is thin: v0.1.0 on 2026-04-07 and v0.1.2 on 2026-04-12, with no tagged release since. Package versions disagree across the tree, with package.json at 0.1.3 and the Cargo workspace at 0.2.0. If you build from main, you are building something that is not pinned to a release tag.

The upgrade cost follows from that. There is no documented migration path between versions, and the README does not describe rollback. The agent server is a separate Go binary that you build yourself with the fts5 tag, so an upgrade means rebuilding it alongside the app. The npm scripts give you the check commands to run before and after: npm run rust:check, npm run rust:clippy and npm run lint. The clippy script treats warnings as errors with -D warnings, so a dependency bump that introduces a new lint will fail the build rather than warn.

## Conclusion

Adopt SideX if you want to read or contribute to a Tauri-based workbench and you can live without a debugger and a complete extension host, and if you are willing to build the Go agent server yourself with go build -tags fts5. Do not adopt it as your daily editor yet: the README calls the release early, the architecture document is the only place to check what the crate split actually covers, and the memory target of under 200 MB at idle on macOS is a target, not a published measurement. Verify first that the extension host gap does not break the extensions you rely on, and that your platform is one where WKWebView or WebView2 behaves as the README describes.

## FAQ

### What is SideX?

SideX is a port of the Visual Studio Code workbench that replaces Electron with Tauri, using a Rust backend and the operating system's native webview. It keeps the same TypeScript workbench and Monaco editor. The README describes it as an early release where core editing and the terminal are solid, while the extension host and debugger are still in progress.

### How does SideX work?

The TypeScript frontend runs on Monaco and is built with Vite, while a Rust workspace of crates handles the terminal, Git, language servers, file watching and SQLite storage. On launch the app also spawns its own Go agent server bound to 127.0.0.1 on a random free port, supervised from src-tauri/src/server.rs.

### Is the SideX source on GitHub?

Yes, the repository is Sidenai/sidex on GitHub under the MIT licence. The README gives the clone command as git clone https://github.com/Sidenai/sidex.git followed by npm install and npm run tauri dev.

## Sources

- [License: MIT](https://github.com/Sidenai/sidex/blob/main/LICENSE)
- [Project website](https://discord.gg/8CUCnEAC4J)
- [README](https://github.com/Sidenai/sidex/blob/main/README.md)
- [Releases](https://github.com/Sidenai/sidex/releases)
- [Sidenai/sidex on GitHub](https://github.com/Sidenai/sidex)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sidenai-sidex