aisw

Why people use AI Switcher

AI Switcher (aisw) exists for a very specific kind of mess:

• You use one Claude Code account for work and another for personal projects.
• Codex CLI should use one OpenAI account for client A and a different one for client B, without relying on copied shared ChatGPT session files.
• Gemini CLI or Antigravity CLI is already logged in, but you want to capture that state safely and switch back to it later.
• Your repo should open with the right coding agent account active, not whatever happened to be left over from the last project.

The underlying problem is not just "multiple accounts." It is that each upstream CLI stores auth differently, in different places, with different side effects. Manual switching usually means editing hidden files, copying auth.json, juggling CLAUDE_CONFIG_DIR, or hoping the shell session you are in still has the right environment.

aisw turns that into a named workflow:

• Save each account as a profile.
• Group mixed per-tool profiles into a context when real-world names do not line up.
• Switch in one command with rollback if something fails.
• Bind repos to expected contexts so the wrong account does not silently launch in the wrong workspace.

If you have ever searched for "AI account switcher for Claude Code", "multiple Codex CLI accounts", "Gemini CLI work and personal profiles", or "coding agent profile switch per repo", AI Switcher addresses that workflow directly.

Common situations

I need separate work and personal accounts

Store both once, then switch explicitly instead of logging out and back in:

aisw add claude work --api-key "$ANTHROPIC_API_KEY"
aisw add claude personal
aisw use claude work

The same pattern works for Codex CLI and Gemini CLI. For Codex ChatGPT-managed auth, the durable model is one isolated CODEX_HOME per profile.

I work across multiple clients

Each client can have its own Claude, Codex, Gemini, and Antigravity profiles, even when the names differ:

aisw context create client-acme \
  --claude acme-claude \
  --codex acme-codex \
  --gemini acme-gemini

aisw context use client-acme

That gives you one switch for the actual work mode instead of forcing fake naming symmetry across tools.

I want the right profile active in the right repo

Bind the repo to a context and let the shell hook warn or block when the wrong account is active:

aisw workspace bind . --context client-acme
aisw workspace guard --mode strict

This is the practical answer to "how do I avoid opening a client repository with my personal coding agent account?"

Demo

General workflow:

Context workflow:

Install

# Homebrew (macOS and Linux)
# If Homebrew asks you to trust the tap first
brew trust burakdede/tap
brew tap burakdede/tap
brew install aisw

# Shell installer (Linux/macOS)
curl -fsSL https://raw.githubusercontent.com/burakdede/aisw/main/install.sh | sh

# Cargo
cargo install aisw

Quick start

The easiest mental model is:

1. aisw init captures whatever accounts are live right now.
2. aisw add ... introduces another account directly under aisw.
3. aisw use ... restores the saved credentials for the selected profile.
4. After switching, start a fresh agent process.

If you are setting up work and personal accounts, follow this order instead of logging out and back in repeatedly at the upstream CLI first.

The top-level commands most people need are:

• aisw init
• aisw add <tool> <profile>
• aisw use <tool> <profile>
• aisw use --all --profile <name>
• aisw list
• aisw status

First account: import what is already live

# Bootstrap ~/.aisw/, install shell integration, and import
# the accounts that are already live right now
aisw init

# Verify what got imported and marked active
aisw list
aisw status

If a tool was already logged in when you ran aisw init, you do not need to re-add that same first account with --from-live.

Second account: add it directly

# Preferred path for a second Claude account
aisw add claude account-2 --label account-2@gmail.com

# Preferred path for a second Codex account
aisw add codex account-2 --label account-2@gmail.com

# If you also use Gemini
aisw add gemini account-2 --label account-2@gmail.com

This is the recommended path because AI Switcher drives the login flow itself instead of depending on whatever account happens to be live upstream at that moment.

For Codex specifically, this distinction matters:

• Durable: aisw add codex <name> for ChatGPT-managed auth, because login happens inside that profile's isolated CODEX_HOME.
• Bootstrap only: aisw add codex <name> --from-live when you intentionally want to import the currently live ChatGPT-managed session.

Switch between saved accounts

aisw use claude account-1
aisw use claude account-2

# If profile names line up across tools
aisw use --all --profile account-1
aisw use --all --profile account-2

After aisw use ..., start a fresh agent process. You should not need to log out and log back in manually after every switch, but you should not rely on reusing an already running or resumable session from the previous account.

When to use --from-live

Use --from-live when you intentionally want to capture whichever account is currently live in the upstream CLI.

# Example: import the account that is currently live upstream
aisw add claude account-2 --from-live --label account-2@gmail.com

That workflow is:

1. Exit the upstream CLI.
2. Log out upstream.
3. Log back in upstream as the account you want to capture.
4. Run aisw add ... --from-live.

That is a valid import path, but it is not the best default recommendation when AI Switcher can run the login flow directly.

Use these when your setup is a little different from the normal two-account OAuth flow above.

# API-key-backed profiles
aisw add claude work --api-key "$ANTHROPIC_API_KEY"
aisw add codex work --api-key "$OPENAI_API_KEY"
aisw add gemini work --api-key "$GEMINI_API_KEY"

# Switch every tool when the profile names line up
aisw use --all --profile work

# Create one mixed-tool context when names do not line up
aisw context create acme \
  --claude acme-claude \
  --codex acme-codex \
  --gemini acme-gemini

aisw context use acme

• Claude: after switching, start a fresh Claude process instead of relying on a resumed session from the previous account.
• Codex: ChatGPT-managed aisw add codex <name> --from-live is bootstrap-only. The durable path is direct per-profile login with aisw add codex <name>.
• Codex: personal access token sessions imported from live state are treated separately from ChatGPT-managed refresh-token auth, so the shared-mode ChatGPT block does not apply to them.
• Codex: shared-mode ChatGPT auth switching is explicitly unsupported.
• Gemini: Google-account login is currently documented upstream as the recommended interactive local path. Some account types still require GOOGLE_CLOUD_PROJECT, and headless automation should prefer GEMINI_API_KEY or Vertex AI.
• Gemini: aisw init and aisw add gemini ... can still capture the currently live Gemini state for supported upstream auth modes, but you should start a fresh process after switching.
• Antigravity: OAuth only. --api-key and --from-env are rejected, because upstream documents keyring-backed sign-in rather than API-key profile auth.
• Antigravity: no documented per-profile auth root exists, so switching replaces the shared live session and --state-mode does not apply.

Generic command examples

Once the two-account flow above makes sense, these are the shorter building blocks:

# Bootstrap: creates ~/.aisw/, offers shell-hook setup,
# and can import already logged-in accounts
aisw init

# Store profiles for each tool
aisw add claude work --api-key "$ANTHROPIC_API_KEY"
aisw add claude personal
aisw add codex work --api-key "$OPENAI_API_KEY"
aisw add gemini work --api-key "$GEMINI_API_KEY"

# Save a cross-tool context when profile names differ
aisw context create acme \
  --claude acme-claude \
  --codex acme-codex \
  --gemini acme-gemini

# Switch
aisw use claude work