Govern Claude Code
Connect your developers' Claude Code to the appliance, choose the filter profile that governs it, and read the activity the plugin reports.
- Version: 0.4
- Role: admin_user
- Type: task
Claude Code is a coding assistant that reads and writes source on a developer's machine. The CID plugin puts every prompt and every tool result through the same detection pipeline as the rest of the product, and reports what happened. Detection & Filtering → Claude Code is where you read that: who worked on which repositories, when, and which filters fired.
What do I need?
- Licence
- Any
- Role
admin_user
Prerequisites
- Developers already have the Claude Code command-line tool installed.
- A gateway API key exists for the plugin to authenticate with. Issue one on Access keys, or let the setup wizard mint one.
- Developer machines can reach the appliance over HTTPS.
- A tenant group exists that the plugin's key resolves to, so its filter overrides govern these calls.
Note
This page is read-only. Every request it makes is a read, and nothing on it changes policy. The page's own description says what it stores: Who worked on which repositories, when, and which filters fired — from the CID plugin. Metadata only; no prompt or file content is stored.
/assets/screenshots/claude-code@0.4.pngHow Claude Code reaches CID222
Two independent layers, and only the first is on by default.
Inspection is always on once the plugin is installed. Claude Code hooks send each prompt and
the output of Read, Grep and Bash tool calls to the appliance's /inspect/v1 endpoint under the
claude-code hostname, which runs them through the guardrails and the tenant group's filter
overrides, and records the telemetry this page shows. Provider traffic is untouched.
Routing is optional. Pointing Claude Code's Anthropic base URL at the appliance's passthrough proxy puts the gateway in the request path, so it can inspect, mask or block before a request reaches the model.
Warning
Deploy inspection first and leave routing alone. The plugin's own README says to keep the Anthropic base URL unset until the transparent passthrough ships, because today's translation path drops tool calls and beta headers. Visibility-only is the correct interim deployment.
Connect one developer's Claude Code
Install the plugin
Have the developer run the installer, naming this appliance:
The installer adds the cid222 marketplace under the user's home directory and installs the
cid plugin into Claude Code. It finishes with Done. Start a new 'claude' session and run
/cid:status to verify. Re-running it is also the update path.
Give the machine an inspection key
Have the developer export the key, or drop it in the key file the plugin reads:
The gateway address is baked into the plugin build; the key deliberately is not. Add the
exports to the shell profile so they survive a new terminal. The plugin also reads a key from
~/.cid/inspect-key if you prefer to place a file with your device-management tool.
Start a session and read the banner
Have the developer start a new claude session and approve the one-time hook prompt.
The session opens with a CID line confirming inspection is active for this session and that prompts and tool output are checked against the organisation's AI-usage policy.
Verify from the developer's side
Have them run /cid:status.
It reports both layers: inspection through the hooks, and whether provider traffic is routed through the gateway.
Danger
Without a key the hooks fail open silently. The plugin sends no authorisation header, the gateway refuses the call at the edge, and nothing is inspected — with no error the developer would notice. A wrong gateway address behaves the same way, except the session banner reports a 404 and tells the developer to contact IT.
Roll it out to a team
Generate the bundle
Open the setup wizard's Connect Claude Code step, enter Proxy hostname (base URL) and API hostname (gateway), then select Generate managed settings.
The appliance mints a key named claude-code-managed, creates a tenant group called
Claude Code if it does not exist, and builds the managed-settings JSON. Leaving the
hostname fields empty produces a file full of YOUR-DOMAIN placeholders and the wizard warns
you before you paste it.
Copy the file
Select Copy under Managed settings (paste this).
The file pins the cid222 marketplace, enables the cid plugin, forbids side-loading and
unmanaged hooks, and carries the inspect key.
Choose one delivery channel
Paste the file into your Claude organisation's managed-settings page. Only an Owner or Primary Owner can reach it — a plain administrator cannot. Clients pick it up on next launch and on their regular poll.
Use one channel, not both. They do not merge: if one is populated the other is ignored.
Warning
If a developer's environment sets a non-default Anthropic base URL, Claude Code skips the console fetch entirely and the console channel silently delivers nothing. Distribute routing and settings together through the device-management file, or keep the base URL out of the JSON and have developers export it themselves.
The wizard's bundle sets an Anthropic base URL; the template shipped with the appliance's deployment files deliberately does not. Decide which of the two you are deploying before you hand the file to a team.
Set the filter profile
Claude Code is a coding surface. It legitimately reads and writes text that a chat-tuned toxicity or jailbreak model flags, and its payload is source code rather than prose. The recommended profile is therefore log-first, expressed entirely as filter overrides on a tenant group — there is no separate Claude Code policy screen.
Group the developers
Create a tenant group — Claude Code is the name the setup wizard uses — and add the developer accounts to it.
The inspect key in the managed settings must resolve to this group, or its overrides do not govern the plugin's calls.
Override the filters for that group
Set the group's overrides on Security filters.
The recommended starting point:
- Toxicity — off. Coding text trips chat-tuned toxicity constantly.
- Jailbreak and injection — off. Same reason, and it avoids a benign prompt being blocked when a detector service is unavailable.
- PII (email, name, phone, national id) — flag. Visibility without interrupting work.
- Generic secrets and keys — flag, or mask to redact them from tool output.
- Critical secrets such as live API keys and private keys — reject.
Confirm the profile is the one being applied
Watch the Policy tab of this page after a day of use.
It ranks the filters that actually fired. A rule you expected to be off appearing near the top means the key is resolving to the wrong group.
Danger
Never run Claude Code against the default filter set. With the default tenant's filters and a detector service unavailable, fail-closed behaviour blocks benign prompts, and developers experience it as the assistant breaking.
Two behaviours are worth knowing before you choose actions:
- A reject rule blocks the prompt, and the developer is told which categories matched.
- A mask rule cannot mask a prompt in place — the hook protocol does not allow it. The shipped
plugin records the prompt, warns the developer and passes it through unchanged. Tool output on
the same session is masked properly. Set the plugin's prompt-mask action to
blockif you would rather refuse those prompts than pass them.
Read the page
The toolbar filters everything below it: a range of Last 24 hours, Last 7 days (the default), Last 30 days or Last 90 days, plus exact-match boxes for Developer email, Repository (full git remote) and Branch. They are exact matches, not searches — there is no content search here because content is never stored. Export offers CSV, Excel (.xlsx), PDF and HTML, for the current tab or any named view.
Tabs
| Tab | Answers |
|---|---|
| Overview | Six counters against the previous period, activity over time, the policy-outcome mix, working hours, and the top developers and repositories |
| Developers | Per seat: sessions, prompts, tool uses, repositories, tokens, policy hits, last seen |
| Repositories | Per repository: developers, sessions, prompts, tool uses, branches, policy hits, last activity |
| Policy | Which filter fired, how often, the blocked/masked/flagged mix, and how many developers and repositories it touched |
| Sessions | One row per session: developer, repository, branch, start, duration, prompts, tokens, what was worked on |
Selecting a developer, repository or session row opens a drawer that re-queries everything scoped to that entity, so the numbers always match the tables.
Counters
| Tile | Counts |
|---|---|
| Developers | Distinct Claude Code seats reporting |
| Sessions | Distinct sessions. Plugin versions before 0.5.1 sent no session id and are not listed |
| Prompts | Prompts submitted; tool output is counted separately |
| Tool uses | Read, Grep and Bash outputs inspected |
| Repositories | Distinct git remotes worked in |
| Policy hits | Blocked plus masked plus flagged |
Attribution
A seat is attributed to a CID222 account by matching the seat's email to a tenant's contact email.
Unmatched seats are shown as unmapped with the explanation No tenant carries this seat
email, so activity cannot be attributed to a CID user. Set the tenant's contact_email to link
them. Attribution is stamped when each event is written, so linking a tenant today does not
retroactively attribute yesterday's events — a partially linked seat shows
{n}/{m} attributed.
Optional: route provider traffic through the appliance
Routing puts the gateway in the request path so it can mask or block a prompt before Anthropic
sees it. It is off by default: the proxy's inspect URL is unset and passthrough masking is
false, so the proxy forwards without inspecting.
Warning
This is a documented procedure that has not been executed on a production deployment. Enabling
it sets CID_INSPECT_URL to the full inspect path (a bare prefix returns 404 and the proxy then
fails open silently), CID_PASSTHROUGH_MASK to true, and costs 50–115 ms per request. A
masked turn rewrites the request body and loses the prompt cache for that turn. Only the text of
the last user turn is ever rewritten.
When routing is on, a blocked prompt returns an HTTP 400 reading Blocked by your organization's CID222 AI-usage policy. Detected: … Remove the sensitive content and try again. — a 400 rather than a 403 deliberately, because Claude Code reads an authorisation status as a credential failure and sends the developer chasing a login problem that does not exist.
Verify
- After a developer starts a session, the Developers tab lists their seat and Sessions is at least 1.
- Have them send a prompt containing a test value your profile flags. Within the refresh, the Policy tab shows the rule with a non-zero hit count.
- Open Event logs and filter for the developer. Clean activity is written as
CLAUDE_CODE_ACTIVITY, token counts asCLAUDE_CODE_USAGE, and a policy decision asMESSAGE_BLOCKEDorMESSAGE_MASKED— the outcomes are recorded with the product's general security event types, not with Claude-Code-specific ones. - The same events appear on All detections with the source set to Claude Code.
- If you enabled routing,
/healthon the proxy host reports the Anthropic mode as passthrough.
If it fails
- Could not load activity. The plugin telemetry endpoint may not be reachable yet. — the page could not read the activity endpoint. It appears before any plugin has ever reported in, and also on a genuine failure; there is no retry button.
- No Claude Code activity yet with No agent has reported in this window. — nothing has reported. Check that a developer has actually started a session since the plugin was installed, and widen the range.
- A seat shows as unmapped — set that tenant's contact email to the seat's email. Existing events stay unattributed; only newer activity is linked.
- The developer's session banner says the gateway rejected the inspection key — the key is wrong, revoked, or absent. Issue a new one on Access keys and redistribute.
- The developer's session banner reports a 404 from the inspect endpoint — the gateway address is wrong, so nothing is being inspected and the hooks are failing open. Fix the plugin's gateway setting.
- CID_HOST is not set. Run: CID_HOST=https://cid.company.local bash install.sh — the installer was piped to a shell without the host prefix.
- claude CLI not found — install Claude Code first. / unzip not found — install it first. — install prerequisites missing on the developer's machine.
- could not create the Claude Code group in the setup wizard — the tenant group could not be created. Create it by hand on Tenant groups and retry.
- A PDF export downloads but will not open — the renderer was unavailable and the appliance
returned an explanatory response the browser saved as the
.pdffile. Export as CSV, XLSX or HTML instead.
Known gaps
- The install URL is not settled. The plugin distribution files are served by the dashboard's web server, so the installer lives on the dashboard origin, while one repository document claims the API origin. Fetch the URL once before you circulate it to developers.
- The code-safety gate is plugin-side only. The plugin's pre-tool-use gate, session audit and repository baseline expect endpoints this build does not serve, so those hooks fail open into a no-op. Nothing about them appears on this page.
- Numbers can differ slightly between tabs. The Overview counts a hit as flagged only when a detection count is present; the Policy tab counts any non-blocked, non-masked row that carries a reason.
- Parts of the page are hard-coded English, including the chart subtitles, the day names on the heatmap, the export format names and the whole setup-wizard step.
- Sessions before plugin 0.5.1 are missing, because those versions sent no session id. The page says so above the table.
Next steps
- Security filters — where the group overrides that make up the Claude Code profile are set.
- All detections — Claude Code verdicts beside every other surface.
- Repository tracking — the other code-safety surface: scanning the repositories themselves rather than what a developer typed.
- Access keys — issue and rotate the key the plugin authenticates with.
Last updated on