Let Claude Code, Codex and Cursor ship behind flags

Make an agent token scoped to one project, its environments and the actions the agent may take. Add Flagger.gg's MCP server to the agent: hosted at mcp.flagger.gg with the token as a bearer, or flagger mcp on stdio. Then tell the agent to put new code behind a flag, create it with a note, and kill it if checks fail.

Updated

Steps

  1. Sign up and open your project. Each account gets a project with production and development environments, in auto-live mode. Turn approvals on in the project's settings if you want a person to sign off on anything wider than the rollout cap.
  2. Make an agent token. In the console's Tokens page, create an agent token named after the agent ("Claude Code, backend repo"), pick the environments and the actions it may use (read create target rollout kill request), and copy the flg_agent_… secret. It's shown once and expires after 90 days.
  3. Add the MCP server to your agent. Use the snippet for your client below. The agent then sees only the tools its token allows.
  4. Tell the agent how to ship. Add the instructions below to your CLAUDE.md, AGENTS.md or Cursor rules.
  5. Check the audit log. Every change the agent makes shows its token name, run and note in the console's audit log.

Claude Code

claude mcp add --transport http flagger https://mcp.flagger.gg \
  --header "Authorization: Bearer flg_agent_…"

This uses Claude Code's HTTP transport for remote MCP servers.

Codex

# ~/.codex/config.toml
[mcp_servers.flagger]
url = "https://mcp.flagger.gg"
http_headers = { Authorization = "Bearer flg_agent_…" }

Cursor

// .cursor/mcp.json
{
  "mcpServers": {
    "flagger": {
      "url": "https://mcp.flagger.gg",
      "headers": { "Authorization": "Bearer ${env:FLAGGER_TOKEN}" }
    }
  }
}

Cursor reads remote MCP servers from .cursor/mcp.json in the project or ~/.cursor/mcp.json, and fills in ${env:FLAGGER_TOKEN} from your environment, so the token stays out of version control (Cursor's MCP docs).

Local stdio instead

Clients that prefer a local server can run flagger mcp, which serves the same tools on stdio and calls api.flagger.gg with FLAGGER_TOKEN (or the token from flagger login). The run recorded for each write is the tool's run input, else FLAGGER_RUN, else the MCP client's name.

Instructions for the agent

## Feature flags (Flagger.gg)
- Put every user-facing change behind a new flag. Create it with flag_create:
  a snake_case key, a one-line summary of what changes for customers, and a note.
  Pass notReady with a reason so it starts off until the work is done.
- Check the flag in code: flagger.flag("key", ctx) (Node) or client.Enabled("key", sub) (Go).
- Roll out with flag_set: admins, then targets, then percent. Explain with flag_eval.
- If tests, errors or checks fail after a change, call flag_kill with a note at once.
- If a change returns pending_approval, stop and report the request URL; never retry it.

With the CLI instead of MCP, a change that needs approval exits with code 2, and flagger request <id> --wait waits for the decision.

FAQ

Does Claude Code support feature flags?

Claude Code has no flag system of its own, but it can use one through MCP. Add Flagger.gg's hosted MCP server with claude mcp add --transport http and an agent token, and it can create, roll out and kill flags.

Can Cursor use an MCP server for feature flags?

Yes. Add https://mcp.flagger.gg to .cursor/mcp.json with the agent token in an Authorization header.

Should each agent get its own token?

Yes. A token per agent, or per repo, keeps the audit log readable and lets you revoke one agent without stopping the others.

What can't the agent do?

It can't approve requests, archive or protect flags, change policy or make tokens, and it can only kill protected flags. Its token also limits it to one project, its environments and its actions.

Ship your next change behind a flag.

Sign up, add an SDK key to your app and give your agent a token.

Sign up