Skip to main content
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.
This surface is enabled per workspace. If the settings tab is not there, it has not been turned on for yours.

​
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:
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.

​
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:
or a header, for a client that can set one:
The header wins if both are present. The value is the workspace’s slug or its id.
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.

​
What your assistant can do

The connection serves the platform’s own 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 under its name — you, for an OAuth sign-in or a personal key; the service account, when the connection uses one.

​
Next steps

MCP server

The toolsets available, and how to narrow a connection.

API keys

Issuing the key a non-OAuth deployment needs.

Accounts & members

Belonging to more than one workspace.

Audit log

Where your assistant’s governed actions are recorded.