Sign in
Magic Coder uses your BridgeApp account for authentication. The first time you start coder, it walks you through sign-in. After that, it caches a single OAuth credential blob locally and reuses it automatically on later runs.
If you don’t have a BridgeApp account yet, sign up at bridgeapp.ai first.
First-run sign-in
Section titled “First-run sign-in”coderIf there’s no saved sign-in for this machine, Magic Coder will:
- Generate a one-time login URL.
- Try to open it in your default browser.
- Wait for you to complete sign-in in BridgeApp.
- Save the resulting OAuth credentials locally for reuse.
When the browser flow completes, Magic Coder enters the TUI and you’re ready to go.
Headless or remote machines (no browser)
Section titled “Headless or remote machines (no browser)”When you’re SSH’d into a remote box, on a server, or otherwise can’t open a browser, ask coder to print the URL instead of trying to open one:
coder --no-open-browserCopy the URL from your terminal, open it in a browser on a machine where you’re already signed in to BridgeApp, complete the flow there, and the running coder will pick up the credentials automatically. If the current environment cannot write to the GUI keychain, Magic Coder falls back to the per-user credentials file automatically.
Re-signing in
Section titled “Re-signing in”Inside the TUI, run:
/login/login always clears your current saved sign-in first, then starts a fresh browser-based login flow. Use it when:
- you switched BridgeApp accounts
- your saved credentials look stale
- you want to force a clean re-auth
Signing out
Section titled “Signing out”/logout/logout clears the saved credential from the active writable store. Your local Magic Coder state (workspace trust, input history, config) stays intact — only the sign-in is removed.
Where credentials live
Section titled “Where credentials live”Magic Coder looks for saved credentials in this order:
MAGIC_CODER_OAUTH_TOKEN- file fallback
- OS keychain
Saved file and keychain credentials use this JSON shape:
{"accessToken":"...","refreshToken":"...","expiresAt":"2030-03-16T00:00:00Z"}Default locations:
- macOS — Keychain service
magic-coder-credentials, account = your macOS username - Linux — Secret Service / GNOME Keyring, with fallback file
~/.config/magic-coder/credentials.json - Windows — fallback file
%APPDATA%\magic-coder\credentials.json
You generally never need to think about this. If you do — say, you’re scripting a one-off automation — see the section below.
Headless / CI override
Section titled “Headless / CI override”MAGIC_CODER_OAUTH_TOKEN is an opaque access token override. It bypasses the file and keychain entirely and Magic Coder does not try to refresh it.
For non-interactive runs, set the opaque token directly:
export MAGIC_CODER_OAUTH_TOKEN='mc_xxx_long_lived_token'If you prefer a refreshable credential file, point coder at it explicitly:
coder --oauth-credentials-file /path/to/oauth-credentials.jsonToken refresh behavior
Section titled “Token refresh behavior”Magic Coder refreshes your access token proactively, 5 minutes before it expires, while you’re using it. You don’t see this happen.
If you run multiple coder instances on the same machine (in different terminals, or in tmux), they coordinate refreshes between themselves so you don’t get racing credential writes — overlapping refreshes are safe.
If a refresh fails (the refresh token has been revoked, your session expired server-side, etc.), the saved credential is invalidated and you’ll be asked to sign in again with /login.
Choosing a different BridgeApp deployment
Section titled “Choosing a different BridgeApp deployment”Magic Coder defaults to the production BridgeApp deployment. If your team uses a different deployment (a development cluster, a staging environment, or a self-hosted instance), pass the host once with --server-url:
coder --server-url bridgeapp.devMagic Coder derives all the deployment URLs it needs from that base host:
- WebSocket:
wss://ws.coder.<host> - Auth (OIDC issuer):
https://auth.<host> - API:
https://api.<host>
You can also pass a full https:// URL — it’s normalized to a host. Don’t pass a ws:// or wss:// URL.
Custom OIDC client (advanced)
Section titled “Custom OIDC client (advanced)”The default OIDC client is the public Magic Coder TUI client registered with BridgeApp. To use a different client (say, a custom integration registered in your BridgeApp deployment), pass --oidc-client-id:
coder --oidc-client-id <your-client-id>You generally only need this if BridgeApp’s admin team told you to.
Troubleshooting
Section titled “Troubleshooting”The browser opens but never returns to the TUI.
Make sure you completed sign-in in the browser tab. The TUI waits for the OIDC callback to complete; if your browser blocked the redirect or you closed the tab early, the flow stalls. Press Ctrl+C to cancel and try again with /login.
The browser doesn’t open at all.
Use --no-open-browser to print the URL and open it manually.
You’re in SSH or tmux on macOS.
Sign in once from a GUI desktop session first. After that, either rely on the fallback file or export MAGIC_CODER_OAUTH_TOKEN into the remote shell.
You need to sign in but you’re already in the TUI.
Run /login from the input line. It clears the existing credential and starts a fresh flow.
Your team uses a non-default deployment.
Pass --server-url <host> (e.g. --server-url bridgeapp.dev).
When you’re signed in, head to Your first session.