winfunc/opcode: a Tauri GUI for Claude Code sessions, agents and MCP servers

The gap opcode fills between the terminal and ~/.claude/projects/

Claude Code is a command-line tool. Everything it keeps on disk lives under ~/.claude, and the README says opcode detects that directory automatically on first launch. Sessions accumulate there as files, and reading them back means either resuming from the terminal or opening JSON by hand. opcode's stated purpose is to put a browser in front of that directory: a visual list of projects, the sessions inside each one, and each session's first message, timestamp and metadata. The audience is narrow and specific. You need the Claude Code CLI installed first, because the README lists it as the only prerequisite and opcode is a front end rather than a replacement. If you have never run the CLI, the app has nothing to show you. The second audience is people who keep several agents with different system prompts and want them stored somewhere other than a shell history. The README describes an agent library where each entry has a name, an icon, a system prompt, a model, and permissions for file read/write and network access. That is a configuration surface, and storing it in a GUI is a real convenience if you switch between agents often.

Tauri 2 front end, Rust back end, and what actually moves between them

The repository layout answers the architecture question without guesswork. There is a src/ directory holding the TypeScript front end, a src-tauri/ directory holding the Rust side, and a package.json whose scripts call both vite and tauri. The stack is Tauri 2 with a React and TypeScript UI: the dependency list includes @tauri-apps/api, @tauri-apps/plugin-dialog, @tauri-apps/plugin-shell, @tauri-apps/plugin-global-shortcut, Radix UI primitives and Tailwind 4. The plugins matter more than the component libraries. plugin-shell is how a desktop app spawns and talks to external processes, and plugin-dialog is how it asks the operating system for file paths. Those two are consistent with the README's claim that agents run in separate processes for non-blocking operations, and with a session browser that reads from a directory outside the app bundle. The justfile shows a second binary: cargo run --bin opcode-web starts a web server mode, and a companion recipe prints the machine's local IP with the note to open http://YOUR_IP:8080 from a phone. So the same Rust core can serve a browser client over the local network, not just a native window. That is a meaningful design decision, and it is also the part of the project with the least documentation. The README's feature list does not mention web server mode at all; it appears only in the justfile and in a file named web_server.design.md at the repository root.

Building opcode from source and getting to a first session

There are no release executables. The installation section of the README says so directly: release executables will be published soon. The documented route is a source build, and the README lists the prerequisites as Rust 1.70.0 or later, Bun, and Git, on Windows 10/11, macOS 11+ or Linux (Ubuntu 20.04+). Install the Rust toolchain first if you do not have it.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then Bun, which the README names as the package manager for the front end.

curl -fsSL https://bun.sh/install | bash

Clone the repository and install dependencies. The package.json declares the project as private and version 0.2.1, with vite as the dev server. The README's build instructions use Bun; the justfile, which is written for NixOS, uses npm install instead, so both package managers appear in the repository and you should pick one and stay with it.

bun install
bun run tauri dev

The tauri script maps to the Tauri CLI, so this compiles the Rust side and starts the front end together. The first build is the slow one because Cargo has to fetch and compile the Tauri dependencies. When the window opens, the README says opcode detects ~/.claude automatically and presents a welcome screen offering CC Agents or Projects. Choose Projects, click one, and you should see its sessions with first messages and timestamps. If the list is empty, the CLI has no sessions under that path yet, which is a CLI problem rather than an app problem. To check both halves of the codebase compile without launching anything, the package.json defines a check script that runs tsc --noEmit and then cargo check inside src-tauri.

Where opcode gets in the way: no binaries, thin docs, and a security section that says little

The most concrete limitation is distribution. A user who wants a desktop app normally downloads one. Here the README's installation section contains a prerequisite and a promise, and nothing else. That means every user needs a Rust toolchain, which is several hundred megabytes of download before the first build even starts, and a build that takes minutes on a cold Cargo cache. For a team evaluating the tool, that is a real cost per machine. The second limitation is documentation depth. The README has a Security section in its table of contents, but the available description does not say what that section contains, so the permission model for agents (the README mentions configuring file read/write and network access) cannot be verified from the feature list alone. Anyone running background agents against a real repository should read that section in the repository before granting anything. Third, the usage dashboard tracks cost and tokens and offers export, but the README marks usage alerts as coming soon, so there is no built-in way to be told when spend crosses a threshold. Fourth, the app is a client of the CLI, so it inherits the CLI's behaviour and its data layout. If the CLI changes where sessions live, the project browser has to follow. Finally, if your work is entirely inside one terminal window and you never resume old sessions, a GUI adds a window to manage for no benefit. The CLI already does the job.

opcode against a terminal multiplexer and a plain editor

The obvious alternative is not another GUI, because there is no second GUI for Claude Code described here. It is the combination people already use: a terminal with tmux or the editor's built-in terminal, plus an editor for CLAUDE.md files. The difference is in what each approach treats as the source of truth. With a terminal, sessions are files you occasionally resume and the agent prompts live wherever you paste them from. With opcode, the app owns a set of views over those same files: a project browser, a session list, an agent library with stored prompts and permissions, a timeline with checkpoints and a diff viewer, and an MCP server registry that can import configurations from Claude Desktop. That last feature is the clearest argument for the GUI, because editing MCP server entries by hand across two applications is exactly the kind of task a form handles better than a text file. The counterargument is weight. tmux starts instantly and works over SSH; opcode needs a compiled Rust binary and a graphical session, unless you use the web server mode from the justfile, which is the one path that gets opcode onto a phone browser.

Licence, maintenance and what an upgrade costs you

opcode is licensed AGPL-3.0, and the package.json repeats that identifier. The AGPL is a strong copyleft licence with a network clause: if you modify the program and let users interact with it over a network, the licence's terms about offering the corresponding source come into play. The justfile's web server mode is precisely the scenario that clause was written for, so anyone planning to run a modified opcode-web for other people should read the licence text rather than assume a desktop app's terms apply unchanged. Nothing here is legal advice, and the repository's LICENSE file is the authority. On maintenance: the repository is not archived and the last push was on 2026-09-18, three days before this writing, so development is current. The release history is short, v0.1.0 on 2025-08-15 and v0.2.0 on 2025-08-31, while package.json already reads 0.2.1, which suggests changes land between tagged releases. Upgrade cost is dominated by the build. There is no auto-update mechanism described, so moving to a newer commit means pulling the repository and rebuilding both the front end and the Rust crate. The justfile's rebuild target does exactly that: clean, build, run. Expect the same cold-compile wait you paid the first time, minus whatever Cargo has cached.

Editorial conclusion

opcode suits engineers already running the Claude Code CLI who want a visual layer over ~/.claude/projects/, a place to keep agent prompts, and a UI for MCP server entries. It is not for anyone who has not installed the CLI, and not for anyone who needs a signed installer today, because the README states release executables will be published soon and lists no download. Before adopting it, clone the repository, run the bun install and tauri dev steps, and confirm the app detects your ~/.claude directory and that the AGPL-3.0 licence is acceptable for how you intend to use it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. winfunc/opcode on GitHub