Skip to main content
When you run ironbee install in a project where Cursor is detected, IronBee writes the hooks, rules, and tools Cursor needs to verify your agent’s work. The integration mirrors Claude Code, with a few Cursor-specific details, including one manual step to activate the MCP server.

​
What gets installed

These are merged into your existing Cursor config, not overwritten.
Unlike Claude Code and Codex, Cursor doesn’t use a verifier sub-agent - the main agent drives the devtools tools directly. (Cursor’s sub-agents run in a separate conversation that can’t share the verification session, so there’s nowhere to delegate to.) The verification.model setting is therefore a no-op for Cursor.

​
Activate the MCP server

Cursor sometimes doesn’t pick up MCP servers added via mcp.json automatically. After installing, you usually need to activate it by hand.
After running ironbee install:
  1. Restart Cursor so it loads the new hooks and MCP config.
  2. Go to Settings → Tools & MCP and confirm the ironbee-devtools server is listed and on (it carries the tools for every cycle you enabled).
  3. If the server shows as enabled but its tools aren’t available, toggle it off and back on.
This is a known Cursor limitation: MCP servers added via config sometimes need a manual nudge.

​
Slash commands

The /ironbee-verify command from Claude Code is available in Cursor too:
  • /ironbee-verify: run a verification cycle for the current changes. You can pass a custom scenario - inline text or a path to a scenario file - that defines exactly what to verify; when supplied it replaces the default “exercise the changed paths” flow. An optional leading fix switches it from the default verify-only behavior into a fix-and-re-verify loop - see Verify-only vs. fix mode.
See Claude Code → Slash commands for the full breakdown; it behaves the same in Cursor, except Cursor’s main agent runs the verification itself rather than delegating to a sub-agent. The same goes for /ironbee-issue-track when an issue tracker is connected.
Cursor’s CLI can try to hand an IronBee skill to a sub-agent via its Task tool - but a Cursor sub-agent runs in a separate conversation that can’t share the verification session, so its evidence would silently never register. IronBee installs a hook that denies exactly those delegations (your own unrelated sub-agents pass through), keeping the verify, scenario, and issue-track skills on the main agent where their evidence counts.

​
How verification is enforced

Cursor’s stop hook can’t hard-deny completion the way Claude’s can, so IronBee uses Cursor’s followup_message mechanism: when verification fails, it auto-submits a new prompt that pushes the agent back into the verification loop, mechanically preventing the task from finishing until it passes (up to Cursor’s loop_limit, default 5).
Restart Cursor after installing, and remember the MCP activation step above; without it the agent won’t have the devtools tools it needs to verify.
Cursor can also power IronBee’s LLM suggestions - the s “suggest” key in the install platform picker and the ironbee checks suggest command - by running a one-shot headless prompt via cursor-agent. When Claude Code or Codex is also present, IronBee prefers those (claude > codex > cursor).

​
What Cursor sessions ship

Cursor sessions ship the same events as Claude Code and Codex - session lifecycle, agent turns, tool calls, file changes, verification cycles, and verdicts - through the Collector. IronBee also does one read-only lookup in Cursor’s local SQLite store (state.vscdb): the signed-in user’s cached email, so events can be attributed to you in the Console. Nothing is ever written there, and the read degrades silently when no SQLite driver is available. Point it elsewhere with IRONBEE_CURSOR_USER_DIR if your Cursor install isn’t in the standard per-OS location.
IronBee 0.42 removed the Cursor usage-API integration (ironbee cursor api-access) that used to enrich sessions with per-request tokens and cost from api2.cursor.sh, together with the rest of the insights layer. The cursor.apiAccess.* config keys are inert and can be dropped from your config files.

​
What’s next?

Claude Code

The same integration for Claude Code.

Codex

The same integration for Codex.