Other clients

Most AI coding tools are OpenAI-compatible: somewhere in their settings is a field for a base URL and a field for an API key, because that is the least they need to support self-hosted and third-party models. If a client has those two fields, it can be put behind the firewall, and the recipe is the same every time.

This page is deliberately generic. We do not publish click paths for tools we do not track release-by-release — a stale menu path in a security product’s documentation is worse than no menu path.

The generic recipe

Any client with a custom OpenAI-compatible provider needs exactly two values.

Base URL:

https://guardrails.vulnetix.com/{provider}/{orgUuid}/v1

API key: your Vulnetix API key (vlx_…). Not a provider key.

That is the whole integration. No proxy, no daemon, no shim.

Four details decide whether it works first time:

The /v1 suffix is required. This is the OpenAI shape. (Anthropic clients are the exception that omits it — see base URLs.)
{provider} must serve the chat surface. openai, openrouter, groq, mistral, deepseek, xai, together, fireworks, alibaba, moonshot and minimax all do. anthropic does not — it serves messages only, and an OpenAI-shaped client cannot reach it through the gateway.
Your organisation must have a stored key for that provider. Otherwise the gateway answers 403 provider_key_missing — it has nothing to forward with.
Model names pass through verbatim. Use whatever the provider itself calls the model: gpt-4o-mini on openai, openai/gpt-4o-mini on openrouter.

The credential goes in the field the client calls “API key” — often labelled OpenAI API key, because these clients name the field after the protocol they speak rather than the vendor you are billing. The gateway authenticates you with your Vulnetix key and injects the provider key itself, from the KMS-encrypted vault. Your provider key never enters the client.

Clients this covers

Cline, Roo Code, Zed and the great majority of OpenAI-compatible assistants take the recipe above without modification. Each of them exposes a custom OpenAI-compatible provider with a base-URL field and a key field; fill in the two values and the client is behind the firewall.

We do not give a step-by-step for each, because the two values are the step-by-step, and the menu they live behind is the tool’s business, not ours.

Warning

Check what else the client does before you call it firewalled. An editor that ships its own models — inline completions, “quick edit”, an on-by-default indexing feature — may keep using them regardless of the provider you configure. That traffic does not reach the gateway, and your guardrails never see it. This is exactly what makes Cursor and Windsurf incompletely firewallable, and the same question is worth asking of any editor before you sign a control narrative that says “every prompt is screened”.

Clients that ship no models of their own — Cline, Roo Code, Aider, Continue — do not have this problem. Everything they send goes to the endpoint you configured.

Verify any client

vulnetix ai-firewall status

A client the CLI knows about is reported as wired, points elsewhere, not wired, manual or not installed. A client it does not know about does not appear at all — and its absence tells you nothing, in either direction.

For anything configured by hand, the only end-to-end proof is a request. Send a message that one of your guardrails should block. A 403 with code: request_blocked and blocked_by: <rule name>, rendered inside the client, is the proof: that request went through the firewall. A normal answer to a normal question proves only that something answered.

Unverified

These clients look as though they should work — they appear to support a custom OpenAI-compatible provider through their own config files — but we have not verified them against the gateway, so we publish no configuration for them.

Client	Status
OpenCode	Unverified. May work via a custom OpenAI-compatible provider in its config.
Hermes Agent (Nous Research)	Unverified. May work via a custom OpenAI-compatible provider in its config.
OpenClaw	Unverified. May work via a custom OpenAI-compatible provider in its config.

“Unverified” means exactly that: not “broken”, and not “supported”. If a client speaks OpenAI chat and lets you set both a base URL and a key, the generic recipe is very likely to work — but we have not run it, so we will not write a tutorial that implies we have. Nothing is worse in a security product’s documentation than a config that looks authoritative and is wrong.

If you get one of these working, tell us and we will document it properly.

Not supported

Client	Why
Junie (JetBrains)	Its provider is vendor-hardcoded — it reads `JUNIE_OPENROUTER_API_KEY` and offers no base-URL override. There is nowhere to point it at the gateway.

This is not a gap we can close from our side, and there is no workaround: without a base-URL override, there is no way to make Junie’s requests reach the firewall. Junie traffic goes straight to its vendor.

If you have developers using Junie and a policy that says agent traffic must be screened, those two facts are in conflict, and the resolution is a decision about Junie — not a configuration change. Continue runs in the same JetBrains IDEs and is fully firewallable.

Something else?

If you are wiring a client that is not listed anywhere in this section, start with the generic recipe, and read the error reference — the gateway’s errors are written to tell you which of the two values is wrong. 404 unsupported_api means the base URL; 401 means the key; 403 provider_key_missing means the vault.