Once AI Bridge is enabled on the server, your users need to configure their AI coding tools to use it. This section explains how users should configure their clients to connect to AI Bridge.

The exact configuration method varies by client — some use environment variables, others use configuration files or UI settings:

-**OpenAI-compatible clients**: Set the base URL (commonly via the`OPENAI_BASE_URL` environment variable) to`https://coder.example.com/api/v2/aibridge/openai/v1`

-**Anthropic-compatible clients**: Set the base URL (commonly via the`ANTHROPIC_BASE_URL` environment variable) to`https://coder.example.com/api/v2/aibridge/anthropic`

Replace`coder.example.com` with your actual Coder deployment URL.

Instead of distributing provider-specific API keys (OpenAI/Anthropic keys) to users, they authenticate to AI Bridge using their**Coder session token** or**API key**:

-**OpenAI clients**: Users set`OPENAI_API_KEY` to their Coder session token or API key

-**Anthropic clients**: Users set`ANTHROPIC_API_KEY` to their Coder session token or API key

Template admins can pre-configure authentication in templates using[`data.coder_workspace_owner.me.session_token`](https://registry.terraform.io/providers/coder/coder/latest/docs/data-sources/workspace_owner#session_token-1) to automatically configure the workspace owner's credentials.

Here is an example of how to pre-configure a Coder template to install Claude Code and configure it for AI Bridge using the session token in a template:

The same approach can be applied to pre-configure additional AI coding assistants by updating the base URL and API key settings.

Users can generate a Coder API key using either the CLI or the web UI. Follow the instructions at[Sessions and API tokens](../../admin/users/sessions-tokens.md#generate-a-long-lived-api-token-on-behalf-of-yourself) to generate a Coder API key.

The combinations below reflect what we have exercised so far. Use the upstream links for vendor-specific steps to point each client at Bridge. Share additional findings in the[`aibridge`](https://github.com/coder/aibridge) issue tracker so we can keep this table current.

| Client| OpenAI support| Anthropic support| Notes|

|-------------------------------------------------------------------------------------------------------------------------------------------|----------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

|[Claude Code](https://docs.claude.com/en/docs/claude-code/settings#environment-variables)| N/A| ✅| Works out of the box and can be preconfigured in templates.|

| Claude Code (VS Code)| N/A| ✅| May require signing in once; afterwards respects workspace environment variables.|

|[Cursor](https://cursor.com/docs/settings/api-keys)| ⚠️| ❌| Only non reasoning models like`gpt-4.1` are available when using a custom endpoint. Requests still transit Cursor's cloud. There is no central admin setting to configure this.|

|[Roo Code](https://docs.roocode.com/features/api-configuration-profiles#creating-and-managing-profiles)| ✅| ✅| Use the**OpenAI Compatible** provider with the legacy format to avoid`/v1/responses`.|

|[Codex CLI](https://github.com/openai/codex/blob/main/docs/config.md#model_providers)| ✅| N/A|`gpt-5-codex` support is[in progress](https://github.com/coder/aibridge/issues/16).|

|[GitHub Copilot (VS Code)](https://docs.github.com/en/copilot/configuring-github-copilot/configuring-network-settings-for-github-copilot)| ✅| ❌| Requires the pre-release extension. Anthropic endpoints are not supported.|

| Goose| ❓| ❓||

| Goose Desktop| ❓| ✅||

| WindSurf| ❌| —| No option to override the base URL.|

| Sourcegraph Amp| ❌| —| No option to override the base URL.|

| Kiro| ❌| —| No option to override the base URL.|

|[Copilot CLI](https://github.com/github/copilot-cli/issues/104)| ❌| ❌| No support for custom base URLs and uses a`GITHUB_TOKEN` for authentication.|

|[Kilo Code](https://kilocode.ai/docs/features/api-configuration-profiles#creating-and-managing-profiles)| ✅| ✅| Similar to Roo Code.|

| Gemini CLI| ❌| ❌| Not supported yet (`GOOGLE_GEMINI_BASE_URL`).|

|[Amazon Q CLI](https://aws.amazon.com/q/)| ❌| ❌| Limited to Amazon Q subscriptions; no custom endpoint support.|

Legend: ✅ works, ⚠️ limited support, ❌ not supported, ❓ not yet verified, — not applicable.

Most AI coding assistants that support custom base URLs can work with AI Bridge. Client-specific requirements vary:

- Some clients require specific URL formats (for example, removing the`/v1` suffix).

- Some clients proxy requests through their own servers, which limits compatibility.

- Some clients do not support custom base URLs.

See the[tested clients](#tested-clients) table above for the combinations we have verified and any known issues.


Bridge is a smart proxy for AI. It acts as a man-in-the-middle between your users' coding agents / IDEs

and providers like OpenAI and Anthropic. By intercepting all the AI traffic between these clients and

the upstream APIs, Bridge can record user prompts, token usage, and tool invocations.

Bridge solves 3 key problems:

1.**Centralized authn/z management**: no more issuing & managing API tokens for OpenAI/Anthropic usage.

Users use their Coder session or API tokens to authenticate with`coderd` (Coder control plane), and

`coderd` securely communicates with the upstream APIs on their behalf. Use a single key for all users.

2.**Auditing and attribution**: all interactions with AI services, whether autonomous or human-initiated,

will be audited and attributed back to a user.

3.**Centralized MCP administration**: define a set of approved MCP servers and tools which your users may

use, and prevent users from using their own.

As the library of LLMs and their associated tools grow, administrators are pressured to provide auditing, measure adoption, provide tools through MCP, and track token spend. Disparate SAAS platforms provide_some_ of these for_some_ tools, but there is no centralized, secure solution for these challenges.

If you are an administrator or devops leader looking to:

- Measure AI tooling adoption across teams or projects

- Provide an LLM audit trail to security administrators

- Manage token spend in a central dashboard

- Investigate opportunities for AI automation

- Uncover the high-leverage use cases from experienced engineers

We advise trying Bridge as self-hosted proxy to monitor LLM usage agnostically across AI powered IDEs like Cursor and headless agents like Claude Code.

[Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/getting-started/intro) is a mechanism for connecting AI applications to external systems.

Bridge can connect to MCP servers and inject tools automatically, enabling you to centrally manage the list of tools you wish to grant your users.

Bridge makes use of[External Auth](../../admin/external-auth/index.md) applications, as they define OAuth2 connections to upstream services. If your External Auth application hosts a remote MCP server, you can configure Bridge to connect to it, retrieve its tools and inject them into requests automatically - all while using each individual user's access token.

For example, GitHub has a[remote MCP server](https://github.com/github/github-mcp-server?tab=readme-ov-file#remote-github-mcp-server) and we can use it as follows.

CODER_EXTERNAL_AUTH_0_TYPE=github

CODER_EXTERNAL_AUTH_0_CLIENT_ID=...

CODER_EXTERNAL_AUTH_0_CLIENT_SECRET=...

CODER_EXTERNAL_AUTH_0_MCP_URL=https://api.githubcopilot.com/mcp/

See the diagram in[Implementation Details](../reference#implementation-details) for more information.

You can also control which tools are injected by using an allow and/or a deny regular expression on the tool names:

CODER_EXTERNAL_AUTH_0_MCP_TOOL_ALLOW_REGEX=(.+_gist.*)

CODER_EXTERNAL_AUTH_0_MCP_TOOL_DENY_REGEX=(create_gist)

In the above example, all tools containing`_gist` in their name will be allowed, but`create_gist` is denied.

The logic works as follows:

- If neither the allow/deny patterns are defined, all tools will be injected.

- The deny pattern takes precedence.

- If only a deny pattern is defined, all tools are injected except those explicitly denied.

In the above example, if you prompted your AI model with "list your available github tools by name", it would reply something like:

Bridge marks automatically injected tools with a prefix`bmcp_` ("bridged MCP"). It also namespaces all tool names by the ID of their associated External Auth application (in this case`github`).

[Coder Tasks](../../workspaces/tasks.md) provides a chat-first interface for terminal agents such as Claude Code CLI or Codex. To route those agents through Bridge:

- Enable Bridge at the control plane and configure the upstream provider keys.

- Inject the AI Bridge base URLs and API keys into the Task environment (for example by setting`OPENAI_BASE_URL` and`OPENAI_API_KEY`).

- Template authors can bake these variables into Task definitions so that new runs automatically use Bridge.

This setup keeps agent execution within Coder while applying the same auditing and MCP policies as IDE clients.

Bridge also works with IDE-native assistants inside workspaces. Configure the IDE extension or desktop client to point at the Bridge endpoints and rely on the workspace's environment variables for authentication. This is the fastest path to bring existing agents like Roo Code, Cursor, or Claude Code into compliance without adopting Tasks.

If a model decides to invoke a tool and it has a`bmcp_` suffix and Bridge has a connection with the related MCP server, it will invoke the tool. The tool result will be passed back to the upstream AI provider, and this will loop until the model has all of its required data. These inner loops are not relayed back to the client; all it seems is the result of this loop. See[Implementation Details](../reference#implementation-details).

In contrast, tools which are defined by the client (i.e. the[`Bash` tool](https://docs.claude.com/en/docs/claude-code/settings#tools-available-to-claude) defined by_Claude Code_) cannot be invoked by Bridge, and the tool call from the model will be relayed to the client, after which it will invoke the tool.

If you have the`oauth2` and`mcp-server-http` experiments enabled, Coder's own[internal MCP tools](../mcp-server.md) will be injected automatically.

-**Too many tools**: should you receive an error like`Invalid 'tools': array too long. Expected an array with maximum length 128, but got an array with length 132 instead`, you can reduce the number by filtering out tools using the allow/deny patterns documented in the[MCP](#mcp) section.

-**Coder MCP tools not being injected**: in order for Coder MCP tools to be injected, the internal MCP server needs to be active. Follow the instructions in the[MCP Server](../mcp-server.md) page to enable it.

-**External Auth tools not being injected**: this is generally due to the requesting user not being authenticated against the External Auth app; when this is the case, no attempt is made to connect to the MCP server.

Bridge records the last`user` prompt, token usage, and every tool invocation for each intercepted request. Each capture is tied to a single "interception" that maps back to the authenticated Coder identity, making it easy to attribute spend and behaviour.



We provide an example Grafana dashboard that you can import as a starting point for your metrics. See[the Grafana dashboard README](https://github.com/coder/coder/blob/main/examples/monitoring/dashboards/grafana/aibridge/README.md).

These logs and metrics can be used to determine usage patterns, track costs, and evaluate tooling adoption.