cc-switch-web: a web console for the configuration of AI coding tools

A fork whose whole point is the headless case

cc-switch-web is a cross-platform, web based configuration manager for a family of AI coding assistants, and it is a fork rather than an original project. The README says so directly: it is a fork of farion1231/cc-switch by Jason Young, it thanks the original author for the work, and it adds a web server mode for cloud and headless deployment.

That single difference is the whole reason to look at this repository instead of the upstream one. The upstream CC Switch is a desktop application, and a desktop application is useless on the machine where your assistant actually runs if that machine is a container, a remote box or a server without a display. The fork keeps the desktop build and adds a browser console for the same operations.

The tools it covers are Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw and oh-my-opencode, referred to as OMO. The project is MIT licensed, the implementation is Rust for the core with a Tauri shell and TypeScript for the interface, and the repository was last pushed on 2026-07-16 with releases v0.19.1 on 2026-07-11, v0.20.0 on 2026-07-15 and v0.21.0 on 2026-07-16. That is three releases in five days, which tells you the fork is being worked on hard, and it also tells you to pin a version.

The repository is a polyglot tree that matches the architecture: src-tauri/ for the Rust core, src/ for the front end, two Vite configurations, scripts/ for the deployment helpers, a Dockerfile and a Dockerfile.release, and the web build shipped separately from the desktop build.

What the console actually manages

The feature list is the clearest description of what this tool does, and it is a configuration manager rather than anything that talks to a model on your behalf.

The core list starts with one-click provider switching between OpenAI-compatible API endpoints. That is the feature the whole project exists for: the assistants each keep their own configuration file with their own base URL and key, and switching between a subscription and a pay per token endpoint means editing several files in several formats.

The second is unified MCP server management across Claude, Codex, Gemini and OpenCode, so a Model Context Protocol server is declared once in this console instead of in four separate configuration files. The third is a skills marketplace for browsing and installing Claude skills from GitHub repositories.

The fourth is a system prompt editor with syntax highlighting, which the package manifest shows is a CodeMirror editor with the JavaScript, JSON and Markdown language modes, a lint extension and the one dark theme. The fifth is configuration backup and restore with version history, so a change to a provider endpoint can be rolled back. The sixth is an OpenCode and OMO configuration UI with presets, model metadata and OMO Slim support, and the seventh is an OpenClaw configuration centre covering models, agent defaults, environment, tools, external provider reconciliation, workspace, daily memory and sessions, with ETag conflict protection and backups on that last one.

Two smaller entries are worth naming. Stream health checks with retained history let you validate that a provider's streaming responses actually work, which is the difference between a provider that is configured and a provider that is usable. And the web server mode itself is described as being for cloud and headless deployment with Basic Auth, which is the one line in the feature list that a security reviewer should read twice.

Failover, health checks and the session manager

The extended features are the ones that separate a configuration editor from an operations tool.

Backup auto-failover automatically switches to backup providers when the primary fails. Combined with the stream health checks, that turns a provider switch from something you do at 2am into something the tool does, and the health check is what tells it that the primary is failing. The health check also classifies common provider errors, so the log says which kind of failure occurred rather than that something went wrong.

The session manager browses host-side Claude, Codex, Gemini, OpenCode and OpenClaw sessions, with snapshot-bound pagination and protected deletion. Reading that carefully, the sessions live on the host where the tool runs, which is exactly what a headless deployment has and a remote browser does not, and the pagination is snapshot-bound so the list does not shift under you as new sessions arrive. Protected deletion means a session cannot be removed by a stray click.

Import and export with version history covers all configurations, and the cross-platform claim in the same list is the summary of the deployment story: Windows, macOS and Linux for the desktop, and Web or Docker for the server.

The screenshots in the README map onto the same set, with panels for provider switching and local routing, a usage dashboard, MCP server management, prompt management, the skills marketplace and an add provider form. A usage dashboard next to a provider switcher is the combination that makes the tool useful day to day, since the question is usually not which provider to use but which one you have been paying for.

Getting the server onto a headless host

The quick start recommends the web server mode for headless and cloud deployments, and there are two methods, a prebuilt binary and a container.

The prebuilt binary needs no compilation, and there is one for Linux on x86_64 and one for aarch64, both built against glibc on Ubuntu 22.04. The README is specific about the failure mode, since a binary built on a newer baseline than yours will not run: if you see a GLIBC_2.xx not found error, use Docker or build from source, and you can check your glibc with ldd --version.

The one line deploy runs a script from the repository:

curl -fsSL https://raw.githubusercontent.com/Laliet/cc-switch-web/main/scripts/deploy-web.sh | bash -s -- --prebuilt

The script takes options through environment variables, so a custom directory and port, or a systemd unit for auto start, are just variables:

# Create systemd service for auto-start
CREATE_SERVICE=1 curl -fsSL https://raw.githubusercontent.com/Laliet/cc-switch-web/main/scripts/deploy-web.sh | bash -s -- --prebuilt

For a container first deployment the README gives a plain run command against the published image on the GitHub container registry, and notes a Windows and WSL shared configuration problem that the settings screen now handles with a one-click WSL template path filler in the Advanced tab.

The practical advice for anyone deploying this is to treat the curl to bash form as what it is, a script from a branch fetched over the network and executed, and to read it or pin a tag before running it. The environment variable style makes that easy to do properly.

Three Docker stages and a non-root server

The Dockerfile is worth reading because it explains how one codebase produces two different products.

The first stage builds the interface. It starts from node:20-bookworm, copies only the manifest, the lock file and the workspace file, enables corepack, installs with a frozen lock file, then copies the TypeScript configurations and the source and runs the web build. The frozen lock file matters: it means the container build fails rather than silently resolving different versions than your machine has.

The second stage builds the server. It starts from rust:1.83-bookworm, installs libssl-dev and pkg-config, copies the src-tauri directory, and copies the already built web assets across from the first stage, then compiles with cargo build --release, the no-default-features flag, the web-server feature and the server example. That combination is the switch that turns the desktop binary into the headless one, and it also means the web assets are baked into the server binary rather than served from a directory next to it.

The final stage is small. It starts from debian:bookworm-slim, installs ca-certificates and libssl3, creates an unprivileged user with useradd, copies the compiled server into /usr/local/bin, switches to that user, and sets HOST to 0.0.0.0 and PORT to 3000 before exposing that port and running the binary. Running as a non-root user and shipping a runtime image with only the shared libraries the binary needs are both the right calls for something that holds credentials.

There is a second Dockerfile, Dockerfile.release, for the published images, and the whole set of files sits in the repository alongside a .dockerignore.

The front end, the tests, and the legal notices

The JavaScript side is a pnpm workspace with two Vite configurations, one for the desktop renderer and one for the web build, and the scripts show the split cleanly. The dev script runs tauri dev, the build runs tauri build, and there are separate renderer and web variants for each of dev, build and serve. Type checking is a separate script, formatting is Prettier over the source tree with a check mode, and the tests are Vitest with a watch mode.

The test dependencies are worth noting because they show the intended testing approach. Testing Library for React with jest-dom, user-event and jsdom for the DOM, and msw, the mock service worker, for network calls. A configuration tool is mostly forms and network requests, so mocking the service worker is how you test the parts that talk to a provider without calling one.

The interface itself uses CodeMirror for the prompt editor, with the language modes for JavaScript, JSON and Markdown, and the dnd-kit packages for drag and drop, which is the natural interaction for reordering MCP servers or providers.

The repository also carries a lot of documentation and legal material that a fork should have: a legal notice file, a licence notice file, a changelog, a quick access document, a web server guide, a Chinese readme and a separate internationalisation readme, an ssh-tunnel.sh script for reaching a local instance, a components.json for the component registry, and a tests/ directory. For a fork of someone else's project, those notices are the part that tells you what you are allowed to do with it.

Editorial conclusion

cc-switch-web fits a team whose AI coding tools run on a remote or containerised machine, where a desktop configuration app is not an option, because the fork exists for exactly that case and the deployment paths cover a prebuilt binary, a systemd service and a container. It is the wrong tool if you only use one of these tools on your own laptop, where the upstream desktop app is simpler, and it is the wrong tool if the machine holds provider API keys and the console cannot be kept behind authentication and a private network, since the web mode is protected by Basic Auth and nothing more. Before you deploy it, read the legal notice files in the repository, because a fork carries its own terms, decide whether the headless host really needs a browser console, and keep the credentials this tool holds on a host only you can reach.

Frequently asked questions

Official sources

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