CC-Switch CLI: a Rust switchboard for Claude Code, Codex and Gemini CLI profiles

The problem CC-Switch CLI solves for multi-provider CLI users

Anyone who uses Claude Code, Codex or Gemini CLI against more than one endpoint ends up editing the same config files by hand: swapping a base URL, pasting a different key, changing a model name, then reverting all of it when the quota runs out or a relay misbehaves. The README frames the project as a way to manage Claude Code, Codex, Gemini, OpenCode, Hermes, OpenClaw and Pi from one interactive TUI or a scriptable CLI, which is a direct answer to that chore. The target user is a developer who keeps several provider profiles alive at once, for example a direct Anthropic account plus a relay, and wants to move between them without remembering which file holds which key. It is a CLI fork of CC-Switch, so people who liked the upstream desktop tool but live in a terminal are the intended audience. The README also notes that WebDAV sync is fully compatible with the upstream project, which matters if you already have profiles stored there.

How the switchboard works: profiles, a TUI and a scriptable CLI

The architecture visible in the repository is a Rust core wrapped in a Tauri shell. The top-level entries include src-tauri/, which is where the Tauri application code lives, alongside a flake.nix and flake.lock for Nix users, an install.sh script, and a scripts/ directory. The README describes two front ends over the same profile store: an interactive TUI and a scriptable CLI. Profiles are grouped by the tool they configure, and the README's own summary lists Claude Code, Codex, Gemini, OpenCode, Hermes, OpenClaw and Pi as the managed targets. Switching means the tool writes the selected profile's settings into the config file that the corresponding CLI reads, so the next time you launch that CLI it picks up the new endpoint. The README does not document the exact path of each config file per platform, so treat that as something to confirm on your own machine. Sync is the other half: the README states WebDAV sync is fully compatible with the upstream CC-Switch project, which implies profiles can be shared between the two tools rather than living only on one disk.

Installing CC-Switch CLI and running a first profile switch

The repository ships an install.sh at the top level, and the README links to the releases page for versioned builds. The install script is the shortest path on Linux and macOS; the README does not spell out its flags, so run it and read the output rather than assuming options. If you prefer Nix, the presence of flake.nix and flake.lock means the project can be built from the flake, though the README does not walk through the exact flake attribute to use. The README gives no install command line of its own, so the concrete step it does point to is the install.sh file in the repository and the releases page. After installation, launch the tool to see the profile list; the README describes the two entry points as an interactive TUI and a scriptable CLI, and it does not enumerate the subcommand names, so check the help output that ships with the binary. For a first real use, create one profile per provider you actually pay for, then switch to the one you want before starting Claude Code or Codex. Because the README does not document the config file locations, the safe first test is to add a profile, switch to it, and then open the target CLI's own config file to confirm the endpoint changed. Windows users should look at the releases page for a build, since the platform badge lists Windows, macOS and Linux but the README gives no Windows-specific install command.

Where CC-Switch CLI is the wrong tool

If you use exactly one provider and never change its endpoint, this adds a layer between you and a config file you could edit in ten seconds. The tool also assumes it is allowed to rewrite the configuration of the CLIs it manages; if your Claude Code or Codex setup is generated by another tool, such as a dotfiles manager or a corporate provisioning script, two writers on the same file will fight. The README does not describe a dry-run mode or a backup of the previous config, so an accidental switch is not obviously reversible from the documentation alone. Uninstall is another gap: the related searches include people looking for an uninstall path, and the README does not document one, which means cleaning up is on you. Finally, the WebDAV sync is described as compatible with upstream CC-Switch, but the README is silent on conflict resolution when two machines edit the same profile, so do not treat it as a multi-user store.

CC-Switch CLI versus the upstream CC-Switch desktop app

The most direct alternative is CC-Switch itself, the project this one forks. The difference is the interface and the deployment: upstream is the original application, while CC-Switch CLI is a Rust command line tool aimed at people who want to script profile changes or run them over SSH. The README explicitly says the WebDAV sync feature is fully compatible with the upstream project, which suggests the two can share the same remote profile store rather than forcing a choice at the data level. That compatibility is the reason to pick the CLI fork if your workflow is terminal-first: you keep the upstream sync format and gain a TUI plus scriptable commands. If you want a graphical window and do not care about scripting, upstream remains the natural choice, and the README does not claim the CLI adds capabilities upstream lacks beyond the command line surface.

Maintenance, licence and the cost of keeping up

The repository is not archived, and the last push was on 2026-09-17, with releases v5.10.5 on 2026-09-15, v5.10.4 on 2026-08-30 and v5.10.3 on 2026-08-25. That release cadence means the version you install today will likely be superseded within weeks, and the related searches show people asking about updating and about which version they are on, so plan for periodic upgrades rather than a one-time install. The project is MIT licensed, which permits commercial and private use and modification, but the README does not discuss how the licence interacts with the third-party provider services the tool configures; those services have their own terms, and nothing in the repository changes that. A practical cost to weigh is that every upgrade can change how profiles are written to the underlying CLI config files, and the README does not promise a stable on-disk format, so keep your own copy of the keys and endpoints you care about.

Editorial conclusion

Adopt CC-Switch CLI if you already juggle several Claude Code or Codex endpoints and want one switchboard instead of hand-editing config files. Skip it if you run a single provider and never change it, or if you need a documented uninstall path, because the README does not describe one. Before rolling it out, check which config files it rewrites on your platform and confirm the WebDAV sync behaviour against the upstream CC-Switch, since the README only states compatibility and gives no conflict rules.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SaladDay/cc-switch-cli on GitHub