Jean: A Tauri Desktop Shell for Running Eight Coding Agents Side by Side
A dev environment for AI agents.
At a glance
- What is it?
- Jean is an Apache-2.0 desktop app that wraps Claude CLI, Codex CLI, Cursor CLI, OpenCode, PI, Command Code, Grok and Kimi Code in one interface, with git worktree automation and a headless server mode. It assumes you already have those CLIs installed and that you want worktrees as your unit of parallel work.
- Who is it for?
- Adopt Jean if you already run several agent CLIs from a terminal and want worktree creation, session history and GitHub or Linear context in one window, and if you are on macOS, which the README lists as the only tested platform. Skip it if you need a Windows or Linux desktop guarantee, or if you want the agent runtime itself to be managed for you, since Jean drives your existing CLI installations rather than shipping a model.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Jean solves is context switching between agent CLIs and branches
Running one coding agent in one terminal is manageable. Running four across three repositories is not. You lose track of which session belongs to which branch, which worktree still has uncommitted work, and which PR the agent was investigating. Jean's answer is to make the git worktree, not the terminal tab, the container for a unit of agent work. The README describes project and worktree management as the first feature: multi-project support, linked projects for cross-project context, and worktree automation covering create, archive, restore and delete. Sessions then attach to a worktree rather than to a folder path. That is the organising idea, and everything else in the feature list hangs off it. The intended user is a developer who already has at least one of the eight supported CLIs installed and who works on more than one branch at a time. The README is explicit that nothing is hosted: "Everything runs locally on your machine with your own CLI installations."
Architecture: Tauri v2 shell, React frontend, Rust backend, your CLIs underneath
The stack line in the README names Tauri v2, React 19, Rust, TypeScript, Tailwind CSS v4, shadcn/ui v4, Zustand v5, TanStack Query, Pierre Diffs and xterm.js. Tauri means a native window with a Rust process behind it, not Electron, so the desktop binary is the same process that can host the HTTP and WebSocket server for Web Access. The terminal is xterm.js, the diff viewer is Pierre Diffs, and client state is Zustand with TanStack Query. Jean does not implement a model client. It invokes the CLI you installed, which is why the README frames the project as having "No vendor lock-in" and why eight backends can be listed without any of them being bundled. The consequence is that authentication, rate limits and model availability are whatever your CLI already has. Jean adds the layer above: session records, execution modes, saved contexts, and integrations with GitHub and Linear. The README describes execution modes as Plan, Build and Yolo with plan approval flows, and mentions per-mode overrides for model and thinking or effort level. That per-mode override is the detail worth noting, because it lets you run planning against a stronger model and execution against a cheaper one without editing anything outside the app.
Installing Jean: Homebrew on macOS, or a systemd install script for the headless server
The README gives one packaged install path and one source path. On macOS the cask is:
brew tap coollabsio/jean brew install --cask jean
Everything else comes from the GitHub Releases page or jean.build. Building from source requires Node.js and Rust, and on Windows the README calls out the Visual Studio Installer workload "Desktop development with C++", which supplies MSVC build tools and the Windows SDK that Rust links against. The headless server is a separate artifact. The README states it is Linux amd64 and arm64 only, needs glibc and OpenSSL 3, and recommends Ubuntu 22.04+ or Debian 12+. Installation is a piped script:
curl -fsSL https://raw.githubusercontent.com/coollabsio/jean/main/scripts/install-jean-server.sh | sudo bash
The README notes the script prompts for bind interface and port when a TTY is available and defaults to 127.0.0.1:3456 otherwise. For the desktop app, Web Access is configured under Settings, Web Access: enable the HTTP server, optionally enable auto-start, then set port and bind address. The README lists 127.0.0.1 for local only, a LAN IP, 0.0.0.0, or a Tailscale IP as the choices. The URL the app shows includes a token query parameter.
Web Access is the most opinionated part, and the README treats it as a security boundary
The default port is 3456. Token authentication is on by default, and the README says to keep it enabled for any non-localhost bind. The recommended remote pattern is not to expose the port. It is to run jean-server --host 127.0.0.1 and put tailscale serve --bg 3456 in front, so the browser sees real HTTPS and secure-context APIs such as clipboard work. The README states directly that binding the Tailscale IP with --host tailscale is HTTP-only and that browsers will treat it as an insecure origin. For token generation it suggests openssl rand -base64 32. It also warns against binding 0.0.0.0 on untrusted networks unless TLS is terminated and reachability is restricted. This is more careful than most self-hosted tools get, and the practical effect is that the headless mode is aimed at a private mesh VPN or an SSH tunnel rather than a public VPS. The desktop app can also act as a client: the title bar server icon has an Add remote option, so you keep the native shell and point it at a remote Jean instance.
Where Jean gets in the way: platform coverage, CLI drift and session state
Platform support is the first limitation and it comes straight from the README. macOS is listed as tested. Windows is listed as not fully tested. Linux is community tested, with the single example being Arch Linux on Hyprland and Wayland. If your team is on Windows, the README is telling you that the desktop app is not a supported target yet, and the headless server does not cover you either because it is Linux only. The second limitation is that Jean inherits every failure mode of the CLIs it drives. The README does not describe how it handles a CLI that changes its flags or output format, and since it is at v0.1.73 with releases roughly two to three weeks apart through August 2026, that surface is still moving. Third, session state is local. The README describes archiving with retention settings, recovery, and saved contexts with AI summarization, which implies a store on disk, but it says nothing about syncing that store between a desktop instance and a headless server. If you run both, assume two separate session histories until you verify otherwise. Finally, the app is opinionated by its own description, and worktree-per-session is a real structural commitment: if your workflow is one long-lived branch with uncommitted work in it, the worktree model adds steps rather than removing them.
Compared with running the CLIs directly, or with a terminal multiplexer
The honest alternative is not another GUI. It is tmux plus your CLI plus git worktree add, which is what most people doing parallel agent work already use. That combination gives you persistence across SSH drops, scriptability, and no dependency on a Tauri build. What it does not give you is a session record with a recap, a diff viewer with unified and side-by-side modes, a command palette, or the GitHub and Linear panels the README describes, including checkout PRs as worktrees and auto-archive on PR merge. The difference is statefulness. tmux keeps a process alive; Jean keeps a record of what the session was for. The other alternative is to treat the agent vendor's own interface as sufficient, which works until you are comparing output from Claude CLI and Codex CLI on the same branch, at which point a single window with a shared diff view is the thing you are missing. Jean's bet is that the worktree is the right join key for that comparison. That bet is reasonable, and it is also the reason the app is hard to adopt halfway.
Licence, releases and what upgrades cost you
Jean is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state changes. That is a permissive licence and it is a deliberate fit for a tool that shells out to proprietary CLIs. Note that the licence covers Jean, not the CLIs it drives; those carry their own terms, and the README does not discuss them. On maintenance, the release cadence visible in the material is three releases in about three weeks (v0.1.71 on 2026-08-04, v0.1.72 on 2026-08-07, v0.1.73 on 2026-08-20), with the last push to main on 2026-09-10. A version string still in the 0.1.x range after that many point releases tells you the project has not declared a stable interface. For a desktop tool that reads your local git state, that means reading the release notes before upgrading rather than letting it update silently, and it means testing a worktree archive and restore cycle after each upgrade, since those operations touch directories you care about.
Editorial conclusion
Adopt Jean if you already run several agent CLIs from a terminal and want worktree creation, session history and GitHub or Linear context in one window, and if you are on macOS, which the README lists as the only tested platform. Skip it if you need a Windows or Linux desktop guarantee, or if you want the agent runtime itself to be managed for you, since Jean drives your existing CLI installations rather than shipping a model. Before committing, install one CLI, create a worktree through the app, and confirm that the session survives a restart and that archiving follows your retention setting.
Community notes