> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect coding agents

> Wire Claude Code, Codex CLI, or Cursor to your workspace over MCP — including how to pick the workspace when you belong to several.

Your local coding agent can operate the platform directly: create and invoke agents, read runs,
search knowledge, manage workflows. This page covers connecting Claude Code, Codex CLI, or Cursor,
the two authentication modes you might meet, and the one thing that needs care if you belong to more
than one workspace. Find it under **Settings → Connect coding agents**.

<Note>
  This surface is enabled per workspace. If the settings tab is not there, it has not been turned on
  for yours.
</Note>

## Connecting

The settings tab shows one card per supported agent — **Claude Code**, **Codex CLI**, and
**Cursor** — each with the command or link that connects it, plus a manual configuration snippet if
you would rather edit your own config file.

What the card gives you depends on how your deployment authenticates:

| Mode                    | What connecting looks like                                                                                                                       |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **OAuth available**     | The command needs no credential. The agent completes sign-in on first use.                                                                       |
| **OAuth not available** | The command and the manual snippet carry a placeholder for an [API key](/security-and-governance/identity-and-access/api-keys) that you fill in. |

<Warning>
  Cursor's deep link cannot carry a header, so on a deployment without OAuth the link alone is not
  authenticated. Use the manual configuration snippet on that card and add your key there instead.
</Warning>

## Choosing a workspace

If you belong to exactly one workspace, there is nothing to configure — the connection resolves to
it.

If you belong to several, the workspace is chosen **on the connection**, because MCP gives a server
no way to retarget a client mid-session. So you configure **one server entry per workspace**, each
carrying its own workspace, and pick which workspace you are working in by choosing which entry to
talk to.

There are two equivalent ways to say which:

```text theme={null}
https://<your-workspace-host>/internal/mcp?account=<workspace>
```

or a header, for a client that can set one:

```text theme={null}
X-AgentOps-Account: <workspace>
```

The header wins if both are present. The value is the workspace's slug or its id.

| What you pass                                                   | What happens                                                |
| --------------------------------------------------------------- | ----------------------------------------------------------- |
| Nothing                                                         | Resolves to your oldest membership — the historical default |
| A workspace you are an active member of                         | Resolves to that workspace                                  |
| A workspace you are not an active member of, or an unknown name | Rejected, never silently re-scoped to a different one       |

<Tip>
  Selection is silent by design, so ask rather than assume: the **`whoami`** tool answers which
  workspace the connection is actually operating in, along with every workspace you belong to. It is
  worth running once after adding a second entry.
</Tip>

## What your assistant can do

The connection serves the platform's own [MCP server](/developer-tools/mcp-server), so everything
there applies — including that a connection can be scoped to particular toolsets, and that every
tool call is authorized against the same capability as its HTTP equivalent.

That last point is the one worth internalizing: **your assistant acts as the identity the connection
authenticated with.** It holds that identity's permissions, its actions are attributed to it, and the
governed ones land in the [audit log](/security-and-governance/controls/audit-log) under its name —
you, for an OAuth sign-in or a personal key; the service account, when the connection uses one.

## Next steps

<CardGroup cols={2}>
  <Card title="MCP server" href="/developer-tools/mcp-server">
    The toolsets available, and how to narrow a connection.
  </Card>

  <Card title="API keys" href="/security-and-governance/identity-and-access/api-keys">
    Issuing the key a non-OAuth deployment needs.
  </Card>

  <Card title="Accounts & members" href="/security-and-governance/identity-and-access/accounts-members">
    Belonging to more than one workspace.
  </Card>

  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    Where your assistant's governed actions are recorded.
  </Card>
</CardGroup>


## Related topics

- [Interfaces](/get-started/interfaces.md)
- [MCP Gateway](/manage-your-agents/build/mcp-gateway.md)
- [Chat & history](/manage-your-agents/run/chat-history.md)
- [MCP server](/developer-tools/mcp-server.md)
- [Overview](/developer-tools/overview.md)