Docs

Agent accounts

Isolade signs in to Claude and Codex itself. You do not need the claude or codex CLI installed or logged in on the host.

Signing in

Go to Settings → Accounts and click Sign in. A throwaway VM runs the CLI’s loopback OAuth flow (claude auth login or codex login), Isolade opens the authorize URL, you sign in, and the browser callback completes it automatically. No codes to copy.

The credential is harvested into Isolade’s own store at ~/.local/share/isolade/auth/{claude,codex}/ (mode 0600, never git-tracked).

Why it signs in separately

Isolade gets its own token, the way signing in on a second device would. It deliberately does not copy your host Keychain or ~/.codex credentials.

The reason is refresh tokens. They’re single-use: a shared copy would mean Isolade and your host CLI rotate the same token and invalidate each other. By signing in independently, Isolade leaves your host CLIs working untouched.

So sign in once under Settings → Accounts and you’re done. (Read-only server features like the Usage tab still fall back to reading the host Keychain when Isolade isn’t signed in, since those only read the token, never refresh it.)

How the token reaches every VM

Two mechanisms make the in-VM login and the shared credential work. Both are covered in more depth under Architecture → Agent account internals.

The login callback bridge. Isolade publishes the CLI’s loopback port out of the VM and runs a small host-side TCP proxy on the redirect port, so the browser callback reaches the login server inside the VM.
Credential propagation. The auth directory is bind-mounted into every instance VM. A tiny watcher keeps each VM’s credential file in sync with the store by access-token expiry, newer wins. A refresh that one VM performs propagates back to the store and into every other live VM, with no central refresher to run. The refresh token never leaves the store or the VMs.