Claude Code in Cowork
“Cowork” gets used for two different things:
- The Cowork tab in the Claude Desktop app — not currently supported, tested and confirmed. See below.
- A cloud session you start in a browser at claude.ai/code — a cloned repo running in its own sandbox. This one works, with setup. See below.
Both are different from your machine's regular terminal or the Desktop app's Code tab, where the normal setup already works.
Desktop app — Cowork tab
AgentGuards does not work in Cowork today. This isn't a missing setup step — we went all the way through it with a real key and it still didn't work.
The plugin does show as installed in Cowork's plugin panel, with its skills listed under their bare names (/guardrails, /setup, /status, no plugin prefix). Asking Claude in Cowork to run the setup skill is unreliable — one attempt produced a fabricated explanation (a made-up claim that the plugin has no public source, with invented citations) instead of the real steps. A second attempt worked correctly: it asked for the key, saved it, and gave the right restart instructions. We completed that path in full — real key, full quit and reopen of Desktop, brand-new Cowork session afterward.
The hook that's supposed to fire on every single message, regardless of configuration, still never appeared — before the key, and after it. That rules out “the key didn't reach the right place” as the explanation. Hook-based enforcement does not currently run in Cowork sessions at all, independent of configuration. Confirmed live, not inferred from documentation.
Use the Desktop app's Code tab, a terminal, or a cloud session instead — all three work today; see below for the cloud session setup. We'll update this page the moment that changes. If you've gotten hooks or the setup skill working in Cowork, or found a real key-configuration path there, tell us at support@agentguards.co — we'd rather correct this page than have you guess.
Cloud sessions (claude.ai/code)
A session you start in a browser at claude.ai/code runs in an ephemeral cloud sandbox — a container with its own home directory, discarded when the session ends. It never reads the ~/.claude/settings.json on your machine either, but unlike Cowork it does have a settings screen for exactly this, on the cloud environment you pick before starting the session. Three one-time steps there.
/agentguards:setup from inside the session itself cannot do this for you — there is no file it can write that survives. Configure the environment instead, then start a new session.1. Allow the AgentGuards domain
This is the step people miss, and skipping it looks exactly like a broken API key. Cloud environments default to Trusted network access — an allowlist covering package registries, GitHub and cloud SDKs. AgentGuards is not on it, so every guardrail call fails until you add it.
Pick your environment, then Network access → Custom, and add this to the allowed domains:
prod.agentguards.coEach environment carries its own allowlist — there is no organisation-wide list an admin can push to everyone.
2. Set your key on the environment
Same environment, under Environment variables. This is the one place a value reaches the sandbox's real process environment, which is what both the hooks and the MCP server read.
AGENTGUARDS_API_KEY=ag_your_token_hereThis field is plaintext.
Anyone who can use that environment can read the value. On a personal environment that is fine. On a shared team environment, every member gets your key.
So mint a separate key for this from your keys page, name it cloud-session, and you can revoke it later without breaking your local setup. Note the free plan allows one API key — on free, reuse the key you have.
3. Enable the plugin from your repo
A cloud session does not inherit the plugins installed on your machine — it installs what the repository asks for. Commit this to your repo's .claude/settings.json:
{
"extraKnownMarketplaces": {
"agentguards": {
"source": { "source": "github", "repo": "alelaguard/agentguards-plugins" }
}
},
"enabledPlugins": ["agentguards-claude@agentguards"]
}The bundled hooks come with the plugin — you do not declare them separately. Note that an env block in this file is ignored in cloud sessions; that is why the key goes on the environment in step 2 rather than here.
Verify it actually works
Start a new session. Don't rely on health_check — it only proves the service is reachable and returns ok even for a placeholder key. Instead ask Claude to run check_input on something that should be refused, such as a request to reveal all of your API keys, and confirm the decision comes back block. That single call is what proves both the key and the domain allowlist took effect.
| What you see | What it means |
|---|---|
| “no API key configured — guardrails are OFF” | Step 2 did not take. The variable is missing from the environment, or the session started before you added it. |
| Everything is blocked, or “service unreachable” | Almost always step 1. The key is set but the sandbox cannot reach prod.agentguards.co, and the hooks fail closed by design. |
| The MCP server fails to connect | The key is not in the environment — the MCP header reads the same variable as the hooks. |
| Nothing happens at all | The plugin did not install. Check step 3 is committed and on the branch the session checked out. |
Fail-closed is the default: once a key is set, an unreachable service blocks rather than silently allows. Set AGENTGUARDS_FAIL_OPEN=true on the environment if you would rather prefer availability.