# Code Switch and the local proxy that sits between Claude Code and its providers

> Code Switch is a Wails 3 desktop app in Go that starts a local HTTP proxy on port 18100, repoints Claude Code and Codex at it, and routes each request to whichever provider is enabled, with fallback, per-request usage accounting, MCP server management and skill installs.

**daodao97/code-switch** — Claude Code & Codex 多供应商代理与管理工具

- Repository: https://github.com/daodao97/code-switch
- Stars: 825 · Forks: 118
- Language: Go
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/daodao97-code-switch

## Both CLIs keep pointing at one fixed local address

Code Switch is a desktop application for managing Claude Code and Codex providers, and it is written in Go with a web frontend on Wails 3. Its central trick is that the command line tools never learn which vendor is actually serving them.

When the app starts it creates an HTTP proxy server on the local machine, bound to :18100 by default, and it then rewrites the Claude Code and Codex configuration files so both point at http://127.0.0.1:18100. From that point on the CLI sees a single stable local endpoint, while the real request is routed by the app to whichever provider the user configured.

The stated benefit of that arrangement is switching without a restart. A user can move from one provider to another without restarting the CLI, which matters because restarting means losing the conversation state and re-establishing context. The architecture is a local reverse proxy plus a configuration rewrite, and that is the whole idea rather than a wrapper around the tools.

## proxyHandler picks by priority and falls back on failure

The proxy deliberately exposes only the endpoints the CLIs actually need. Two are named: /v1/messages is forwarded to the configured Claude provider, and /responses is forwarded to the Codex provider. Everything else about the upstream conversation is left to pass through untouched.

The selection logic lives in a handler called proxyHandler. It chooses a provider dynamically based on two properties: the current priority of that provider and whether it is enabled. When a request fails, the handler falls back automatically to another candidate.

That fallback is the part with real operational consequences, and the project describes it as multi-provider automatic degradation, meaning a failing upstream degrades into another one rather than into an error. The cost is predictability. An automatic fallback is convenient for a solo developer at a desk, but in a pipeline where a silent switch to a different provider means different pricing, different data handling and different output quality, you need the request log. The application does provide log views alongside its main interface.

## Request level usage statistics with a local SQLite store

The application reports usage per request so that spending is visible, and the repository layout shows where that data lands. The Go module depends on modernc.org/sqlite, a pure Go SQLite implementation that needs no cgo, which matters for a Wails application that has to build for macOS, Windows and Linux from a single tree.

The rest of the dependency list describes the shape of the app. The HTTP server is gin, configuration parsing and editing go through go-toml, yaml.v3 and gjson plus sjson, and the UI framework is wails v3 at version v3.0.0-alpha.38. The alpha pin is worth noticing for anyone planning to depend on this project directly: the framework underneath the app is a pre-release build.

The configuration-editing dependencies are also the mechanism behind the feature people notice first. Rather than asking a user to hand edit a config file, the app reads and rewrites provider entries, which is what makes the no-restart switch possible in the first place.

## MCP server configuration for both tools in one place

Code Switch manages MCP servers for both Claude Code and Codex, described in the project notes as dual-platform management. The two CLIs disagree about where MCP server definitions live and in what shape, so maintaining them by hand means editing two files in two formats whenever a server needs to be added or removed.

Centralising that is the practical win here. A developer who keeps a stdio MCP server and a couple of remote ones configured only has to describe them once in the app, and the tool-specific formats are handled by the application rather than by the user.

The documentation excerpt available here states the capability but does not describe the storage format for MCP server definitions, whether shared between the two CLIs or duplicated per tool, nor does it show an import or export path for migrating an existing configuration. Teams with a large hand-maintained MCP setup would want to check that first, because the value of the feature depends on being able to bring your existing configuration with you.

## Skill repositories are downloaded and installed for you

The application can download and install Claude Skills automatically. Two popular skill repositories are bundled, and the project states that custom skill repositories can be added.

This is the feature with the most obvious security question attached, because automatic installation means code from a remote source lands on the developer's machine. The project notes do not describe any verification step, signature check or allowlist for the bundled or custom repositories, and they do not describe what a skill is allowed to do once installed. A skill is a directory of instructions and scripts that a coding agent will read and run, so an unverified auto-install path deserves a look before it is switched on in a work environment.

The counter-argument is convenience and consistency. Skills that are installed by hand drift, and a team that wants everyone on the same skill set has a distribution problem this solves. The reasonable approach for an organisation is to add its own internal repository rather than rely on the bundled ones, which is exactly what the custom repository support is for.

## Building the desktop app with Wails 3 tasks

Development needs Go 1.24 or later, Node.js 18 or later, and npm, pnpm or yarn, plus the Wails 3 command line tool, which the project installs with:

```bash
go install github.com/wailsapp/wails/v3/cmd/wails3@latest
```

With that in place the development loop is a single task:

```bash
wails3 task dev
```

Packaging a macOS application bundle takes two steps, and the order matters. The build metadata has to be synchronised first:

```bash
wails3 task common:update:build-assets
```

and only then is the bundle produced:

```bash
wails3 task package
```

The task definitions live in a Taskfile.yml at the repository root, with the Go entry point in main.go and the frontend under a frontend directory. The troubleshooting notes at the bottom of the project documentation name the same update-assets task as the fix for an app bundle that refuses to open, which confirms the ordering is a known sharp edge rather than an arbitrary sequence.

## Cross-compiling a Windows installer from a Mac

Windows builds are produced from a macOS environment, which needs a cross toolchain first:

```bash
brew install mingw-w64
```

The build and the installer packaging are separate tasks, both parameterised by architecture:

```bash
env ARCH=amd64 wails3 task windows:build
```

```bash
env ARCH=amd64 wails3 task windows:package
```

One macOS specific trap is documented: cross-compiling needs the terminal to have full disk access, otherwise the Go build cache under ~/Library/Caches/go-build fails with an operation not permitted error. That is a permission grant on the host, not a project defect, but it is the kind of setup step that stalls a first build.

Releases go through a publish script that packages and uploads the assets in one go:

```bash
scripts/publish_release.sh v0.1.0
```

The assets it produces are listed explicitly, which is useful for anyone writing their own distribution: codeswitch-macos-arm64.zip and codeswitch-macos-amd64.zip for the two Apple Silicon and Intel builds, plus codeswitch-arm64-installer.exe and codeswitch.exe for Windows. The download links in the project documentation point at the project's GitHub releases page rather than at a package registry.

## A young project with a recent commit and an older release

Code Switch is licensed under Apache-2.0, with the LICENSE file at the repository root and a RELEASE_NOTES.md alongside it. Apache-2.0 is a permissive licence with an explicit patent grant, and it places no requirement that a derived work be published, so embedding or modifying the project carries few obligations beyond preserving the licence and notices. That said, teams with their own legal review should read the licence text rather than rely on that summary.

On maintenance, the numbers deserve a careful reading. The last push to the repository was on 2026-06-03, and the repository is not archived. The most recent tagged releases are v0.1.8 on 2025-11-17, v0.1.7 on 2025-11-13 and v0.1.6 on 2025-11-12. The version is still in the 0.1 range, and the Wails 3 dependency is pinned to an alpha build, so this is software to try on a workstation rather than to standardise a team on.

The repository also carries test files at the top level, main_test.go and requestlog_mock_test.go, which suggests the request logging path has some coverage, and the services directory holds the application logic while version_service.go handles versioning. A team evaluating this should expect to own the Windows and macOS packaging, since the release flow is a shell script that packages and uploads assets.

## Conclusion

Code Switch suits developers who juggle several Claude Code or Codex providers and want one address to point at, plus request level cost visibility and shared MCP server configuration. It does not suit teams that need a hosted gateway, audited multi-user routing or a stable release cadence, since the last push was on 2026-06-03 and the newest tagged release is v0.1.8 from 2025-11-17. Before adopting it, check the two details the design forces on you: that a local proxy on port 18100 is acceptable in your environment, and that rewriting the Claude Code and Codex configuration files to http://127.0.0.1:18100 is reversible on your machine.

## FAQ

### What port does Code Switch proxy listen on and how do Claude Code and Codex reach it?

The app starts an HTTP proxy on the local machine, bound to :18100 by default, and automatically updates the Claude Code and Codex configuration to point at http://127.0.0.1:18100. The proxy exposes /v1/messages for Claude providers and /responses for Codex providers.

### How does Code Switch choose which provider handles a request?

A handler called proxyHandler selects a provider dynamically according to its current priority and whether it is enabled, and it falls back to another provider automatically when a request fails. The project describes this as multi-provider automatic degradation.

### Do I have to restart Claude Code or Codex when switching providers?

No. The project states that switching between providers is smooth and requires no restart of Claude Code or Codex, because both tools keep talking to the same local address at http://127.0.0.1:18100 while the app routes the request.

### What do I need to build Code Switch from source?

Go 1.24 or later, Node.js 18 or later, npm, pnpm or yarn, and the Wails 3 CLI installed with `go install github.com/wailsapp/wails/v3/cmd/wails3@latest`. Development runs with `wails3 task dev`, and tasks are defined in Taskfile.yml.

### Can Code Switch install Claude Skills automatically and add my own skill repository?

Yes. The application supports automatic download and installation of Claude Skills, ships with two popular skill repositories built in, and lets you add custom skill repositories. The project notes do not describe any verification step for those downloads.

## Sources

- [daodao97/code-switch on GitHub](https://github.com/daodao97/code-switch)
- [Issues](https://github.com/daodao97/code-switch/issues)
- [License: Apache-2.0](https://github.com/daodao97/code-switch/blob/main/LICENSE)
- [README](https://github.com/daodao97/code-switch/blob/main/README.md)
- [Releases](https://github.com/daodao97/code-switch/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/daodao97-code-switch