Extensions
Most of what your sandbox can do arrives as an extension: including the parts that shipped with it. This is how to find one, read what it may touch before you say yes, and stay in control of it afterwards.
On this page(10 sections)
What you're installing
An extension is one package that can add several kinds of thing at once: a screen in your rail, a connector card in your capabilities, a command-line tool for the agent, a background process, or all of them together. They belong together because you install a product ("deployments", "knowledge", "Reddit research"), not a skill here and a view there, so it is one identity, one trust decision, and one switch that unwires all of it.
Most of the product you already use is extensions: over twenty-five of them. Activity, Automations, Memory, Knowledge, Deployments, Pipelines, the file viewers, the commit graph, the Discord, Slack, Telegram, WhatsApp and IMAP gateways, Google Workspace, the connector catalog. All are built against the same public interface a third-party one uses, so there is no privileged internal path and a third-party extension can be as good as a built-in.
Where they come from
- Already there. First-party extensions ship inside the image. You can switch them off; you can't remove them, and they don't need installing.
- The gallery. The extensions page lists everything published to the official registry, and the same list is browsable inside the app at Capabilities → Add → Extension. One click installs from there.
- A repo URL. No registry required. Paste a git URL and a commit into the same dialog and it installs, which is how a company runs internal extensions that are published nowhere.
- Your own workspace. A directory you (or your agent) wrote under
.intentic/config/workspace-extensions/runs straight from where it sits. No clone, no install, no publishing.
All four land in the same list on Sandbox → Extensions, with one on/off switch each. So "what is running in here" is one screen regardless of how any of it arrived.
What the install dialog is telling you
Extension code runs in your browser and on your machine, so the install makes its declared host integrations legible before approval. The dialog is the extension's manifest rendered as plain English: one line per thing it declared, with the exact daemon routes it may call through the extension API spelled out underneath:
| A line like this | Means |
|---|---|
| Adds a tile to your rail | A screen of its own, in the left-hand strip, alongside the built-in ones. |
| Reads your workspace logs | A specific daemon route it may call. Anything not on the list is refused at runtime. |
| Runs a background process | Something that keeps running while the sandbox does, supervised and restartable. |
| Puts a tool on your agent's PATH | A command the agent can run in its shell, the same way it runs git. |
| Adds a connector | A card in your Capabilities catalog, with its own config form and credential. |
| Bakes layers into your image | Real packages installed in the sandbox, applied when you rebuild the environment. |
The host enforces those declarations, and the three sentences worth remembering are:
- An extension that declared no routes cannot call the daemon through the extension API.
- An extension that declared no badge cannot interrupt you from a screen you aren't looking at.
- An extension that registers a view its manifest never declared is refused at runtime, not warned about.
The extension API injects transport authorization, and a secret setting reads back as "still set" rather than its value. That reduces routine credential handling; it is not a confinement boundary. A browser bundle shares the app's JavaScript realm and can reach its DOM, storage and network APIs, and process code runs on the sandbox machine.
You approve a commit, not a project
Installing from anywhere but your own workspace pins a full 40-character commit sha, never a branch. You pick a release or a branch and the app resolves it to the commit it points at right then; from that moment the code you read about is the code that runs, and if the author force-pushes tomorrow nothing on your machine changes. An update is always an explicit, visible act.
Your own workspace extensions are pinned to nothing, for the same reason your own repositories aren't: there is no upstream that could change them behind your back, only files you can read.
Reading a listing before you install
Every listing carries one word about how much anybody has actually checked it, and the difference between them matters more than any other signal on the card:
- Listed: in the official registry, the exact source passed the deterministic scan and adversarial agent audit. No human source review is claimed.
- Verified: somebody read the source at that exact commit. A newer commit is unverified again until re-read.
- Blocked: known-malicious or known-broken, with the reason recorded for installed-extension advisories.
A separate ✓ loads mark means a nightly job re-checked the pinned commit and it would install. That is evidence, not endorsement: "it loads" and "somebody read it" are different claims, and the gallery keeps them apart. Stars are the source repo's stars.
Verification & trust is precise about what each of those words guarantees, and what none of them do. The short version: installing an extension is trusting its author, like installing an editor plugin. Source-bound automated review and a declaration of host access reduce risk; they do not isolate extension code from the app or sandbox.
Living with one
Sandbox → Extensions is the whole management surface. Each row has a switch, and switching one off unwires it everywhere at once: no view, no command, no PATH entry, no connector card, no environment variable, no background process. Nothing is left half-connected, so "turn it off and see" is a reasonable first move.
The daemon stores settings, secrets and requested environment variables under the extension's identity rather than inside its checkout. They survive an update, a revert, and even a remove followed by a re-add.
Updates
Because what you installed is a commit and a listing carries one, "there's a newer version" is a comparison your sandbox makes itself: daily, and whenever the Extensions tab is open. A newer pinned commit badges the row. What happens when you click depends on one thing: whether the new version wants more than the old one:
- Same powers, new code: one click. The new version is cloned into staging and validated first, the outgoing processes are stopped, and the swap happens only if the new one is sound. A broken release cannot replace a working install.
- It wants more than before. A new route, process, PATH entry or badge means the update asks again. The dialog computes the difference and states every addition as a plain sentence, and approval never transfers to powers you did not approve. You can also ask your own agent to read the code diff first.
After a swap the daemon watches for a minute that what the new version declared actually came up. The version it replaced is kept one back, so revert is one click: after a failed health check, or because the update made things worse.
Nothing updates itself unless you say so
Silently changing the code that runs against your repos and credentials is not a convenience. So nothing moves without you by default, and you raise individual extensions up a ladder as you come to trust them:
| Policy | What it does | When it fits |
|---|---|---|
| Notify | The badge waits for you. Nothing changes until you click. | The default, and the right setting for anything touching real credentials. |
| Agent-prepared | Your own agent reads the diff between the two commits the moment a release is listed. | Deciding then means opening a finished review instead of starting one. |
| Auto | Applied unattended, but only when four things hold at once, and it reverts itself when they stop. | Extensions you'd rather not think about, from listings somebody has actually read. |
The four conditions for Auto, all required together: the listing is human-verified, the powers didn't grow, validation passes, and the health watch stays green afterwards. Any one of them failing stops the update, or undoes it.
When a listing is withdrawn
The same daily comparison protects existing installs as well as people browsing. A listing marked blocked raises an advisory on your installed row carrying the registry's recorded reason, and by default the extension is switched off. That is the one thing that happens without asking you, because disabling runs no new code and reverses with a click.
The mirror case: a release flagged as a security fix promotes its update badge from ambient to loud. There the version you already have is the dangerous one, so waiting is the risky choice rather than the safe one.
What it costs
Nothing. Publishing and installing are free, no cut is taken, and nothing about an extension is metered or telemetered.
Related pages
- Capabilities: many extensions arrive as a connector card; this is what a connector actually gives the agent.
- Extension API: build one yourself: a workspace directory is already an extension.
- Troubleshooting: an extension that installed but went quiet, and how to tell which half broke.