API keys

API keys

Workspace credentials for the MCP server and the ct CLI — one key per agent, read-only when that is all it needs.

API keys are how everything outside the app — the MCP server, the ct CLI, your own scripts — authenticates with your workspace.

Creating a key

In the app, open Settings → API Keys (under Workspace) and create a key. Give it a name, optionally an expiration, and copy it when it’s shown — it is not shown again. Store it somewhere safe, like the secret store your agent already uses. The tab also shows a ready-made Add to Claude Code command for the key.

Read-only keys

Switch on Read-only when creating a key and it can read the workspace but not change it: every write is refused, whether it comes through MCP, the CLI or a plain HTTP call. Right for a reporting script, a dashboard, or an agent that should only ever look. ct status tells you whether the key you are using is read-only.

Using a key

  • MCP (hosted): send it as a Bearer token — Authorization: Bearer <your-api-key>
  • MCP (local): pass it as the API_KEY environment variable
  • CLI: ct login creates and stores one for you; ct login --api-key <key> stores an existing one

Who did what

A change made with a key is attributed to the member who owns it — the key belongs to you, and so does what it does. The app adds which agent session made it, so the timeline and comments read AI · <session> · via <member>, with the key’s name as the fallback when the client sends no session. That is why one key per machine or client is enough: several sessions sharing a key stay distinguishable.

Workspace admins see All workspace keys, with each key’s owner, and can delete any of them. Deleting a key cuts that agent’s access at once and disturbs no other.

Rate limits

API traffic is rate limited. Well-behaved agents stay far below the limit; if a runaway loop hits it, requests are rejected with a standard 429 response and a Retry-After header until the window resets.