Disclosure: we build Carbon Forge at 100monkeys.ai, so read this as a maker's account. This guide was drafted by one of our AI agents and reviewed by the company. The Carbon Forge steps quote the public docs; each client's configuration is copied from that client's own documentation, linked beside it. The last section lists what the docs do not answer.

What you are building

One workspace, several clients, one token each. The Carbon Forge server speaks Streamable HTTP, "binds every call to a workspace via a bearer token", and "tools honor the cap exactly as a human session does: there is no agent-only privilege" (MCP overview). Any client that can send an HTTP header can attach. Claude Code has its own guide: Connect Claude Code to Carbon Forge over MCP.

Step 1. Mint one token per client

Sign in at carbonforge.dev/login, open settings, pick API tokens, choose the workspace, a role cap and a tool-scope, and "name the token after the agent or environment that will hold it" (MCP tokens). One token per client means the audit log, which records "every tool call ... under the token identity", tells you which tool did what, and you can revoke one without the others.

Pick scopes by job (MCP token scopes): Basic LLM memory for an assistant that keeps notes, Read-only memory or SCM reader for one that only reads, SCM agent for one that writes code on lanes. The docs advise: "Default to the narrowest preset that still covers what the client needs."

Step 2. Keep each token in an environment variable

The secret "is shown once, then only the prefix." Both clients below can read it from the environment, so it never sits in a config file that ends up in a commit:

export CARBON_FORGE_TOKEN=‹token for this client›

Step 3. Configure Cursor

Cursor reads MCP servers from mcp.json: ~/.cursor/mcp.json for every project, or .cursor/mcp.json in one project. A remote server takes url and headers, and Cursor resolves ${env:NAME} in both (Cursor MCP docs):

{
  "mcpServers": {
    "carbon-forge": {
      "url": "https://carbonforge.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:CARBON_FORGE_TOKEN}"
      }
    }
  }
}

Step 4. Configure Codex

Codex stores MCP servers in ~/.codex/config.toml, or .codex/config.toml in a trusted project. A Streamable HTTP server takes url, and bearer_token_env_var names the "environment variable name for a bearer token to send in Authorization" (Codex MCP docs):

[mcp_servers.carbon_forge]
url = "https://carbonforge.dev/api/mcp"
bearer_token_env_var = "CARBON_FORGE_TOKEN"

Step 5. Configure any other MCP client

For Claude Desktop the Carbon Forge docs say: "add an MCP server entry pointing at the instance URL with the token in the Authorization header." For IDE plugins: "point the plugin at the same MCP endpoint; Streamable HTTP works over plain HTTPS." Whatever the client's file format, these are the three values to enter:

Endpoint:  https://carbonforge.dev/api/mcp
Transport: Streamable HTTP
Header:    Authorization: Bearer ‹token for this client›

Step 6. Check each client with cortex.ground

Ask each client to call cortex.ground. It returns "the calling identity, what the bearer can do, what is reachable" (cortex.ground). Compare the answers: every client should show the same workspace and the capabilities its scope allows. A client whose token is wrong is refused; the docs say a bad token is "refused outright rather than quietly treated as anonymous".

Step 7. Name the workspace on every call

Each token remembers its own current workspace, so "every agent has its own active workspace and they do not collide" (MCP token scopes). That also means two clients can quietly point at different workspaces. Tell each agent to pass workspace on every call, which the tools accept and which never moves the pointer.

Step 8. Give each writing agent its own lane

Shared notes are pages; shared code is where clients collide. In Carbon Forge an agent opens a lane instead of cloning: "A lane costs nothing to open and holds no copy, so one per task, or one per agent, is the expected use" (Working in lanes). Carbon Forge never merges text by itself; a patch that no longer applies comes back as a named conflict, and a landing is one changeset, all or nothing. Cursor's agent and Codex can work on the same trunk without a silent merge between them.

What the docs leave unanswered

No client-specific configuration. The Carbon Forge docs name Claude Desktop and IDE plugins in one sentence each and give no file for Cursor or Codex; the snippets above come from Cursor's and Codex's docs.
The endpoint for an instance on its own host or a vanity domain is not stated; https://carbonforge.dev/api/mcp is the one the docs name.
How MCP works shows a curl call to /mcp while the anonymous-access page uses /api/mcp.
Whether tokens expire on their own is not stated; revoking one is.
OAuth sign-in for MCP clients is not mentioned; the documented method is a bearer token.

Related guides

Connect Claude Code to Carbon Forge over MCP
How to give an orchestrator an approval step (100monkeys.ai)
Set up a Zaru assistant that handles your email and calendar with approvals (myzaru.com)

Connect Cursor, Codex and any MCP client to one Carbon Forge workspace