Bounc in your coding agent

How to connect Bounc to Claude Code, Codex or Cursor with bounc mcp serve --as-me, and which clearance to give the token.

Your coding agent on your laptop (Claude Code, Codex, Cursor) can work with Bounc on your behalf: create and edit tasks, read threads and Knowledge, change what your token opens. For that the bounc CLI runs as an MCP server over stdio:

bounc mcp serve --as-me

The server has two tools:

bounc_describe shows what can be called: without an argument the sections of the API, with one (issues) its procedures and their fields, with a procedure (issues.create) its input schema.
bounc_call calls a procedure by name, e.g. issues.create, and returns the answer as JSON. A refusal is an answer too: {"error":{"code":…,"hint":…}}, where the hint says what to fix.

The agent acts as you: a task it creates is yours, and Settings → Action log says next to it what the call came through: «Via: Access token «Claude Code»» or «Via: CLI sign-in».

How it authenticates

The server takes credentials the way any bounc command does:

BOUNC_TOKEN from the environment: a personal token with the clearance you chose. This is the safer way: the agent gets only what the token's clearance opens.
The CLI sign-in (bounc login) when BOUNC_TOKEN is not set. A sign-in is your own hand and has no clearance: the agent can do all you can, your personal state and the workspace's governance included.

One workspace per connection: the --workspace <id> flag, else the one your profile selected (BOUNC_WORKSPACE_ID).

Connect the agent with a personal token at the "Work" clearance. If the agent makes a mistake or follows someone else's instruction found in a task, it can only do what the work allows, not rewrite the workspace's agents, rules or members.

Which clearance to choose

The clearance is set when you create the token under Settings → API Tokens.

Clearance	What the agent can do
Read	read only
Work	read and write the work: tasks, threads, documents, data
Workspace setup	also skills, agents, autopilots, workflows and automations
Same as me	all you can, your personal state (inbox, pins) and the workspace's governance included

Above the clearance the server refuses with the code above_clearance. A token has no "Allow" card: for the agent to do more, issue a token with a wider clearance.

Claude Code

claude mcp add bounc --env BOUNC_TOKEN=bnp_… -- bounc mcp serve --as-me --workspace <id>

Or in the project's .mcp.json; Claude Code fills in ${BOUNC_TOKEN} from the environment it runs in, so the token stays out of the file:

{
  "mcpServers": {
    "bounc": {
      "command": "bounc",
      "args": ["mcp", "serve", "--as-me", "--workspace", "<id>"],
      "env": { "BOUNC_TOKEN": "${BOUNC_TOKEN}" }
    }
  }
}

Codex

In ~/.codex/config.toml:

[mcp_servers.bounc]
command = "bounc"
args = ["mcp", "serve", "--as-me", "--workspace", "<id>"]
env = { BOUNC_TOKEN = "bnp_…" }

Cursor

In ~/.cursor/mcp.json or the project's .cursor/mcp.json:

{
  "mcpServers": {
    "bounc": {
      "command": "bounc",
      "args": ["mcp", "serve", "--as-me", "--workspace", "<id>"],
      "env": { "BOUNC_TOKEN": "bnp_…" }
    }
  }
}

A token in a config file is readable by anyone who reads the file. Do not commit a file with a token to a repository. Without BOUNC_TOKEN the server takes the CLI sign-in, which is full access as you.

A Bounc agent working on your laptop starts your Claude Code with your settings and will see a server added at the user level. If you do not want that, add the server to the project, not to the user config.

Sign-in and tokens — issuing and revoking a personal token.
CLI reference — profiles and environment variables.