Contents
Getting started
Using Codepanion
Connecting your tools
Everything starts with an API key: the credential your CI pipeline uses to push code snapshots to Codepanion. It travels as an Authorization: Bearer header on the ingest call.
Creating a key
In the app, open Settings and find the API Keys card. Name the key after the thing that will use it: one key per CI system is the tidiest arrangement.
The key is shown exactly once, immediately after you create it. Copy it then and store it as a secret in your CI system (e.g. CODEPANION_TOKEN in GitHub Actions secrets). Codepanion keeps only a hash of it, so a value you didn't copy can't be recovered. Create another key and revoke the one you missed.
A key can be open-ended or set to expire after 30 days, 90 days or a year. An expired key stops working and is flagged Expired in the list, so a pipeline that suddenly can't push has an obvious first thing to check.
Rotating and revoking
You can hold as many keys as you like, and each is revoked on its own. That makes rotation zero-downtime: create the new key, point CI at it, watch a push succeed, then revoke the old one. There's no hard cutover, so nothing breaks mid-rotation.
Every key lists when it was created and when it was last used, so a stale one, or one being used when you didn't expect it, is easy to spot. Revoking asks for a confirming click and then takes effect immediately: the next push presenting that key is rejected.
Or no key at all
If you push from GitHub Actions, the recommended setup stores no secret anywhere. The Keyless CI (GitHub Actions OIDC) card on the same Settings page holds an allowlist of owner/repo entries: your workflow proves its identity per run with a short-lived OIDC token, and Codepanion checks the repository against that list. This removes the CI secret and its rotation work. Static API keys stay available for CI that isn't GitHub. The workflow for both is in ingesting your codebase.
Inviting your team
An account starts with one person. Settings → Team is where the rest arrive: enter an email address, optionally a name, pick a role, and Codepanion emails the invitation. Everyone signs in as themselves, so no login is ever shared.
There are three roles, in a strict order of privilege:
- Owner. Everything a member can do, plus the settings that hold credentials: database and log connections, API keys, the keyless CI allowlist, integrations, and the team list itself.
- Member. Drives investigations. Opens them, chats with the agent, assigns, closes and reopens, and manages codebases and pinned context. This is the everyday support-engineer role, and the default for a new invitation.
- Viewer. Read-only. Can read investigations, messages and usage, but cannot start a turn or change anything, so a viewer can never spend. Reading the audit log is open to every role, viewers included.
Change someone's role from the picker on their row. Until an invitee has signed in, their row says not signed in and carries Resend for another invitation email and Remove to withdraw it. Disable is offered on any live account: it refuses future sign-ins while leaving their investigations intact, and the same button reads Enable afterwards. Removing an account that has already signed in is refused by the server, so disabling is how a real account is retired. Both destructive actions ask for a confirming click.
There is always at least one owner. The server refuses to demote, disable or remove the last one, so the guarantee holds even for a request made outside the app. The Team card is visible only to owners.
Note
An ingest-scoped API key, which is what this card mints, is scoped to your account and can only push code. It cannot read data, run database queries, or reach any other customer's account. (A key minted with the connector scope instead opens the on-prem connector channel, and cannot push code.) One name for one object: the app calls it an API key and so do these docs. On an investigation's cost meter, tokens are the model's units of text.