Documentation
Put Claude Code, Claude Desktop, Codex CLI, Cursor, Continue, Aider and every other OpenAI-compatible agent behind the firewall — and know exactly which of their traffic does not go through it.
A coding agent is the hardest LLM client to govern, because it does not only send what you type. It sends the files it reads, the output of the commands it runs, and the diffs it produces — all as ordinary prompt content. Putting an agent behind the firewall means that content is screened by your guardrails before it leaves the machine, your provider key never sits in the agent’s config, and the agent cannot quietly switch to a model your organisation has not approved.
Every agent on this page talks to the gateway over its native wire protocol. There is no local proxy, no daemon, and no shim to install. You change a base URL and a key, and that is the whole integration.
| Agent | Surface | CLI-wired? | Mechanism | Caveats |
|---|---|---|---|---|
| Claude Code | messages | Yes — install claude-code | ~/.claude/settings.json env block, or shell exports | ANTHROPIC_API_KEY must be set to an empty string; /logout first if a previous Anthropic login is cached |
| Claude Desktop | messages | No — manual | Built-in third-party gateway, behind developer mode | Requires a full restart, then Continue with Gateway on the start screen |
| Codex CLI | responses | Yes — install codex | ~/.codex/config.toml, a [model_providers.*] block | Requires wire_api = "responses"; only the openai provider serves it |
| Cursor | chat | No — manual | Settings → Models → API Keys | Tab completions and Auto mode do not route through your key. Agent-mode tool calls may fail |
| Continue | chat | Yes — install continue | ~/.continue/config.yaml + ~/.continue/.env | The .env holds the literal key (the IDE cannot read your shell env) |
| Aider | chat | Yes — install aider | .aider.conf.yml | None once wired |
| Windsurf | chat | No — manual | Model / API-key settings panel | Same class of gaps as Cursor: its own built-in completion features are not BYOK |
| Cline, Roo Code, Zed, … | chat | No | Any “OpenAI-compatible provider” field | Generic recipe: base URL + key |
| OpenCode, Hermes Agent, OpenClaw | chat (expected) | No | Their own config files | Unverified against the gateway. May work — tell us if it does |
| Junie (JetBrains) | — | No | — | Not supported. Its provider is vendor-hardcoded and it offers no base-URL override |
Guardrails run identically on all three request surfaces — chat, responses and
messages — so a rule you write once covers a curl, a Codex turn and a Claude Code
tool result alike. You never write a policy per agent.
For agents specifically, the important property is that tool results are
scanned. When an agent reads a file or runs a command and feeds the output back
into the conversation, that content is a prompt segment like any other and goes
through your guardrails on the next turn. A secret in a .env the agent happened
to cat is caught on the way out.
When a guardrail blocks a request, the gateway answers 403 with
code: request_blocked and blocked_by: <rule name>, rendered in the dialect of
whatever client asked. Your agent prints a readable error, not a bare status code.
vulnetix ai-firewall install claude-code codex aider
install takes one or more client ids (or none, to wire every client it detects).
For each one it writes a managed block into that client’s own config file —
the base URL for your organisation, and a reference to the VULNETIX_API_KEY
environment variable. It never invents settings the client does not have.
Before it writes anything, it checks:
no provider is ready to wire: store a provider key first with 'vulnetix ai-firewall key set <provider>'--model is validated against your organisation’s policy before the file
is touched, so you cannot wire a model your org would refuse at request time.--embed-key refuses to write a literal key into a path that is not
git-ignored. It is a hard error, not a warning — it will not help you commit a
secret.Useful flags: --provider (repeatable), --model, --scope user|project,
--dry-run, --embed-key, --create-env, --gateway-url.
To undo:
vulnetix ai-firewall uninstall claude-code # one client
vulnetix ai-firewall uninstall --all # every client
vulnetix ai-firewall uninstall --all --except codex
uninstall removes only the managed block. It needs no authentication and touches
nothing but local files.
package-firewall is a different Vulnetix product, and it also writes a
managed block to the same shell rc file. Seeing two Vulnetix blocks in your
~/.zshrc is expected and correct. Each product’s uninstall strips only its own
marker, so removing one never disturbs the other.vulnetix ai-firewall status
status lists every provider and whether a key is stored, every local client it
detected and whether it is wired, points elsewhere, not wired, manual or
not installed, and a set of checks. The one to read first is
bypasses_firewall — a client on your machine that is configured to talk to a
provider directly. The others are provider_denied, provider_key_missing,
model_denied, model_not_allowed, wire_unsupported, key_env_unset and
guardrail_pattern_invalid.