Jean: a Tauri desktop shell for running parallel Claude CLI and Codex CLI sessions across git worktrees

The problem Jean addresses: eight CLI agents, one repo, no shared state

Running an AI coding agent from a terminal is easy. Running three of them against the same repository without them stepping on each other is not. Claude CLI, Codex CLI, Cursor CLI, OpenCode, PI, Command Code, Grok and Kimi Code each keep their own session history, their own working directory assumptions and their own notion of what the current branch is. Jean is a native desktop application, built with Tauri v2 and React 19, that puts a single interface over those eight backends and pairs each session with a git worktree.

The intended user is a developer who already has these CLIs installed and authenticated. The README is explicit that Jean does not proxy the models: "Everything runs locally on your machine with your own CLI installations." There is no Jean account, no hosted inference and, per the README, no vendor lock-in. That design choice also means Jean is useless without the underlying CLIs. Install the app on a clean machine with no Claude CLI present and you have a project manager, a diff viewer and a terminal, not an agent.

The opinionated part is the worktree coupling. Jean treats a worktree, not a repository, as the unit of work, and attaches sessions, terminals and diffs to it. That is a real architectural stance, and it is the reason the tool exists at all rather than being a nicer terminal multiplexer.

How the worktree, session and Web Access layers fit together

The repository layout tells most of the story. There are three Rust crates or directories in play: jean-core, src-server and src-tauri, plus a TypeScript frontend under src/. jean-core holds shared logic, src-tauri is the native desktop shell, and src-server is the headless binary called jean-server. The frontend is one codebase serving both, which is why the README can claim that every Jean instance, desktop or headless, can expose the full UI over HTTP and WebSocket.

Data flow is local-first. A session is created against a worktree, the session spawns the chosen CLI backend, and the CLI's output streams back into the UI. The debug panel tracks token usage, and execution modes (Plan, Build, Yolo) govern how much the agent is allowed to do before a human approves a plan. Magic Commands are prompt templates bound to a backend, a model and an effort level, covering things like code review with finding tracking, AI commit messages and merge conflict resolution.

Web Access is the piece worth understanding before you enable it. It is an embedded HTTP plus WebSocket server that serves the same UI, with token authentication on by default. The README recommends Tailscale over raw exposure and warns that binding the Tailscale IP directly is HTTP-only, so browsers treat it as an insecure origin and secure-context APIs such as clipboard access stop working. The suggested pattern is to bind 127.0.0.1 and put `tailscale serve --bg 3456` in front. That is a more careful security posture than most desktop tools of this kind bother to document.

Installing Jean and running a first worktree session

On macOS the README gives a Homebrew path. The tap and cask are both under the coollabsio namespace.

brew tap coollabsio/jean
brew install --cask jean

After the cask installs, the app appears in Applications. There is no separate CLI to configure; Jean expects your agent CLIs to already be on PATH. If you would rather build it yourself, the prerequisites are Node.js and Rust, and on Windows the Visual Studio Installer needs the "Desktop development with C++" workload selected, which brings in the MSVC build tools and the Windows SDK that Rust links against. The build scripts are Bun-driven: `bun run tauri:build` for a full bundle, and `bun run tauri:build:fast` for a DMG-only build with updater artifacts disabled.

For a headless Linux box, the README documents an install script that sets up a release binary plus systemd. It prompts for a bind interface and port when a TTY is available, and defaults to 127.0.0.1:3456 when it is not.

curl -fsSL https://raw.githubusercontent.com/coollabsio/jean/main/scripts/install-jean-server.sh | sudo bash

The headless server is Linux amd64 and arm64 only, needs glibc and OpenSSL 3, and the README suggests Ubuntu 22.04+ or Debian 12+. Once it is running, the process is the Web Access endpoint; there is no desktop window, GTK or WebView involved. From the desktop app, the equivalent path is Settings, then Web Access, where you enable the HTTP server, optionally turn on auto-start, set the port and bind address, and copy the token URL that the app displays.

A first real session looks like this: add a project, let Jean create a worktree for the branch you want, open a session on that worktree, pick a backend and a mode, and start typing. The mode matters more than it looks. Plan mode asks the agent to produce a plan you approve before it edits files; Yolo mode does not.

Where Jean gets in the way

The platform matrix is the first honest limitation. macOS is listed as tested, Windows as not fully tested, and Linux as community tested on Arch Linux with Hyprland and Wayland. If you are on Windows, you are on a path the maintainer has not validated, and the C++ workload requirement in the README is a hint that the native build is the fragile part.

The headless server narrows things further. jean-server is Linux-only, amd64 and arm64, and it wants a modern glibc and OpenSSL 3. Older distributions will not work without upgrading the base system.

The version number is the second limitation. The package manifest reads 0.1.74, and the most recent release listed is v0.1.73 from 2026-08-20. A 0.1.x line means interfaces, config keys and the shape of stored session data can change between releases. If your team pins tooling for reproducibility, Jean is a poor fit today.

The third is the coupling itself. Jean's worktree-per-session model is a strong opinion, and it does not match every workflow. Teams that work on a single long-lived branch, or that use a monorepo where worktrees are expensive to materialise, will find the abstraction fighting them. The README does not document a way to run a session outside the worktree model, and it does not describe rollback behaviour for a worktree that an agent has already modified. Treat an agent's worktree as disposable and you will be fine; treat it as your working copy and you have no documented recovery path beyond the app's own archive and restore features.

Jean compared with Vibe Kanban and a plain terminal

The obvious comparison is Vibe Kanban, which several of the search phrases for this project reference. Both tools exist because running multiple agents in parallel is awkward. The difference is where the coordination lives. Vibe Kanban's model is a board: tasks move through columns and each card maps to an agent run. Jean's model is a project tree: worktrees are the containers, sessions hang off them, and the GitHub and Linear integrations pull issues and pull requests into that same tree so you can check out a PR as a worktree directly.

That makes Jean closer to an IDE with an agent layer than to a task queue. If your mental model is "I have twelve issues and I want twelve agents working them," a kanban-shaped tool fits better. If your mental model is "I have four branches in flight and I want to see what each agent did to each one," Jean's layout is the more natural one. The README also lists multi-agent collaboration and linked projects for cross-project context, which suggests the design assumes several agents inside one project rather than one agent per card.

The other alternative is the terminal plus tmux plus `git worktree add`, which is what most people do before they look for a tool like this. That setup costs nothing and has no version churn. What it does not give you is a diff viewer with unified and side-by-side modes, a file tree with preview, a debug panel with token usage, or the GitHub dashboard with Issues, PRs, Security Alerts and Advisories tabs. Whether those are worth a 0.1.x dependency is the actual decision.

Licence, releases and what upgrades cost you

Jean is Apache-2.0, and the package manifest carries the same identifier. Apache-2.0 is permissive: you can use, modify and redistribute the code, including commercially, provided you keep the licence and notice files and state significant changes. It also includes an explicit patent grant, which matters if you are considering shipping a fork inside a company. The package.json copyright line reads "Copyright © 2025 Andras Bacsai. All rights reserved." alongside the Apache-2.0 licence field; that combination is common in projects that want the licence terms to govern while still naming the author, but it is the kind of thing worth having your own counsel read rather than taking from a review. Nothing here is legal advice.

The release cadence visible in the release history is roughly every two to three weeks: v0.1.71 on 2026-08-04, v0.1.72 on 2026-08-07, v0.1.73 on 2026-08-20. The last push to the default branch was on 2026-09-10, so the repository is not dormant. That cadence is the upgrade cost. Because the app is a desktop binary rather than a service, upgrading means replacing the app, and the README does not document a migration path for stored sessions or worktree metadata between versions. The presence of `tauri:build:fast` with updater artifacts disabled suggests the maintainer builds local test bundles frequently, which is consistent with a project still settling its internals.

One structural note for anyone evaluating the codebase: the repository contains agent-specific directories (.claude/, .cursor/, .commandcode/) and instruction files (AGENTS.md, CLAUDE.md, GEMINI.md) at the top level. Jean is used to build Jean, which is a reasonable signal about the workflow the author actually runs, though it says nothing about stability.

Editorial conclusion

Adopt Jean if you already run Claude CLI, Codex CLI or Cursor CLI from a terminal and are tired of hand-managing worktrees, sessions and PR checkouts; the Homebrew cask and the release binaries make the first run cheap. Do not adopt it if you work primarily on Windows, where the README says support is not fully tested, or if you need a stable 1.0 interface, since the project is at 0.1.x with releases roughly every two to three weeks. Before committing, verify three things on your own machine: that your CLI binaries are found by the app, that Web Access binds 127.0.0.1 with a token you generated, and that the worktree archive and restore flow matches how your team expects branches to be cleaned up.

Frequently asked questions

Official sources

1. coollabsio/jean on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases