opcode by winfunc: a Tauri 2 desktop front end for Claude Code that you still have to build yourself

It reads the session state Claude Code already keeps in ~/.claude

opcode does not run its own copy of the model tooling. On first launch it detects your ~/.claude directory, and its project browser walks the projects stored in ~/.claude/projects/. Each project expands into its sessions, and each session row shows the first message and a timestamp, so you can tell an old debugging session from a refactor without opening it. From there you either resume a past session with its context or start a new one. Search covers both projects and sessions.

The consequence is a hard dependency. The Claude Code CLI has to be installed, and for a source build the README says `claude` must be available in your PATH. If the CLI is missing or sits outside PATH, there is nothing for the interface to drive. The README also states that the project is independent and is not affiliated with, endorsed by, or sponsored by Anthropic, so it follows whatever the CLI does rather than defining it.

Agents are a system prompt plus permission settings, run as separate processes

The CC Agents area is built around a four step flow: Create Agent, Configure, Execute. You give an agent a name, an icon and a system prompt, pick one of the available Claude models, and set permissions for file read, file write and network access. Agents run in separate processes, which is how the app keeps them from blocking the interface, and every run is recorded in an execution history with logs and performance metrics. The repository also carries a cc_agents/ folder at the top level next to src and src-tauri.

The project description promises secure background agents, but the usage steps only name the permission settings and do not say how they are enforced. Before you point an agent at a repository you care about, open src-tauri and check what actually restricts file and network access. Until you have, treat the toggles as configuration of the agent, not as a sandbox you have verified.

Checkpoints and the branching timeline leave one question unanswered

The timeline feature lets you create a checkpoint at any point in a session, then browse the session history as a branching tree. A checkpoint can be restored in one click, forked into a new branch, or compared against another checkpoint in a diff viewer. That combination is the reason to use a GUI over the plain terminal, since a branching view is awkward to draw in a scrollback buffer.

What the feature list does not state is the scope of a restore. It says you can jump back to a checkpoint and see exactly what changed between checkpoints, but it does not say whether restoring rewinds the conversation only, or also the files in your working tree. That difference decides whether a checkpoint is a bookmark or an undo button. Test it on a throwaway project with committed work before you rely on it, and keep your normal version control as the real safety net.

Cost tracking has no alerts yet, so overspend is something you notice after the fact

The Usage Dashboard sits under the menu and breaks Claude API usage and cost down by model, project and date. It shows token analytics, draws charts of usage trends, and exports the data so you can feed it into accounting or your own analysis. For someone running several agents in the background, a single place that adds up spend is the practical draw.

The usage section lists setting up usage alerts as coming soon. That means the dashboard is a look-back tool today. Nothing in the described feature set stops a runaway agent or warns you when a budget is crossed, so a long unattended agent run can only be judged by opening the dashboard afterwards. If you need a hard ceiling, enforce it on the account side rather than counting on this screen. The same applies to the word real-time in the feature list: it describes how the numbers are shown, not an enforcement mechanism.

MCP servers and CLAUDE.md files get their own screens

The MCP Manager is reached from the menu and follows the path Add Server, then Configure. You can add a Model Context Protocol server through the interface, paste it in as JSON, or import existing definitions from the Claude Desktop configuration. A connection test lets you verify a server answers before a session depends on it. This is useful when one broken server definition would otherwise show up as a confusing failure in the middle of a task.

CLAUDE.md handling is a separate feature. A project scanner finds every CLAUDE.md file under your projects, and a built-in editor opens one with a live markdown preview and syntax highlighting. The practical value is cross-project cleanup: you can see which projects carry instructions and edit them without hunting through directories. Neither screen replaces the CLI's own configuration, because the app reads and writes the same files the CLI uses, so edits made here are visible to a terminal session on the same machine.

The Installation section still says executables will be published soon

Under Installation the README lists only the Claude Code CLI as a prerequisite and then carries the heading Release Executables Will Be Published Soon. GitHub shows two tagged releases, v0.1.0 from 2025-08-15 and v0.2.0 from 2025-08-31, while package.json already reads version 0.2.1 and the last push to main was on 2026-09-18. Check the releases page for what each tag actually attaches before assuming a download exists.

Building from source asks for Windows 10/11, macOS 11+ or Ubuntu 20.04+, 4GB of RAM at minimum with 8GB recommended, and 1GB of free disk. The toolchain is Rust 1.70.0 or later and Bun:

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

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

On Ubuntu or Debian the Tauri system libraries come first:

sudo apt update
sudo apt install -y \
  libwebkit2gtk-4.1-dev \
  libgtk-3-dev \
  libayatana-appindicator3-dev \
  librsvg2-dev \
  patchelf \
  build-essential \
  curl \
  wget \
  file \
  libssl-dev \
  libxdo-dev \
  libsoup-3.0-dev \
  libjavascriptcoregtk-4.1-dev

The package.json scripts include tauri, build:dmg and check, and a family of build:executables scripts that call scripts/fetch-and-build.js with --version=1.0.41. A shell.nix and a NixOS oriented justfile are in the tree as well. The license is AGPL-3.0, which matters if you plan to embed or redistribute modified builds.

Web server mode serves the app to a phone, and the recipes only take a port

Besides the desktop window, the justfile defines a web mode meant for phone access. It builds the frontend and then runs a second Rust binary called opcode-web:

web: build-frontend
    cd src-tauri && cargo run --bin opcode-web

A variant lets you choose the port:

web-port PORT: build-frontend
    cd src-tauri && cargo run --bin opcode-web -- --port {{PORT}}

The ip recipe prints your PC's addresses and reminds you to use http://YOUR_IP:8080 on the phone, and falls back to the message Could not detect IP when detection fails. A web_server.design.md file at the top of the repository holds the design notes for this mode.

The recipes pass a port and nothing else, so there is no visible authentication or access option in them. Anyone who can reach that port on your network reaches a tool that can start Claude Code sessions on your machine. Keep it on a trusted network, and read the opcode-web source in src-tauri before exposing it any further.

Editorial conclusion

Use opcode if you already live in the Claude Code CLI, have a Rust and Bun toolchain, and want session browsing, agent presets, checkpoints and cost charts in one window. Skip it if you need a downloadable installer today, and read the agent permission code in src-tauri before trusting the secure background agents wording.

Frequently asked questions

Official sources

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