Supported Tools

For a quick compatibility overview, see the supported tools page.

aisw supports four AI coding agent CLIs:

Tool	Binary	Auth methods	macOS	Linux	Windows
Claude Code	claude	OAuth, API key	Full	Full	Full
Codex CLI	codex	OAuth, API key	Full	Full	Full
Gemini CLI	gemini	Enterprise auth, Vertex AI, API key	Full*	Full*	Full*
Antigravity CLI	agy	OAuth, API key	Full	Full	Full

The colored marks identify the upstream products; the links point to their official product or project pages.

aisw status reports whether the detected release matches the audited compatibility baseline. A non-verified release is a warning, not an automatic block; review the versioned acceptance baseline before relying on changed upstream auth/storage behavior.

Binary detection

aisw resolves each tool from PATH and confirms it is present by running <binary> --version. If a binary is not found, aisw status reports it as missing and aisw use for that tool is blocked with an error.

State mode

Tool	isolated (default)	shared
Claude Code	CLAUDE_CONFIG_DIR set to profile directory when the install supports profile-owned auth	CLAUDE_CONFIG_DIR unset
Codex CLI	CODEX_HOME set to profile directory	CODEX_HOME unset for API-key profiles only
Gemini CLI	Profile files applied to ~/.gemini/	Not supported
Antigravity CLI	Not supported	Shared live keyring-backed auth and provider selection restored transactionally

In isolated mode, the tool reads config, history, and extensions from the profile-specific directory. In shared mode, the tool reads its standard config directory. Credentials are applied to the live location in both modes; state mode only controls which config directory the tool reads.

For Codex ChatGPT-managed auth, shared mode is intentionally unsupported. Use one isolated CODEX_HOME per profile and authenticate each profile independently.

For Claude OAuth, isolated mode is intentionally blocked only when Claude is using its legacy shared live Keychain credential. CLAUDE_CONFIG_DIR still isolates config/history in that case, but not the underlying OAuth credential owner. Use shared mode for that profile, or prefer API key / long-lived token flows for repeatable switching.

Gemini does not support shared mode because its auth state and broader local state (settings, session history, MCP configs) are tightly coupled under ~/.gemini/. aisw retains the existing file-backed switching model, with Antigravity-owned subtrees excluded.

Antigravity does not currently expose a documented per-profile auth/data root like CODEX_HOME or CLAUDE_CONFIG_DIR. aisw therefore supports Antigravity through shared live switching: it restores the live OS keyring credential and removes modelProvider from ~/.gemini/antigravity-cli/settings.json for OAuth. Other settings and the global config/runtime trees remain shared.

Credential storage by tool and platform

Claude Code

Platform	Live credential location	Keyring
macOS	~/.claude/.credentials.json or macOS Keychain	Supported - preferred for OAuth-based accounts
Linux	~/.claude/.credentials.json	Supported via Secret Service
Windows	~/.claude/.credentials.json	Supported via Windows Credential Manager

OAuth account metadata (display name, organization) is stored in ~/.claude.json under the oauthAccount key. aisw captures and restores this alongside credentials.

Claude Code also stores MCP OAuth tokens in the credentials payload. aisw preserves the full credential payload including mcpOAuth keys when writing to any backend.

Supported Claude auth models in aisw:

• Durable: API-key profiles.
• Durable: file-backed OAuth where the live credential file follows CLAUDE_CONFIG_DIR.
• Durable: OAuth installs whose keychain credential is scoped by CLAUDE_CONFIG_DIR.
• Supported but not isolated: OAuth profiles backed by Claude’s legacy shared live Keychain credential.
• Caution: if Claude’s keychain behavior cannot be determined, aisw warns that isolated switching may not be durable on that install.

Codex CLI

Platform	Live credential location	Keyring
macOS	~/.codex/auth.json or OS keyring	Supported
Linux	~/.codex/auth.json or OS keyring	Supported via Secret Service
Windows	~/.codex/auth.json or OS keyring	Supported via Windows Credential Manager

Codex uses CODEX_HOME to override its root directory. aisw sets this variable when applying profiles in isolated mode, which causes Codex to read its complete state (auth, config, history) from the profile directory.

Supported Codex auth models in aisw:

• Durable: API-key profiles.
• Durable: ChatGPT-managed profiles authenticated directly inside their own isolated CODEX_HOME.
• Durable when already live upstream: personal access token sessions imported with aisw add codex <name> --from-live after codex login --with-access-token.
• Bootstrap only: ChatGPT-managed profiles imported with aisw add codex <name> --from-live.
• Unsupported for import: ephemeral credentials are process-local and cannot produce a durable aisw profile.
• Unsupported: shared-mode ChatGPT auth switching for ChatGPT-managed refresh-token auth.

Codex supports native file, keyring, auto, and ephemeral storage. aisw imports readable auth.json and uses upstream file storage for its supported profiles. A managed aisw profile may keep its own secret in the system keyring, but that is separate from Codex’s native keyring. Native keyring-only and ephemeral sessions are not imported; auto is importable only when it has produced the file fallback.

Gemini CLI

Platform	Live credential location	Keyring
macOS	~/.gemini/ (oauth_creds.json, settings.json, and other state files)	Not supported
Linux	~/.gemini/	Not supported
Windows	~/.gemini/	Not supported

Gemini stores all auth and local state under ~/.gemini/. aisw captures and restores Gemini-owned regular files, excluding Antigravity’s antigravity-cli/, antigravity/, antigravity-ide/, and config/ trees and removes stale live files from the previously active Gemini profile. This includes OAuth tokens, settings, and any MCP OAuth token files stored as regular files under the Gemini state root.

Gemini CLI stopped serving Google AI Pro, Ultra, and free-tier individual accounts on June 18, 2026; those users should migrate to Antigravity. Gemini CLI enterprise and API-key / Vertex AI paths remain supported. See the upstream announcement. aisw can manage:

• API-key-backed Gemini profiles (GEMINI_API_KEY)
• Vertex AI-backed Gemini profiles
• Enterprise Google-account / Code Assist-style flows that may require GOOGLE_CLOUD_PROJECT

For interactive Google-account / OAuth-style capture, aisw uses GEMINI_CLI_HOME to redirect Gemini’s config root to a scratch directory during the login flow, then copies the resulting files into the profile. This was introduced in Gemini CLI as the clean way to redirect config storage without overriding HOME.

API key profiles store a .env file containing GEMINI_API_KEY=<key>. Switching also selects security.auth.selectedType: gemini-api-key in ~/.gemini/settings.json; writing a key alone does not override a saved OAuth provider. Imported Vertex key profiles retain the Vertex provider choice. OAuth switching selects oauth-personal. Verification checks credentials and provider selection while ignoring mutable runtime files.

Antigravity CLI

• Live auth: OS-native keyring entry (service=gemini, account=antigravity) as observed in upstream issue reports and docs-aligned behavior.
• Native transport: macOS Go envelopes, Windows gemini:antigravity with raw UTF-8, and Linux login/default Secret Service collection with service/username attributes. aisw-managed keyring entries use a separate storage contract.
• Provider selection: modelProvider in ~/.gemini/antigravity-cli/settings.json; other config/runtime files remain shared.
• --from-live: captures the current live keyring-backed session without copying global configuration or runtime files.
• Interactive OAuth: launches agy, captures the resulting live keyring session, and restores the prior live state unless --set-active is requested.
• API-key path: GEMINI_API_KEY with modelProvider: gemini in ~/.gemini/antigravity-cli/settings.json; use the shell hook or --emit-env so the key reaches agy.
• No --state-mode support because upstream does not currently document an isolated per-profile auth or data root.

Auth backend support matrix

Tool	Backend	aisw init import	aisw use	Notes
Claude Code	File credentials	Supported	Supported	Standard on Linux/Windows
Claude Code	System keyring	Supported	Supported	Standard on macOS
Codex CLI	File auth.json	Supported	Supported	Available on all platforms
Codex CLI	aisw-managed system-keyring secret	Not imported from native keyring	Supported	Applies the managed credential through Codex file storage
Codex CLI	Native keyring-only or ephemeral session	Not supported	Not imported	No readable auth.json to capture
Gemini CLI	File-backed ~/.gemini/ state	Supported	Supported	Gemini-owned file capture and restore; preserves Antigravity subtrees
Gemini CLI	System keyring	Not supported	Not supported	aisw supports file credentials; upstream encrypted credential storage is not imported
Antigravity CLI	File-backed managed profile + live OS keyring apply	Supported	Supported	Stores captured secret in the profile, then restores it into the live keyring on switch
Antigravity CLI	System keyring-backed managed profile	Supported	Supported	Stores the captured live keyring secret in aisw’s managed keyring backend
Antigravity CLI	API-key profile via GEMINI_API_KEY	Supported	Supported with --emit-env or shell hook	Stores the key using the selected profile backend and selects the Gemini API-key provider

Fail-closed means aisw refuses the operation rather than guessing. For example, Codex keyring-only or ephemeral auth is diagnosed rather than synthesized into an importable profile.

aisw add --credential-backend ... sets the managed profile backend only. It does not force the upstream CLI’s live auth backend.

References

• Auth Storage Matrix - detailed research on credential file locations and storage models per tool and platform
• How it works - implementation details and design decisions
• Security - keyring integration, file permissions, and storage safety

Gemini’s GEMINI_FORCE_ENCRYPTED_FILE_STORAGE=true mode bypasses the OAuth credential file in current upstream code. aisw does not manage that mode; use the supported file-auth path or an API-key profile. It does not decrypt or import upstream encrypted storage.