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 → Providers and click Sign in (guided setup does this as its last step). 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 the profile’s own store at ~/.local/share/isolade/profiles/<id>/auth/{claude,codex}/ (mode 0600, never git-tracked). Each profile signs in on its own, so its credentials are scoped to that profile.

The model picker follows the logins. Sign in to only one of the two and the other’s models leave the picker, replaced by a Sign in to … entry. A chat that already runs on the signed-out provider’s model keeps it, flagged in the picker, and holds its send until you switch model or sign in.

Until either provider is signed in, the composer is disabled behind a “No providers configured” overlay whose Sign in button brings you here. Nothing gets as far as failing inside a VM for want of a token.

Why it signs in separately

Isolade gets its own token, the way signing in on a second device would. It never reads your host credentials — not the macOS Keychain, not ~/.codex. Everything, including read-only server features like the Usage tab, uses the credential from the in-app login for that profile.

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 → Providers and you’re done.

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.