Connect Claude Code, Codex, Cursor, OpenCode, Devin, pi or fx to Sessionboxer

The first screen is the prompt box with the Provider logos above it: click the agent you want to use and the dialog opens. Sign in with is the short way: it opens the Provider's sign-in page in a new tab of this browser — the one where you are already signed in to Claude, ChatGPT, Cursor or Devin, or where Chrome has your password — and finishes the login for you. Claude Code and Devin show a code on their page once you are in: paste it into the field under the button. Codex is the other way round: the dialog shows a one-time code, type it into the page. Cursor needs nothing more; the dialog notices when the page is done. pi has no browser sign-in (its /login lives in its terminal): paste or import its file, or Use this machine's pi login when the server runs where pi is logged in. OpenCode has none either (its logins are per model provider, made with opencode auth login): paste or import its auth.json, or Use this machine's OpenCode login. Behind the button, Sessionboxer runs the Provider's own login CLI (the one on the machine the server runs on when it is installed there, else a throwaway box from the Sandbox image) in a scratch home, so your own ~/.claude.json, ~/.codex/auth.json, … are never read or rewritten, and stores only what the CLI produced — the same token or file you would paste by hand. When the server runs on your own machine and its CLI is already logged in there, the dialog says signed in as you@…; for Codex, Cursor, OpenCode and Devin Use this machine's login copies it without any browser tab (Claude Code's own login is short-lived and cannot be copied, so the button signs in). Or using the CLI underneath is the terminal way, in three steps for your OS (macOS, Windows or Linux; switch with the tabs) — install its CLI, log in, paste (or import) what it produced. The same wizard is behind To set up → Connect a Provider in the sidebar and Global settings → Providers → Connect a Provider…. The To set up list starts with Runtime — Docker, or QEMU for Windows and macOS VMs — struck through when the machine has it; done items stay in the list, struck through. Connect a Git account next to it connects GitHub or Bitbucket (see Git accounts); skip it (later) if you only work on public repositories or none. What each Provider needs, by hand:

• Claude Code: run claude setup-token on your machine and paste the result.
• Codex: run codex login on your machine (it opens the browser; sign in with your ChatGPT account), then paste or import ~/.codex/auth.json. Settings shows the account, plan and last refresh it holds, never the file. Codex refreshes the tokens inside the file while it works; the refreshed file is stored back so other Codex sessions and your next session keep working. Paste it again if Codex answers Your access token could not be refreshed.
• Cursor: install the Cursor CLI on your machine and run agent login (it opens the browser; sign in with your Cursor account), then paste or import the file it writes: ~/.config/cursor/auth.json on Linux, ~/.cursor/auth.json on macOS, %APPDATA%\Cursor\auth.json on Windows. An API key from cursor.com → Dashboard → Integrations works too, pasted in the same field. Settings shows whether it holds a login or an API key and until when the login's token is valid, never the file. Cursor refreshes the token inside the file while it works; the refreshed file is stored back so other Cursor sessions and your next session keep working. Paste it again if Cursor sessions fail to start with an authentication error.
• OpenCode: install OpenCode on your machine (curl -fsSL https://opencode.ai/install | bash, npm i -g opencode-ai or brew install opencode) and run opencode auth login once per model provider you want it to use (Anthropic with your Claude Pro/Max login, OpenAI with ChatGPT, OpenCode Zen, Google, OpenRouter, an API key…), then paste or import the file it writes, ~/.local/share/opencode/auth.json (the same path on macOS and Windows). An API key from opencode.ai/auth (OpenCode Zen) pasted alone works too. There is no Sign in with OpenCode button: each of its logins is a browser OAuth that calls back to its CLI, which the browser flow of the other Providers cannot carry. Settings shows which providers the file holds a login, API key or token for, never the file. OpenCode refreshes OAuth tokens inside the file while it works; the refreshed file is stored back so other OpenCode sessions and your next session keep working. Paste it again if OpenCode sessions answer with an authentication error.
• Devin: run devin auth login on your machine, then paste the token from ~/.local/share/devin/credentials.toml.
• pi (earendil-works/pi): runs on your own model accounts. Install it (npm i -g @earendil-works/pi-coding-agent, Node.js 22+), run pi and type /login to sign in with Anthropic, OpenAI, GitHub Copilot, OpenRouter, … then paste or import ~/.pi/agent/auth.json (%USERPROFILE%\.pi\agent\auth.json on Windows); and/or paste API keys as NAME=value lines (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY, …) in the second field — they reach the pi process in the box as its environment only. pi has no browser sign-in: its login lives in its own terminal. Settings shows which model providers the login covers, never the file or the keys. pi refreshes OAuth tokens inside the file while it works; the refreshed file is stored back.
• Kimi CLI: install Kimi CLI (uv tool install kimi-cli==1.52.0), run kimi login, then paste or import the whole ~/.kimi/credentials/kimi-code.json file in Global settings → Providers. Or choose Connect a Provider → Kimi CLI → Sign in with Kimi CLI: the CLI prints a device URL and code, and the dialog opens that page in your browser. Settings shows only OAuth metadata and expiry; refreshed tokens flow back from running Sessions. API-key-only use is unsupported until Kimi’s ACP server honours it: 1.52.0 requires the Kimi Code OAuth file even with a valid Moonshot API key and config. Docker · Linux and QEMU · Windows are supported; QEMU · macOS is disabled because the guest is x86_64 and Kimi has no build for it.
• fx: install fx on your machine (curl -fsSL https://fx.sh/setup.sh | bash) and run fx login (it opens the browser; sign in with your Vercel account), then paste or import ~/.fx/auth.json. fx login codex (ChatGPT subscription) writes ~/.fx/chatgpt-auth.json and fx login grok (Grok subscription) ~/.fx/grok-auth.json; paste either in the same field, and fx runs on that provider. An AI Gateway API key from vercel.com → AI Gateway → API keys works too. Settings shows which login it holds and until when its token is valid, never the file. fx refreshes the tokens inside the file while it works; the refreshed file is stored back so other fx sessions keep working. fx runs in Docker · Linux and QEMU · macOS sessions; it has no Windows build, so the Agent dropdown disables it when QEMU · Windows is chosen.
• GitHub Copilot: Sign in with GitHub Copilot runs copilot login --device-code for you and shows the one-time code for github.com/login/device. By hand: install GitHub Copilot CLI (npm install -g @github/copilot, Node.js 22), put { "storeTokenPlaintext": true } in ~/.copilot/settings.json (else the token goes to the OS keychain), run copilot login, then paste or import ~/.copilot/config.json. A fine-grained GitHub token with the Copilot Requests permission (github.com → Settings → Developer settings → Fine-grained tokens) works too, pasted in the same field; the token of a GitHub connector does not (it lacks that permission). Settings shows the kind of login and the GitHub user it names, never the token. The Sandbox hands the token to the agent as COPILOT_GITHUB_TOKEN and keeps the file in memory only; COPILOT_GITHUB_TOKEN in the Control Plane's environment overrides the stored login. Needs a Copilot plan with the CLI enabled (Free, Pro, Pro+, Business or Enterprise). Runs in Docker · Linux, QEMU · Windows and QEMU · macOS sessions.
• Mistral Vibe (mistralai/mistral-vibe): runs on your Mistral account. Click Sign in with Mistral Vibe in Connect a Provider: the browser opens console.mistral.ai, you sign in, and the API key Mistral hands out is stored. Or create a key at console.mistral.ai → API Keys and paste it; or, if you use Vibe on your own machine without an OS keyring, paste or import the ~/.vibe/.env it wrote (MISTRAL_API_KEY=…; with a keyring, the key is there and not in a file). Settings shows whether it holds a key or an .env, never the key. The box keeps it in memory only, as Vibe's .env; a sign-in from inside the agent flows back here. Vibe runs in Docker · Linux, QEMU · Windows and QEMU · macOS sessions.
• Grok Build (xAI's own coding agent; not to be confused with fx's fx login grok, which puts a Grok subscription behind Vercel's agent): install it on your machine (npm install -g @xai-official/grok) and run grok login (it opens the browser; sign in with your xAI account), then paste or import ~/.grok/auth.json, or click Sign in with Grok Build in Settings → Providers (xAI's device flow: open the link, confirm the code). An xAI API key from console.x.ai → API keys works too, pasted in the same field. Settings shows which it holds (and the account's e-mail and token expiry when the file says), never the key. Grok Build refreshes the session in the file while it works; the refreshed file is stored back so other Grok Build sessions keep working. It runs in Docker · Linux, QEMU · Windows and QEMU · macOS sessions.
• Gemini CLI: install Gemini CLI on your machine (npm install -g @google/gemini-cli, Node.js 20 or newer), run gemini and choose Login with Google in its first-run dialog (or /auth later; it opens the browser), then paste or import ~/.gemini/oauth_creds.json. A Gemini API key from aistudio.google.com works in the same field; Vertex AI credentials do not. Settings shows which login it holds, the account's email and until when its token is valid, never the file. Gemini CLI refreshes the token inside the file while it works; the refreshed file is stored back so other Gemini sessions keep working. There is no Sign in button: Gemini CLI's login lives in its interactive screen only. Gemini CLI runs in Docker · Linux, QEMU · Windows and QEMU · macOS sessions.
• Qwen Code (QwenLM/qwen-code): install it on your machine (npm i -g @qwen-code/qwen-code), run qwen, /auth → Qwen OAuth (it opens the browser; sign in with your qwen.ai account, free tier), then paste or import ~/.qwen/oauth_creds.json. Or, in the second field, point it at any OpenAI-compatible endpoint with NAME=value lines: OPENAI_API_KEY, OPENAI_MODEL and OPENAI_BASE_URL (DashScope, ModelScope, OpenRouter, a local server); the keys reach the qwen process in the Sandbox as its environment only. Settings shows which login it holds and until when its token is valid, never the file. Qwen Code refreshes the OAuth token inside the file while it works; the refreshed file is stored back so other Qwen Code sessions keep working. Qwen Code runs in Docker · Linux, QEMU · Windows and QEMU · macOS sessions.

Global settings (bottom of the sidebar) is laid out like the Advanced dialog: the groups down the left — Providers (logins, Claude API), Environment (CPU and memory, Docker inside the Sandbox, snapshots, Windows and macOS VMs, TLS certificates), Agent (Claude model aliases, system prompt), MCP & connectors (the built-in desktop and sessionboxer servers with their settings, Git accounts and author, GitHub OAuth App, your own servers), Auto QA, Interface (color theme, dictation), Devices and remote access — and the one you picked on the right, each caption with a ? for its explanation; #/settings/<group> links straight to one (old section links such as #/settings/agent-tools still open the right block). Save writes every section at once, whichever is on screen. Tokens are stored in ~/.sessionboxer/config.json (readable only by you) and are only handed to the containers of sessions that use that agent. Settings also holds the default git name and email that commits made by agents will carry (blank means your machine's git config; either can be overridden per session when creating it), and how much CPU and memory each session gets (2 CPUs and 4 GB by default).