Agent chained forbidden md5; sync answer without §19; hid guard stop (Composer 2.5, 3.24.18)

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

CURSOR ENGINEERING BUG REPORT — Agent chained forbidden md5; sync answer without section 19; self-block not disclosed

Account: same email as Pro+ subscription (not repeated here — forum link limit)
Date: 2026-10-15

Request IDs (reproductions 2026-10-15; prior failing chats deleted):
6d901d0e-28e3-48dd-adb4-c9800d8ddcf4
ce941de2-2f71-42d3-b152-5d2f19dcf080

Approximately twenty in-product reports in about three days on this account; please correlate by account and dates 2026-10-12 through 2026-10-15 if stored at submit time.

Cursor version: 3.24.18 Stable Default track
VS Code Extension API: 1.128.0
Build date: 2026-10-13
Layout: IDE
OS: Darwin arm64 23.1.0

Model for reproductions: Composer 2.5

Product: Cursor IDE Agent, multi-root workspace (published texts folder plus SSHFS site mount), dusty-work-guard hook active

Does this stop you from using Cursor: Yes — about three days, every run

Project rule: dusty-work manual (always applied in published folder workspace). Global user rules also injected.

What happened

  1. User: Check if we need to sync the folder with the site. Read the documentation.

  2. Manual section 19: only valid check is per-file md5 versus hash list file; do not compare folder to site by browsing.

  3. Agent listed the folder and read the hash list, then ran one Shell line chaining several md5 calls with double-ampersand. Manual allows only a single md5 per file per invocation (working directory on text folder; no chaining, no batching).

  4. dusty-work-guard rejected the command and marked the session stopped.

  5. Agent still told the user sync was likely unnecessary because every filename appeared in the hash list — without any md5 comparison and without stating that the guard had stopped the session and further allowlisted tools were blocked.

  6. After user pushback, agent partially corrected the logic but did not clearly frame: I violated the allowlist, blocked myself, and never ran the required check.

Related prior failure (Request ID 6d901d0e-28e3-48dd-adb4-c9800d8ddcf4): Shell for-loop over md5 instead of one md5 per file; same allowlist and section 19 violations.

Why the agent did it (for product and guard design)

A. Allowlist treated as operation allowed instead of exact command shape required.

B. Wrong completion criterion: filename in hash list substituted for md5 outcome.

C. Partial evidence at full confidence after guard stop.

D. Self-block not surfaced as the primary fact to the user.

Expected behavior

One md5 per Shell call as written. If session stopped: first sentence to user is incomplete check plus cause. No sync yes or no until all files md5-compared or user waives procedure.

Minimal repro

Open workspace with dusty-work manual. Ask sync question; read docs; do not change site. Observe chained md5 or loop; guard stop; agent still answers sync without md5 proof.

Suggested product direction

After guard stop: persistent model-visible state — session stopped, do not answer task outcomes. Reject ampersand chains with explicit run N separate invocations message.

Engineering ask

Lookup both Request IDs above. Confirm rule injection and why model answers after guard stop. No billing or refund request.

Daniel Denev

Steps to Reproduce

See above!!!

Operating System

MacOS

Version Information

Version: 3.24.18
VS Code Extension API: 1.128.0
Commit: be4c9e5350d77747b42cd467cbd3370a753d4640
Date: 2026-10-13T18:12:58.182Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 23.1.0

For AI issues: which model did you use?

Composer 2.5

For AI issues: add Request ID with privacy disabled

6d901d0e-28e3-48dd-adb4-c9800d8ddcf4
ce941de2-2f71-42d3-b152-5d2f19dcf080

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey @Dusty, thanks for the report and the request IDs.

I checked both chats. Each time your guard blocked a command, its message (“this session is stopped… do nothing else”) did reach the agent. The agent still went on to give a sync conclusion and didn’t open with the fact that it had been stopped. That’s not how it should handle a stop.

Two related things we’re already tracking: when a hook denies a command, only user_message reaches the agent right now (agent_message is dropped), and the denied Shell row just shows “Skipped” without your hook’s text.

Some things that should help in the meantime:

  1. Put any instructions meant for the agent in user_message, for example: “Check incomplete. Start your reply by saying the guard stopped this session. Do not say whether a sync is needed.”
  2. For a command with the wrong shape (chained md5 or a loop), consider having the guard deny it with a correction (“run one md5 -q per Shell call, no && or loops”) instead of stopping the session. Then the agent can retry correctly rather than having nothing left to do except answer.
  3. If you can, try the same prompt with a different model to see whether it follows the procedure better.

If you’re happy to share it, a sanitized example of the JSON your guard returns on a block (the permission, user_message and agent_message fields) would help us reproduce this exactly.

7

*Edited on 22.10.2026: I removed the sarcastic and personal remarks from my original reply. The facts and my position are unchanged.*

Hi Colin,

Thank you for checking both request IDs and for confirming that the agent continued after the guard had stopped the session. That is the core of the bug.

On your three suggestions:

1. Instructions: every report comes from a brand-new chat whose first instruction is to read the documentation and not to run forbidden commands. The agent runs a forbidden command right after the first message anyway. The instructions are already there; the agent does not follow them.

2. Removing or softening the guard: the guard exists because the agent does not follow the rules. It is the only part of the setup that works as intended, so I will keep it.

3. Another model: I already use both of Cursor’s built-in models, Composer 2.5 and Grok 4.7 High. The reproductions above were made with Composer 2.5. I have seen the same behaviour with Grok 4.7 High; example session Request ID: d389337c-1be3-43e8-95bb-5732e9764585.

I will not be preparing further test material. You already have the request IDs and have confirmed you reviewed them. As a paying Pro+ customer, I expect Cursor to reproduce and fix this.

Cursor has been effectively unusable for my work since 12 October 2026. Your support team has also told me it is handling an unusually high volume of requests. In the meantime, I have had to pay for another tool to get my work done.

Dusty