> ## Documentation Index > Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Coding CLI Integrations > Use the LangWatch AI Gateway from Claude Code, Codex, opencode, Cursor, Aider. The fastest-growing surface for enterprise LLM usage in 2026 is coding CLIs: every engineer has at least one running locally, and the gap between personal and corporate use has become a governance crisis. The AI Gateway solves it, every engineer keeps their preferred CLI, the org controls cost, guardrails, and visibility. Setup is always the same two steps: 1. Mint a LangWatch virtual key (see [Quickstart](/docs/ai-gateway/quickstart)). 2. Set the CLI's base URL and API key to the gateway + VK. The gateway exposes both OpenAI-compatible and Anthropic-compatible endpoints on the same port, so any CLI that speaks either dialect works unchanged. **Debugging a CLI sign-in or fold pipeline?** See [AI Governance → CLI Debug](/docs/ai-governance/cli-debug): `langwatch governance status`, `langwatch ingest tail`, the `langwatch login` error catalog (incl. `409 no_default_routing_policy`), and OCSF probe. ## At a glance The `langwatch` CLI ships wrappers for the 4 most common coding CLIs, they auto-inject the right env vars from your governance config so you don't have to. Native env-var setup still works everywhere if you prefer. | CLI | Wrapper | Endpoint | Native env vars | Notes | | ------------------------------------------ | --------------------- | ------------------------------------------ | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Claude Code](/docs/ai-gateway/cli/claude-code) | `langwatch claude` | `/v1/messages` | `ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN` | Tool-call deltas preserved byte-for-byte. Pin to dated model name (e.g. `claude-haiku-4-5-20251001`). | | [Codex CLI](/docs/ai-gateway/cli/codex) | `langwatch codex` | `/v1/responses` | `~/.codex/config.toml` `model_providers`, `wire_api = "responses"` | Codex 0.122+ requires `wire_api = "responses"` (chat dropped). Pin model to a Bifrost-registered name. | | [Gemini CLI](/docs/ai-gateway/cli/gemini-cli) | `langwatch gemini` | `/v1beta/models/{model}:generateContent` | `GOOGLE_GEMINI_BASE_URL`, `GEMINI_API_KEY` | Native Gemini API passthrough. Works with all Gemini models supported by your VK's Vertex/Gemini credential. | | [Cursor](/docs/ai-gateway/cli/cursor) | `langwatch cursor` \* | `/v1/chat/completions` | Custom "OpenAI API base URL" in settings | \* Cursor is a GUI app, its AI panel reads from settings, not env vars, so the wrapper is mostly cosmetic for terminal launches. The canonical setup is the in-app paste. Agent mode benefits most from budgets. | | [opencode](/docs/ai-gateway/cli/opencode) | , | `/v1/chat/completions` (or `/v1/messages`) | Per-provider config in `opencode.json` | No wrapper today, set the per-provider config explicitly. Pin opencode `1.13.x`, `1.14.x` has a known regression with custom providers. | | [Aider](/docs/ai-gateway/cli/aider) | , | `/v1/chat/completions` | `OPENAI_API_BASE`, `OPENAI_API_KEY` | No wrapper today, manual env-var path. Confirmed working with model aliases. | ## Why this matters for the enterprise Before the gateway, governance of coding CLIs was a choice between: * **Ban them**: kills productivity, drives shadow usage. * **Allow them with personal provider keys**: no visibility, no cost control, leaked credentials in dotfiles and CI logs. The gateway adds a third option: **allow every CLI, centrally governed.** * **Cost.** Each engineer's CLI spend debits the org → team → project → principal budgets you've set. * **Visibility.** Every CLI call shows up in LangWatch traces, scoped to the project the VK belongs to. * **Policy.** `policy_rules` can deny shell-exec tools or untrusted MCPs at the gateway level, even if the CLI would otherwise enable them. * **Portability.** An engineer on Claude Code and a co-worker on Codex hit the same gateway with different VKs but the same budget, you don't need to pick a winner. * **Revocation.** Rotate or revoke a VK and the CLI stops working globally within 60 seconds. No more "which laptops still have the old key?" ## Recommended VK layout for coding CLIs A workable pattern used by several early customers: * One personal-access VK per engineer (`{engineer}-cli`) bound to the engineer's principal. * Attach a `principal`-scoped monthly budget (e.g. `$200/month` for engineers, `$1000/month` for staff+). `on_breach: block`. * `policy_rules.tools.deny`: `^shell\\.exec$`, `^filesystem\\.write$` (or your org's list). * Fallback chain: Anthropic → OpenAI → Azure OpenAI. CLI autoswitches on outage. * `cache.mode: respect` so Anthropic prompt caching keeps saving 90%. Then every engineer gets a one-time setup (env vars in their shell rc) and never touches provider keys again. ## Cleaning up a machine `langwatch logout` reverses the setup. It revokes and clears your device session, then removes the telemetry wiring the wrappers installed so a plain `claude`, `codex`, `gemini`, or `opencode` stops sending traces. It only touches the blocks LangWatch wrote (the OTEL env keys in `~/.claude/settings.json`, the `[otel]` block in `~/.codex/config.toml`, and the scoped shell functions in your shell rc), leaving the rest of each file untouched. It scans first, shows you what it found, and asks before removing anything. * `langwatch logout --yes` skips the confirmation, for scripts and machine teardown. * `langwatch logout --keep-credentials` removes the telemetry wiring but stays signed in. Handing a laptop back or switching accounts is one command. ## Real-time feedback Each CLI's trace lands in LangWatch live. You can: * Pin a filter "where `langwatch.vk.tags` contains `cli`" on the project dashboard. * Page on-call if any engineer crosses 80% of their monthly personal cap. * Run an offline eval comparing Claude Code vs Codex quality on tickets of a given type. See the per-CLI pages for exact setup commands. ## Verified smoke output Lane A ran the gateway locally against `pnpm dev` on 2026-04-19 to confirm the response shape CLIs will see. Pinning the transcripts here so integrators can diff their actual output against known-good. Start the gateway pointed at a running LangWatch control plane on `:5560`: ```bash theme={null} cd services/gateway GATEWAY_CONTROL_PLANE_URL=http://localhost:5560 \ GATEWAY_ALLOW_INSECURE=1 \ go run ./cmd/gateway ``` ### `/healthz`, always 200 once the process is up ``` HTTP/1.1 200 OK Content-Type: application/json X-Langwatch-Gateway-Version: dev X-Langwatch-Request-Id: req_f5e4fd9f33a8861af4ab328aa00c45 {"status":"ok","version":"dev","uptime_s":0.988610959} ``` Kubernetes liveness probe target. `X-Langwatch-Gateway-Version` is set from the binary's `main.Version` build-arg, production deploys carry the commit SHA so operators can answer "which pod served this" straight from the response. ### `/v1/models` and `/v1/chat/completions` with no auth, 401 OpenAI-compat envelope ``` HTTP/1.1 401 Unauthorized Content-Type: application/json Traceparent: 00-e8aeda507fb93fafd3d2c20bbef283d6-53e32e8f6030ef05-01 X-Langwatch-Gateway-Version: dev X-Langwatch-Request-Id: req_8f1250b94a959c1b2502792c757264 X-Langwatch-Span-Id: 53e32e8f6030ef05 X-Langwatch-Trace-Id: e8aeda507fb93fafd3d2c20bbef283d6 {"error":{"type":"invalid_api_key","code":"missing_api_key","message":"missing API key; supply Authorization: Bearer vk-lw-... or x-api-key"}} ``` The error message names both accepted auth headers, `Authorization: Bearer vk-lw-...` (OpenAI SDK, Claude Code, Cursor, Aider) AND `x-api-key` (Anthropic SDK). Either works against either endpoint. `Traceparent` + `X-Langwatch-Span-Id` + `X-Langwatch-Trace-Id` are present even on unauth 401s, observability of probe-abuse, misconfigured CLIs is available without inspecting access logs. ### `/startupz` and `/readyz` behavior at cold boot ``` # /startupz, 503 only during the brief window before MarkStarted fires # (initialisers + optional GATEWAY_STARTUP_NETCHECK_HOSTS probe), then 200 HTTP/1.1 503 Service Unavailable {"status":"degraded","checks":{"control_plane_reachable":"ok"}} ``` `/startupz` and `/readyz` go to `200` as soon as the gateway has finished its startup initialisers and (if configured) the network-check probe has succeeded. They do NOT block on the auth cache observing a VK, a cold pod with no traffic and a fresh control-plane install with zero VKs will still go ready, and auth resolution happens on demand at request time. ### Graceful drain on SIGTERM ``` INFO msg="gateway_draining" pre_drain_wait="5s" INFO msg="gateway_shutting_down" timeout="15s" INFO msg="gateway_stopped" ``` Matches the 4-phase drain documented in [self-hosting/helm](/docs/ai-gateway/self-hosting/helm) § Graceful drain. If your CLI sees one of these response shapes, the gateway is healthy. End-to-end completion through a real VK + provider requires the per-CLI config on each integration page.