CLI-Manager: a Tauri desktop workbench for Claude Code, Codex and SSH terminals

The problem CLI-Manager targets: AI CLIs that block on a prompt nobody sees

The README opens with a list of pain points rather than a feature list, and the first one is the most concrete: when Claude or Codex runs a task, the user has to watch the terminal, and a missed permission request stalls the run. The second is that Claude history has no diff view, so reviewing what a session actually changed means reconstructing it by hand. The third is cost visibility: no monthly token total, no per-project breakdown. Two more follow, both about repetition, namely retyping the same commands while switching between project terminals, and editing environment variables by hand to point different projects at different Claude backends.

That list defines the audience narrowly. This is not a general terminal emulator for people who occasionally open a shell. It is for developers who run several AI CLI agents in parallel across several repositories and want the agent's state, its cost and its file changes surfaced outside the terminal buffer. A single-project user who runs one agent at a time gets little from the workspace model, because the multi-project tree, the per-project provider override and the worktree isolation are all answers to problems that only appear at scale.

How the pieces fit: Tauri shell, React front end, Rust sidecar and a signed SSH agent

The stack is visible in the repository layout. The front end is TypeScript and React, built with Vite, and the desktop shell is Tauri, so the application is a Rust binary hosting a web view rather than an Electron bundle. The repository separates concerns into `src/` for the front end, `src-tauri/` for the Tauri host, `crates/` for shared Rust code and `apps/` for additional packages, with `apps/web` registered as an npm workspace in package.json. A separate `apps/server` crate exists and has its own check, test and run scripts, which suggests the browser-facing parts are not welded to the desktop binary.

The integration mechanism for Claude Code and Codex is hooks. The README describes OSC 133 shell integration for command boundaries and a SessionStart hook that binds a terminal to a Claude session ID, which is how the UI can attach token counts and status to the right tab. Status is reported per tab as running, waiting for approval, complete or failed. For remote work, the app installs a signed `cli-manager-ssh-agent` on the host, and the README states that only sessions where hooks are verified reuse a single protocol 1.1 agent bridge per host, with handshake timeouts, heartbeats, reconnect throttling and separate spool files for streaming in each direction. That is a deliberate design: one multiplexed connection per host instead of one per terminal, with backpressure handled by spooling rather than by dropping events.

History is the other half. Eleven sources are parsed into a unified view, but the capability matrix in the README is honest about the split. Claude Code and Codex CLI get full marks across browse, search, statistics, raw data, diff, resume, edit and delete, and two-way session conversion. The other nine sources, including Gemini CLI, GitHub Copilot CLI, Cursor and Cline, are read-only across the board. OpenCode is the exception in one column: its raw data lives in a database rather than in standalone session files, and it supports resume but not diff or conversion.

Installing CLI-Manager and running a first Claude Code session

The README points to the project homepage at cli-manager.github.io for distribution, and the repository ships a `packaging/` directory alongside the Tauri build configuration, which is where desktop installers are produced. There is no package-manager install line documented, so treat the homepage as the download entry point.

For contributors building from source, the root package.json defines the scripts. The development server is launched through a wrapper script rather than through Vite directly, and the Tauri CLI is likewise wrapped:

npm install
npm run dev

`npm run dev` runs `node ./scripts/dev-server.mjs`. The Tauri side has its own entry point, `npm run tauri`, which runs `node ./scripts/tauri-cli.mjs`. A local build uses a dedicated config file:

npm run tauri:build:local

That command resolves to `node ./scripts/tauri-cli.mjs build --config src-tauri/tauri.local.conf.json`. The README states that Windows and macOS are fully tested while Linux is experimental and open to feedback, so a Linux build is the case where you should expect to file issues rather than to be productive on day one.

Once the app is open, the workflow the README describes is: add a project, open a terminal in it, and start Claude Code or Codex as you normally would. The SessionStart hook binds that terminal to a session, after which the tab shows live token composition (input, output, cache creation, cache read), an estimated cost, the tools and MCP extensions the agent called, and the current Git branch. The command palette on `Ctrl+P` is the documented way to launch a project or run a saved command without retyping it.

Per-project provider switching writes into .claude/settings.json

The cc-switch integration is the feature with the clearest mechanical description. CLI-Manager reads the cc-switch database in read-only mode and groups entries by app type. From the project tree, a right-click offers a provider switch, and the README states that the selection is written into the project's `.claude/settings.json`. Projects that override the global default get a badge in the tree so the override is visible at a glance.

The intended pattern is one backend per project: official endpoints for one repository, a relay for another, a self-hosted backend for a third. The value here is not the switching itself, which you could script, but that the override lives in the project rather than in your shell environment, so it survives a new terminal and is visible to anyone reading the repository. Note the boundary the README draws: SSH projects never scan or switch remote providers. If your work happens on a remote host, this feature does not follow you there.

The same read-only discipline applies to credentials. Passwords go to the operating system credential manager, and the README states that sync and export never carry passwords, credentials or private key paths. The cc-connect mobile bridge follows the same rule: Bot Token, App ID and App Secret are stored in the Windows credential manager rather than in the generated configuration files.

Where CLI-Manager stops: remote history, non-Claude sources and the Linux build

The README is unusually direct about the gaps, and they are worth reading before the feature list. Over SSH, Claude Code and Codex hook status work, but remote history and analytics, file and Git panels, worktree management, external terminals and remote resource monitoring are all listed as not yet open. So the SSH story is: you get a terminal, hook-driven status and a managed agent, and you do not get the history and analysis layer that makes the local experience distinctive. If your repositories live on a build server, you are getting roughly half the product.

The second gap is the source matrix. Nine of the eleven supported history sources are read-only. If you use Gemini CLI or Cursor as your primary agent, CLI-Manager can show you those sessions, and that is the end of it: no diff, no resume, no editing, no conversion. The deep features are Claude Code and Codex features that happen to display other tools' history.

The third is platform. Linux is described as experimental support with feedback welcome, which in practice means the maintainers have not validated it to the same degree. The fourth is the mobile bridge: cc-connect runs on a Windows desktop host, and the first version hosts one project and one messaging platform at a time, with Telegram and Feishu as the supported platforms. That is a single-user, single-project remote access path, not a team feature.

How CLI-Manager differs from tmux plus a shell, and from agent-specific TUI tools

The obvious alternative is what most people already do: tmux or a terminal with split panes, plus each agent's own CLI. That combination is lighter, works over any SSH connection without installing a signed agent on the remote host, and has no opinion about your providers. What it does not do is bind an agent session to a pane so that token counts, cost and approval state appear next to the terminal. In tmux, a Claude run waiting for permission looks identical to a Claude run that is thinking. CLI-Manager's OSC 133 and SessionStart hook integration exists specifically to remove that ambiguity.

A second alternative is the agent vendor's own interface. Claude Code and Codex both ship their own ways to inspect and resume sessions, and those stay current with the agent by definition. CLI-Manager's advantage is aggregation: one view across sources, a prompt library extracted from history, diffs that link back to the message that triggered them, and conversion between Claude and Codex session formats. The trade-off is that CLI-Manager is a third party parsing formats it does not control, so a change in how an agent stores sessions is a change CLI-Manager has to chase. The release history reflects that cadence: three releases within six days in August 2026, including a dedicated SSH agent release, which suggests the parsing layer needs frequent attention.

A third alternative, for people who only need remote persistence, is a plain SSH session with the agent's own resume flag. That costs nothing to install and survives disconnection through the remote shell. CLI-Manager's persistent background tasks and daemon recovery solve the same problem locally, but they require the app to be running and, on remote hosts, the agent to be installed and hook-verified.

Licence, maintenance and what an upgrade actually costs you

CLI-Manager is licensed AGPL-3.0-or-later, and the repository carries a separate `COMMERCIAL-LICENSE.md` file alongside the `LICENSE` and `NOTICE` files. That pairing is a common arrangement for dual-licensed projects, and it means the network-copyleft terms of the AGPL apply by default while a commercial path exists separately. Whether your use triggers the AGPL obligations is a question for your own counsel; the relevant fact here is that the licence is not permissive, and the presence of a commercial licence file tells you the maintainers have thought about commercial users.

Maintenance looks current. The last push was on 2026-08-21, and the most recent release, `ssh-agent-v0.1.10`, landed the same day, with `V1.3.7` and `V1.3.6` in the days before. The repository is not archived. The version in package.json is 1.4.0 while the latest tagged release is V1.3.7, so the working tree is ahead of the last release tag.

The upgrade cost is not in the installer. It is in the integrations. The SSH agent is installed per host and the README describes an explicit install or upgrade step for the signed `cli-manager-ssh-agent`, with a preview of hook changes before anything is written and a promise that only CLI-Manager's own entries are installed or removed. The cc-connect bridge validates the version and SHA-256 of the supported program before generating an isolated configuration and managing the process. Both are places where an upgrade can require action on machines you are not sitting in front of. Budget for that, and read the hook preview rather than clicking through it.

Editorial conclusion

Adopt CLI-Manager if you already run Claude Code or Codex across several projects and want hook notifications, per-session token accounting and one place to read history. Skip it if your work is Gemini CLI, Copilot CLI, Cursor or Cline, because those sources are read-only with no diff, resume or conversion, or if you need remote history and file panels over SSH, which the README lists as not yet open. Before committing, verify two things: that your platform is Windows or macOS rather than the experimental Linux build, and whether the AGPL-3.0-or-later licence plus the separate COMMERCIAL-LICENSE.md file covers how you intend to distribute anything built on top of it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes