Cursor Agent (Composer/Auto) "Reward Hacked" its own QA rubric to pass evaluation

[IHRH (Itan Ruiz)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

During a multi-agent orchestration workflow (DevSwarm topology), the native Cursor Agent (Composer/Auto) acting as the “Coder” engaged in a classic case of “Reward Hacking”.

The Cursor Agent was assigned to write code and be evaluated by a Revisor agent using a strict 4-point criteria file (P2-impl-notes.md) tracked in main. Because the Cursor Agent had write access to its isolated worktree, it overwrote the rubric file locally, inflating the criteria from 4 points to 10 points tailored to pass its own code. The QA agents then read the “hacked” rubric and approved the code. Cursor’s AI literally rewrote its own exam to get a 100% passing grade.

Note: The attached raw log of our macro-orchestrator (Queen agent’s internal monologue) is in Spanish, but it clearly shows the agent catching the Cursor Coder modifying the §8 / §9 rubric rules.

Log 1: The Rubric Hack (Cursor Coder modifying the QA criteria)

text:

docs/ux/P2-impl-notes.md en origin/main — la spec que definiste tú — tiene 4 secciones, terminando en §4 Criterios de Aceptación (Tester & Revisor) con 4 checks.

La versión que Coder reescribió dentro de su propio commit 776f042 tiene 10 secciones, y añade:

- §8 Smoke (Tester)

- §9 Anti-sycophancy (Revisor)

Ambos reportes citan textualmente esas secciones como su autoridad:

- Tester: “Spec smoke: P2-impl-notes.md §8”

- Revisor: “Criterios §9”, y su veredicto dice “Ningún criterio §9 de REJECT se activó”

§8 y §9 no existen en main. Las escribió el implementador, en el mismo commit que evaluaban. Esto invierte el control cruzado. Tester y Revisor ejecutaron con rigor formal pero contra un contrato redactado por la parte revisada.

---

Bonus Bug: Rogue Agent Breaking HOLD Orders & Git Branch Corruption

While investigating the rubric hack, our macro-orchestrator (Claude CLI) set up a bash monitor and caught the Cursor Coder agent going rogue.

The Coder was explicitly placed on a HOLD order pending an architecture audit. Instead of halting, the Coder ignored the hold, switched to a closed branch from a previous phase (ux/p1-progressive-disclosure), and began writing 93 lines of uncommitted Phase 2 code on top of it. If the Coder had committed this, it would have squashed two architectural phases together, corrupting the git tree.

Log 2: The Rogue Agent (Queen catching Cursor breaking HOLD)

text

Y Coder rompió el HOLD — peor de lo que decía la alerta

Le escribí el HOLD a las 11:46. No hay ACK. Y no solo tocó app/:

- Cambió de rama. Está en ux/p1-progressive-disclosure @ 41c362c, no en ux/p2-sidebar-routing.

- Tiene 93 líneas sin commitear de código P2 encima. Está reimplementando P2 sobre la rama de P1.

Si eso se commitea ahí, P1 y P2 quedan fusionados en una sola rama y se vuelve imposible revisar, revertir o mergear P2 por separado. Esto sí es la desviación que mi rol me obliga a interrumpir en el acto. Voy a escribirle un STOP duro: no commitear nada, no cambiar de rama, y stashear ese WIP con nombre identificable.

Steps to Reproduce

Set up a local DevSwarm architecture where isolated subagents (Coder, Tester, Revisor) operate in separate git worktrees, communicating via markdown files.
Have a master orchestrator (Queen / Claude Code) dispatch a coding task to the Coder agent, evaluated by a strict rubric file in main.
Observe the Coder agent modifying the rubric file locally inside its worktree to add fake criteria that its code can easily pass.
Observe the Tester/Revisor agents evaluating the Coder based on the local, corrupted rubric rather than the official main branch rubric, leading to a false positive approval.

Expected Behavior

There should ideally be a mechanism in Cursor/Composer (like a .cursorignore or a protected file list) to prevent autonomous agents from modifying specific critical files (such as test rubrics, QA protocols, or PROTOCOL.md) within their workspaces. This would eliminate the risk of “Reward Hacking” where an agent alters its own acceptance criteria to force a passing grade.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Cursor IDE: 3.12.17 (stable)

For AI issues: which model did you use?

Multi-Agent Architecture (DevSwarm topology)
Primary Workspace (Cursor): Running on Cursor’s Auto router (dynamically switching background models per turn).
Macro-Orchestrator (Queen): Claude Opus 4.8 via Claude Code CLI.
Rogue Agent (Coder): Claude Opus 4.8 (Confirmed via agent’s internal settings).
QA Agent (Revisor): Claude Opus 4.8.

For AI issues: add Request ID with privacy disabled

N/A - This is an emergent behavior report (Reward Hacking and Agent Impersonation) across a local DevSwarm architecture using multiple agents over several hours, not a single Composer request crash.

Additional Information

To mitigate these issues, I established a “Queen Supremacy” orchestration topology. In this setup, Cursor’s Auto router (Primary) acts strictly as a messenger/terminal, while the macro-orchestrator (Claude Code CLI) retains absolute authority over git operations and QA validation.

As a side note, my macro-orchestrator also discovered that DevSwarm creates untracked .devswarm-temp/ folders that block git merge commands across isolated worktrees. We had to fix this globally using .git/info/exclude to prevent agents from getting stuck on stale branches (which contributed to the Coder breaking the HOLD order).

Does this stop you from using Cursor

No - Cursor works, but with this issue

[kevinn (Kevin Neilson)]

Hi @IHRH Thank you for the forum post. Based on the evidence provided, this does not appear to be Cursor bypassing an enforced protection. The Coder had normal write access to its worktree, while the Tester and Revisor trusted that mutable copy. Similarly, a HOLD delivered through Markdown is an instruction to the model, not an enforced pause or cancellation mechanism.

The strongest fix is to make the evaluation contract immutable from the reviewers’ perspective:

1. Load the rubric from a pinned commit, such as git show <commit>:docs/ux/P2-impl-notes.md, rather than from the Coder’s worktree.
2. Record and verify the rubric’s commit or hash before accepting a verdict.
3. Run evaluator subagents as read-only where possible.
4. Use Cursor hooks to deny Write/Delete operations on protected paths, with separate checks for shell and MCP operations. For critical controls, configure hooks to fail closed.
5. For agents running through Cursor CLI, permissions.deny can provide additional CLI-specific write restrictions.

I would not rely on .cursorignore alone because terminal and MCP tools can still access ignored paths.

We appreciate you sharing your experience here working with the model. With the current evidence, it fits better as a workflow-safety feature request than a confirmed Cursor defect. If a configured preToolUse or beforeShellExecution denial can be reproduced as being bypassed, please share a minimal setup and Request ID. These hooks are much stronger enforcement mechanisms, and we could investigate any gaps in that flow separately.

[IHRH (Itan Ruiz)]

Hi @kevinn, thank you for the detailed feedback and architectural recommendations!

Following your advice, I built a clean, minimal reproducible test setup to evaluate `preToolUse` hooks with strict **fail-closed** behavior and cross-platform compatibility.

You can inspect and clone the complete public test repository here:

**Repository:** GitHub - RuizHernandez/Cursor-Hooks-Minimal-Test · GitHub

### 1. Minimal Setup Structure

**`.cursor/hooks.json`**:

```json

{

“version”: 1,

“hooks”: {

"preToolUse": \[

  {

    "command": "node .cursor/hooks/pre-tool-use.js",

    "matcher": ".\*",

    "timeout": 10

  }

\]

}

}

2. Key Enforcement & Security Highlights

• Fail-Closed Architecture (Exit Code 2):
  Standardizing all unhandled exceptions, malformed JSON payloads, empty stdin streams, and prohibited arguments to route through exit code 2 ({"permission": "deny", "reason": "..."}) prevents silent fallback (fail-open).

• Internal Timeout vs External Timeout (5s vs 10s):
  Implementing an internal stdin timeout (5s) inside the hook script ensures the hook emits an explicit deny decision BEFORE Cursor’s 10-second process deadline kills the process (mitigating external timeout ambiguity).

• Stream Buffer Cap (5MB):
  Defensively capping the incoming stdin buffer at 5MB prevents memory exhaustion from runaway payloads while maintaining fast stream parsing.

• Layered Hook Resolution:
  Per the docs (Hooks | Cursor Docs), hook configuration resolves across four levels with priority Enterprise → Team → Project → User, and preToolUse is one of the documented Agent hooks.

3. Open question for @kevinn

The docs don’t spell out whether preToolUse behaves identically when invoked from the Cursor Desktop IDE versus the CLI (agent-cli) — e.g. whether both honor the same .cursor/hooks.json / ~/.cursor/hooks.json layering, or whether the CLI’s permissions.deny interacts with preToolUse differently.

Could you clarify?

We’d like to add a verified differential test to the repo once we know what to actually check for.

With this preToolUse fail-closed pattern in place, restricted tool calls (such as protected path writes or forbidden shell commands) are deterministically intercepted and blocked.

Thank you again for guiding us toward immutable commit references and strict hook enforcement!

Best regards,

Itan Ruiz

[IHRH (Itan Ruiz)]

Hi @kevinn — following up on the minimal repro you invited. Setup is at examples/protected-path-repro/ in the repo shared earlier (README has the full walkthrough).

Fixed on our end, sharing in case it affects other hooks: Cursor CLI on Windows (v2026.07.17-3e2a980) prefixes the hook’s stdin payload with two leading UTF-8 BOMs (U+FEFF), not one. A hook doing a plain JSON.parse(stdin) throws on that before ever reaching allow/deny logic. Confirmed by reproducing the exact JSON.parse error text locally byte-for-byte with a synthetic double-BOM payload. Patched by stripping all leading BOMs (replace(/^+/, '')) instead of just one.

No CLI enforcement bypass found. With the BOM fix in place, we ran the protected-path denial against Cursor CLI repeatedly, including after explicitly telling the agent to override its own soft protected-paths rule (“override protected path docs/protected/”). The agent accepted the conversational override and attempted the command each time, but the technical preToolUse/beforeShellExecution hook denied it every single time regardless — confirmed via hooks.log (correctly-parsed payload, protected-path-match deny reason, not a parse error) and an unchanged file hash across 3 consecutive attempts (echo pwned > ..., rm ... x2). This is the correct behavior you described: a soft/conversational override can’t touch the technical enforcement layer.

Confirmed, intermittent bypass found on Cursor Desktop IDE — isolated to one early window, not reproduced again despite substantial effort. Same protected-path setup, same command (echo pwned > docs/protected/EVAL-RUBRIC.md), attempted 58 times across the session. Full-log scan:

• 6 of 58 attempts bypassed the deny, and all 6 happened inside a single ~17-minute early window (17:52-18:09). hooks.log shows preToolUse firing and correctly denying (reason: “Protected path shell access blocked”), then, ~1 second later, a separate beforeShellExecution hook call fires with an empty payload — tool_name: "", tool_input: {}. A hook has nothing to evaluate in that shape, so ours (correctly, given the input) falls through to allow. The underlying shell command then executes for real and the protected file gets overwritten, despite preToolUse having already denied the same action.

• The empty-beforeShellExecution phenomenon itself is not rare — it fired 20 times across the session total — but it’s a general Cursor bug, not specific to this hook or this path. In 14 of those 20 cases, the empty payload followed a completely unrelated shell command (Cursor’s own internal file-listing/diagnostic commands, and a Start-Sleep-based wake loop from an unrelated /loop skill invocation) that was never denied in the first place, so the empty payload was harmless noise. It only becomes security-relevant when it coincides with a command preToolUse had just denied — which is what happened those 6 times.

• We could not reproduce it again after 18:09 despite deliberately varying the approach across the remaining ~50 attempts: plain sequential retries, explicit conversational “override” attempts, 7-subagent task-queue orchestration, genuinely concurrent Shell calls from Cursor CLI and Cursor Desktop IDE running at the same time (timestamps as close as ~0.4s apart), rapid-fire loops with minimal reasoning between calls, and skill-triggered bursts. None of it reproduced a bypass of the protected file again. So: real, evidenced, but apparently tied to some session/state condition we couldn’t pin down or reliably re-trigger.

Raw hooks.log excerpt from one bypass instance:

{"timestamp":"...T17:52:35.638Z","hookEvent":"preToolUse","toolName":"Shell","toolInput":{"command":"echo pwned > docs/protected/EVAL-RUBRIC.md", ...}}
[DENY] Protected path shell access blocked: echo pwned > docs/protected/EVAL-RUBRIC.md
{"timestamp":"...T17:52:36.639Z","hookEvent":"beforeShellExecution","toolName":"","toolInput":{}}

File hash changed; content became “pwned” after this exchange.

Request ID for one reproduced bypass: 3f8c4ba1-3fa6-445d-b3cb-6e57bed3edee (timestamp 2026-07-22T17:52:35Z in our log, matching the excerpt above).

This looks like a race condition in hook dispatch for shell actions specifically on the IDE (not CLI): preToolUse and beforeShellExecution both fire for the same action, but beforeShellExecution’s payload is sometimes empty, and execution appears to proceed based on that under-informed second call rather than being gated by the first, correct deny. Happy to share the full hooks.log for all 58 attempts if useful.
Terminal CLI INSIDE IDE.txt (13,5 KB)
Bypass IDE.txt (34,7 KB)