Capabilities

A fresh sandbox can read and write your code. It cannot yet look at your error tracker, query your database, open a pull request, or deploy anything. Capabilities are how you close that gap, one connection at a time, on the Capabilities page.

What you're actually adding#

Four shapes, and which one a card uses is a detail of that integration rather than a choice you make:

The catalog#

The "+" grid is grouped by what a connection is for, not by how it works:

Most connector cards come from installed extensions rather than being baked into the app, which is why the grid grows without an update — and why you can add your own. See contributes.capabilities.

Adding one#

Pick a card and you get two things side by side: a guide and a form. The guide is the part that usually costs the time — where to create the credential, which scopes it needs, and a deep link straight to the right settings page (at the provider, or at your own instance if you're self-hosting one). The form is the fields that connection needs, with secrets masked.

Saving applies it, and you watch it happen: provisioning runs as a real terminal job with its output on screen, rather than a spinner that either turns green or doesn't. The card then reports one of four states — active, pending, error or inactive — re-probed live, so "connected" means the daemon just checked, not that it worked once.

Some capabilities need something installed in the sandbox image — the browser one needs Chromium. Those bake a fragment into your environment overlay and sit pending until you approve the rebuild, because changing what the container contains is your call, not the extension's.

What the agent receives#

Two things, both of them boring on purpose: an environment, and a cheatsheet.

# Two Postgres connections, added as "analytics" and "billing".
POSTGRES_URL_ANALYTICS=postgres://…
POSTGRES_URL_BILLING=postgres://…

# The agent never guesses these: each connection's own skill file names its exact variables.

Every variable is suffixed with the connection's own id, so a second connection of the same kind never collides with the first. That is what makes two databases, or a work GitHub and a personal one, a normal setup rather than a conflict.

.claude/skills/
├── analytics/SKILL.md     # how to query THIS database, with its variable names
├── github/SKILL.md        # the gh CLI, scoped to the token you gave it
└── ssh/SKILL.md           # every connected machine, in one cheatsheet

Each connection also writes a skill file the agent loads automatically: what the tool is, how to drive it, and the exact variable names this connection uses. So the agent doesn't guess at credentials or invent flags — the thing that otherwise turns a connected tool into three wasted turns.

Where the credentials live#

In your sandbox, in a file the agent is specifically not allowed to read. The manifest of active capabilities sits in your workspace's control-plane directory and is on the daemon's secret denylist, so the generic file routes answer "not found" for it — an agent cannot read its own credential store out through the file API, and neither can an extension.

Nothing goes to the intentic platform. The platform holds your identity and your sandbox's address; every credential here is one your sandbox stores and your sandbox uses.

Plain environment secrets that aren't tied to a card — an API key your own code needs — go on Sandbox → Secrets instead. That page also has an inventory view that aggregates every store, showing keys and where they came from, never values.

Living with them#

• Re-adding edits. Adding a connection under an id that already exists updates it in place rather than making a second one.
• Removing tears down. The credential, the environment variables and the skill file all go.
• One bad entry costs only itself. If a stored connection can't be read — a hand-edit, a format that moved — it is skipped and reported by name, never rewritten away, and every other capability keeps working.

Next#

• Automations & workflows: have the agent act on what a connected system tells it.
• Autonomous employees: the narrative version — specialise one sandbox until it does a job on its own.