Changing an API key or switching providers sounds like editing one value. It fails for a simpler reason: the same credential lives in four places, and each tool reads those places in a precedence you did not think about. If you came here looking for how to change an API key in Claude Code, or how to switch providers in cc-switch between coding agents, the mechanics reduce to three questions. Which surface holds the value? What still points at the old one? And what happens to your session history? This guide answers those for Claude Code, Codex CLI, and CC Switch, without repeating first-time setup.
Four places a credential can live
Before editing anything, locate the change you are actually making. Changing a key, switching a provider, and switching accounts look similar and touch different surfaces. Rotating an API key that several coding agents share on one machine is the hardest case, because it touches more than one of them.
Shell environment variables. Exports in your shell profile or terminal. They apply to the terminal session they were set in, which is why a change can look like it worked yesterday and not today.
Tool configuration files. Claude Code settings files with an env block; Codex's config.toml. These persist and often win over shell values in ways that depend on the specific key, since precedence is decided per variable pair rather than by source level alone.
Credential files. Codex keeps credentials in auth.json inside its home directory. A provider switch frequently edits config.toml while leaving this file pointed at the old account, which is the classic "I switched but it still says my old login" report.
Switcher profiles. A manager such as CC Switch stores whole provider configurations and writes the right one into each tool. Here the credential lives in the manager, and the question becomes which profile is active.
Whether you should architect for cheap switching at all is its own trade-off, which we compared in aggregation versus direct access. This article assumes you are changing something today.
Claude Code: how to change an API key and switch endpoints
Claude Code's documentation specifies the gateway pattern precisely, so follow it rather than guessing. The endpoint lives in ANTHROPIC_BASE_URL, and for a platform such as String AI it is the site root with no trailing /v1. The credential variable depends on what the gateway issues, and the official connect guide maps it clearly: ANTHROPIC_AUTH_TOKEN when the credential is a bearer token, ANTHROPIC_API_KEY when it is an API key, and apiKeyHelper for a command that fetches rotating credentials from a vault or an SSO flow. A credential in the wrong variable travels in a header the gateway does not read, and the request fails with 401; if that happens, switch variables and retry.
Two nuances catch people during a change. First, a gateway credential takes precedence over a saved claude.ai login: with ANTHROPIC_AUTH_TOKEN it applies immediately, while ANTHROPIC_API_KEY prompts once in interactive mode for approval before it takes effect. Second, surface matters. The CLI reads shell variables and settings files, but the VS Code extension is configured in its own user settings, and, per the same documentation, Slack and cloud sessions always use Anthropic's API and are not part of a gateway deployment; gateway variables set in a cloud session's environment configuration are not applied. If someone reports that their local change did nothing on the web, this is the documented reason, not a bug.
Where you set the value decides how long it lasts: a shell export lives for one terminal session, a settings file persists everywhere Claude Code runs. The settings system also reloads several kinds of changes mid-session, including credential helpers such as apiKeyHelper, so rotation through a helper can take effect without a restart, while a stale shell export in another terminal window will silently keep the old value.
Codex CLI: how to switch provider and rotate credentials
In practice, a Codex CLI switch provider change touches two files, not one. The provider definition lives in config.toml under [model_providers.<name>], with fields such as base_url, wire_api, and requires_openai_auth; the credential lives separately in auth.json as OPENAI_API_KEY. The platform documentation for String AI shows the shape at field level, with the base URL ending in /v1, and it is worth opening the official config reference for the current key list before editing: for example, the reference states that wire_api takes responses as its only supported value, and that provider keys placed in a project-local .codex/config.toml are ignored in favor of user-level config. That last point explains a whole category of "I changed it and nothing happened" reports.
The rule for a switch: change config.toml and auth.json in the same pass. Editing only the base URL leaves the old account's credential in place, and editing only the credential leaves the old endpoint. And because the CLI reads configuration at startup, a restart is required before an open session picks up new values, which matches what platform setup guides tell you to do after writing the files.
CC Switch: switching providers in one click and keeping session history
CC Switch is the piece that makes this a management problem instead of a file-editing problem. It is a cross-platform desktop manager for the major coding agents, covering Claude Code, Codex, OpenCode, OpenClaw, Grok Build, Hermes Agent, and more; the repository is explicit about what happens on first launch, when it imports your existing Claude Code, Codex, Gemini CLI, and Grok Build configurations as a provider named default and adds an official provider for each of these tools, so nothing already configured is lost.
From there, switching is designed to be one action: provider presets fill in the obvious fields, and the Projects feature saves a whole setup, the provider plus, for Claude Code and Codex, the MCP, skills, and prompt files, so the entire configuration can be switched at once from the project switcher at the top of the main page. If you are wiring up String AI as a provider inside it, the platform's documentation describes the Universal Provider form at field level, a name, the base URL, your API key, and a default model, followed by a Health Check that confirms the connection before you rely on it. The details live in the official CC Switch repository, which is also where the tool's own documentation should be your source of truth for current behavior.
Verify the change with a minimal request
After any change, resist the urge to open your biggest project. Send one small request first, the same discipline the five-step quickstart applies to a first call. Confirm three things:
- The request actually uses the new endpoint. In Claude Code, the
/statusoutput shows whether a gateway credential or a saved login is active; on the platform side, the usage records should show the request against the account and key you expect. - A session still works. Open a fresh session and ask something trivial. If the old one misbehaves, that is your signal to restart the tool rather than to keep editing configuration.
- No mixed credentials. On a machine with several surfaces, check the ones you did not touch: another terminal's exports, a settings file, a switcher profile, an editor extension. Mixed configurations are the most common cause of "it works in one window and not another."
Before you start, save a quick snapshot of the files and variables you are about to change. A two-minute copy is what turns a bad change into a rollback instead of an afternoon.
Coding agent session history migration
Coding agent session history migration is the step nobody budgets time for, and the honest starting point is that session storage belongs to each tool. A provider or key change is a credentials change; it does not by itself rewrite where sessions live. Per its README, CC Switch's Session Manager exists for this gap: it can browse, search, and restore each tool's conversation history from one place, and the README is upfront about the edges, noting that resuming OpenClaw and Hermes sessions isn't supported yet, so check the current limitations before planning around it. For Codex, the platform setup notes describe an optional migration script for older OAuth-based sessions, including the observation that such a session may temporarily appear missing after a provider switch without actually being deleted; the notes have you confirm the config first and preview before executing.
The safe procedure during a switch: keep the previous configuration intact until a new session under the new credentials behaves normally, and treat old sessions as read-only history until the tool's own documentation says otherwise. Nothing about credentials can guarantee that history carries over; only the tool's storage layer decides that, and testing with one session answers it faster than any guide.
Troubleshooting: symptom, surface, fix
The table maps the usual failure to the surface most likely responsible.
| Symptom | Look at | Fix |
| --- | --- | --- |
| Still the old account after a switch | Precedence and leftovers | Check other terminal windows, settings files, switcher profiles, editor extensions; a stale export in one window overrides your new value there |
| 401 after changing the key | Credential variable type | Bearer token belongs in ANTHROPIC_AUTH_TOKEN; API keys belong in ANTHROPIC_API_KEY; swap and retry |
| 404 on every request | Base URL path convention | OpenAI-compatible clients need the /v1 path; Claude Code's base URL uses the site root without it |
| Model not found | Model identifier | Use the current model list from the platform's docs instead of a remembered name |
| Works locally, not in Slack or cloud sessions | Documented limitation | Cloud surfaces use Anthropic's API and ignore gateway variables; plan around them rather than fighting them |
| Usage does not match expectations | Profile not active | Confirm with /status or the manager, then check the platform's usage records for the requests themselves |
Where to go next
- New to the setup entirely. Start with one key across coding tools, the first-time configuration this article deliberately does not repeat.
- Confirm what the endpoint supports. The compatibility checklist is how you verify the surface your tools depend on.
- Keep the books straight. Usage and cost attribution is how you confirm, after a switch, that requests and spending landed where you intended.
Change one surface at a time, verify with one small request, and keep the old configuration until the new one has answered.