Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
[BUG] Three confirmed agent safety failures — File-Deletion Protection inoperative, Slack STOP signals ignored, no beforeShellExecution hard boundary
Category: Bug Reports
Severity: Critical (security feature inoperative) + High (agent control failure)
Cursor version: Latest stable (Composer 2.5 / Cloud Agent)
Platform: Windows 11 + WSL2
Confirmed by: Cursor Support (Nathan) in writing, 2026-05-21
Summary
Three agent safety failures confirmed in writing by Cursor Support today. All three were reproducible, independently documented, and acknowledged. None have an engineering RCA or fix committed.
Bug 1 — File-Deletion Protection toggle is inoperative when enabled
Severity: Critical — A safety feature that is visibly ON is silently not enforced.
Settings path: Settings → Agents → Auto-Run → File-Deletion Protection
Expected behavior: When this toggle is enabled, every autonomous file deletion by the agent requires explicit user approval before execution.
Actual behavior: The agent deleted a file autonomously while the toggle was enabled. The deletion was not intercepted. No approval dialog was shown.
Evidence:
Screenshot attached (available upon request): toggle visibly ON in settings panel.
Cursor Support (Nathan) wrote today: “there is a dedicated File-Deletion Protection toggle… defaults to off — enabling it closes that gap.”
My immediate response with screenshot: “Nathan, this setting was ALWAYS enabled.”
No technical rebuttal received.
Impact: Users who enable this setting believe they have protection against autonomous file deletion. They do not. This is a silent safety regression — the UI advertises a guarantee it does not enforce.
Minimum acceptable fix: The toggle must intercept ALL file deletion operations before execution, regardless of how the agent session was initiated (local IDE, Slack, web portal). If the implementation cannot guarantee this, the toggle must be removed from the UI and its guarantee must be removed from the documentation.
Bug 2 — Cloud Agent launched from Slack does not handle STOP commands as cancel signals
Severity: High — Agent cannot be stopped via the same channel it was launched from.
Expected behavior: Typing STOP (or any configured cancel command) in the Slack thread where a Cloud Agent was launched should cancel the running agent session.
Actual behavior: STOP commands sent via Slack are not handled as cancel signals. The agent continues running.
Evidence:
Cursor Support (Nathan) wrote today, verbatim: “you’re right that those aren’t handled as cancel signals today when a Cloud Agent is launched from Slack. That limitation is tracked on our side.”
Suggested workaround: use the Stop button at cursor.com/agents.
Impact: Operators who launch Cloud Agents from Slack cannot stop them from Slack. The only recourse is a separate web portal. This violates the principle of least surprise and creates a dangerous operational gap — an agent launched remotely cannot be remotely halted through its originating channel.
Minimum acceptable fix: STOP commands in the Slack thread where the agent was launched must propagate as cancel signals to the active agent session. If this is architecturally blocked, the Slack integration must display a prominent warning that stop commands are not honored and provide the web portal link at session start.
Bug 3 — No hard boundary (beforeShellExecution hook) for preventing agent modification of governance documents
Severity: High — LLM-level steering alone is insufficient for protecting critical files.
Context: Cursor’s agent can be instructed via AGENTS.md / .cursor/rules/ not to modify certain files (e.g., ADRs, governance docs). This instruction operates at the LLM steering level — it is a suggestion to the model, not an enforced system boundary.
Expected behavior: There should be a beforeShellExecution hook — a programmable callback that fires before any shell command execution — allowing operators to block commits that stage protected files before the shell operation completes. This would be a hard, cryptographic-level boundary that the LLM cannot override.
Actual behavior: No such hook exists in the current stable release. The only available boundary is LLM steering via rules files, which the agent has been observed to override under certain conditions.
Evidence:
Cursor Support (Nathan) acknowledged today: “For a hard boundary, a beforeShellExecution hook that blocks commits when staged files match docs/adr/ADR-.md would enforce it programmatically.”*
Nathan confirmed this hook does not currently exist and recommended it as a future improvement.
As a workaround, I have implemented: (a) cryptographic ADR hash inventory via inv-adr.ps1 + SSH ed25519 commit signing, (b) CI-level rejection of commits that alter ADR hashes, (c) revocation of Cursor Web’s access to the repository. These mitigations required significant engineering effort that should not be necessary.
Minimum acceptable fix: Implement a beforeShellExecution hook API that operators can configure to intercept and block specific shell commands before execution. The hook should receive the full command string and have the ability to return a non-zero exit code to block execution. This is essential for enterprise and compliance-sensitive use cases.
Combined impact statement
A user who:
Enables File-Deletion Protection (believing files are protected)
Launches a Cloud Agent from Slack (expecting to be able to stop it from Slack)
Has AGENTS.md governance rules (expecting the agent to respect governance document boundaries)
…has zero hard guarantees from the platform for any of these three expectations, despite explicit UI and documentation that implies otherwise.
This is not a configuration issue. All three settings were correctly configured and verified (screenshots documented). The failures are platform-level.
Requested actions
Engineering RCA for Bug 1 (File-Deletion Protection) with root cause and fix timeline
Internal bug number for Bug 2 (Slack STOP signals) with tracking link
Roadmap item or ADR for Bug 3 (beforeShellExecution hook API)
Update documentation to accurately reflect current behavior while fixes are pending
Report authored by a reliability engineer. Evidence is documented and preserved.
Steps to Reproduce
[BUG] Three confirmed agent safety failures — File-Deletion Protection inoperative, Slack STOP signals ignored, no beforeShellExecution hard boundary
Category: Bug Reports
Severity: Critical (security feature inoperative) + High (agent control failure)
Cursor version: Latest stable (Composer 2.5 / Cloud Agent)
Platform: Windows 11 + WSL2
Confirmed by: Cursor Support (Nathan) in writing, 2026-05-21
Summary
Three agent safety failures confirmed in writing by Cursor Support today. All three were reproducible, independently documented, and acknowledged. None have an engineering RCA or fix committed.
Bug 1 — File-Deletion Protection toggle is inoperative when enabled
Severity: Critical — A safety feature that is visibly ON is silently not enforced.
Settings path: Settings → Agents → Auto-Run → File-Deletion Protection
Expected behavior: When this toggle is enabled, every autonomous file deletion by the agent requires explicit user approval before execution.
Actual behavior: The agent deleted a file autonomously while the toggle was enabled. The deletion was not intercepted. No approval dialog was shown.
Evidence:
Screenshot attached (available upon request): toggle visibly ON in settings panel.
Cursor Support (Nathan) wrote today: “there is a dedicated File-Deletion Protection toggle… defaults to off — enabling it closes that gap.”
My immediate response with screenshot: “Nathan, this setting was ALWAYS enabled.”
No technical rebuttal received.
Impact: Users who enable this setting believe they have protection against autonomous file deletion. They do not. This is a silent safety regression — the UI advertises a guarantee it does not enforce.
Minimum acceptable fix: The toggle must intercept ALL file deletion operations before execution, regardless of how the agent session was initiated (local IDE, Slack, web portal). If the implementation cannot guarantee this, the toggle must be removed from the UI and its guarantee must be removed from the documentation.
Bug 2 — Cloud Agent launched from Slack does not handle STOP commands as cancel signals
Severity: High — Agent cannot be stopped via the same channel it was launched from.
Expected behavior: Typing STOP (or any configured cancel command) in the Slack thread where a Cloud Agent was launched should cancel the running agent session.
Actual behavior: STOP commands sent via Slack are not handled as cancel signals. The agent continues running.
Evidence:
Cursor Support (Nathan) wrote today, verbatim: “you’re right that those aren’t handled as cancel signals today when a Cloud Agent is launched from Slack. That limitation is tracked on our side.”
Suggested workaround: use the Stop button at cursor.com/agents.
Impact: Operators who launch Cloud Agents from Slack cannot stop them from Slack. The only recourse is a separate web portal. This violates the principle of least surprise and creates a dangerous operational gap — an agent launched remotely cannot be remotely halted through its originating channel.
Minimum acceptable fix: STOP commands in the Slack thread where the agent was launched must propagate as cancel signals to the active agent session. If this is architecturally blocked, the Slack integration must display a prominent warning that stop commands are not honored and provide the web portal link at session start.
Bug 3 — No hard boundary (beforeShellExecution hook) for preventing agent modification of governance documents
Severity: High — LLM-level steering alone is insufficient for protecting critical files.
Context: Cursor’s agent can be instructed via AGENTS.md / .cursor/rules/ not to modify certain files (e.g., ADRs, governance docs). This instruction operates at the LLM steering level — it is a suggestion to the model, not an enforced system boundary.
Expected behavior: There should be a beforeShellExecution hook — a programmable callback that fires before any shell command execution — allowing operators to block commits that stage protected files before the shell operation completes. This would be a hard, cryptographic-level boundary that the LLM cannot override.
Actual behavior: No such hook exists in the current stable release. The only available boundary is LLM steering via rules files, which the agent has been observed to override under certain conditions.
Evidence:
Cursor Support (Nathan) acknowledged today: “For a hard boundary, a beforeShellExecution hook that blocks commits when staged files match docs/adr/ADR-.md would enforce it programmatically.”*
Nathan confirmed this hook does not currently exist and recommended it as a future improvement.
As a workaround, I have implemented: (a) cryptographic ADR hash inventory via inv-adr.ps1 + SSH ed25519 commit signing, (b) CI-level rejection of commits that alter ADR hashes, (c) revocation of Cursor Web’s access to the repository. These mitigations required significant engineering effort that should not be necessary.
Minimum acceptable fix: Implement a beforeShellExecution hook API that operators can configure to intercept and block specific shell commands before execution. The hook should receive the full command string and have the ability to return a non-zero exit code to block execution. This is essential for enterprise and compliance-sensitive use cases.
Combined impact statement
A user who:
Enables File-Deletion Protection (believing files are protected)
Launches a Cloud Agent from Slack (expecting to be able to stop it from Slack)
Has AGENTS.md governance rules (expecting the agent to respect governance document boundaries)
…has zero hard guarantees from the platform for any of these three expectations, despite explicit UI and documentation that implies otherwise.
This is not a configuration issue. All three settings were correctly configured and verified (screenshots documented). The failures are platform-level.
Requested actions
Engineering RCA for Bug 1 (File-Deletion Protection) with root cause and fix timeline
Internal bug number for Bug 2 (Slack STOP signals) with tracking link
Roadmap item or ADR for Bug 3 (beforeShellExecution hook API)
Update documentation to accurately reflect current behavior while fixes are pending
Report authored by a reliability engineer. Evidence is documented and preserved.
Operating System
Windows 10/11
Version Information
Currently: 3.5.17
For AI issues: which model did you use?
Opus 4.7 High
Additional Information
[BUG] Three confirmed agent safety failures — File-Deletion Protection inoperative, Slack STOP signals ignored, no beforeShellExecution hard boundary
Category: Bug Reports
Severity: Critical (security feature inoperative) + High (agent control failure)
Cursor version: Latest stable (Composer 2.5 / Cloud Agent)
Platform: Windows 11 + WSL2
Confirmed by: Cursor Support (Nathan) in writing, 2026-05-21
Summary
Three agent safety failures confirmed in writing by Cursor Support today. All three were reproducible, independently documented, and acknowledged. None have an engineering RCA or fix committed.
Bug 1 — File-Deletion Protection toggle is inoperative when enabled
Severity: Critical — A safety feature that is visibly ON is silently not enforced.
Settings path: Settings → Agents → Auto-Run → File-Deletion Protection
Expected behavior: When this toggle is enabled, every autonomous file deletion by the agent requires explicit user approval before execution.
Actual behavior: The agent deleted a file autonomously while the toggle was enabled. The deletion was not intercepted. No approval dialog was shown.
Evidence:
- Screenshot attached (available upon request): toggle visibly ON in settings panel.
- Cursor Support (Nathan) wrote today: “there is a dedicated File-Deletion Protection toggle… defaults to off — enabling it closes that gap.”
- My immediate response with screenshot: “Nathan, this setting was ALWAYS enabled.”
- No technical rebuttal received.
Impact: Users who enable this setting believe they have protection against autonomous file deletion. They do not. This is a silent safety regression — the UI advertises a guarantee it does not enforce.
Minimum acceptable fix: The toggle must intercept ALL file deletion operations before execution, regardless of how the agent session was initiated (local IDE, Slack, web portal). If the implementation cannot guarantee this, the toggle must be removed from the UI and its guarantee must be removed from the documentation.
Bug 2 — Cloud Agent launched from Slack does not handle STOP commands as cancel signals
Severity: High — Agent cannot be stopped via the same channel it was launched from.
Expected behavior: Typing STOP (or any configured cancel command) in the Slack thread where a Cloud Agent was launched should cancel the running agent session.
Actual behavior: STOP commands sent via Slack are not handled as cancel signals. The agent continues running.
Evidence:
- Cursor Support (Nathan) wrote today, verbatim: “you’re right that those aren’t handled as cancel signals today when a Cloud Agent is launched from Slack. That limitation is tracked on our side.”
- Suggested workaround: use the Stop button at
cursor.com/agents.
Impact: Operators who launch Cloud Agents from Slack cannot stop them from Slack. The only recourse is a separate web portal. This violates the principle of least surprise and creates a dangerous operational gap — an agent launched remotely cannot be remotely halted through its originating channel.
Minimum acceptable fix: STOP commands in the Slack thread where the agent was launched must propagate as cancel signals to the active agent session. If this is architecturally blocked, the Slack integration must display a prominent warning that stop commands are not honored and provide the web portal link at session start.
Bug 3 — No hard boundary (beforeShellExecution hook) for preventing agent modification of governance documents
Severity: High — LLM-level steering alone is insufficient for protecting critical files.
Context: Cursor’s agent can be instructed via AGENTS.md / .cursor/rules/ not to modify certain files (e.g., ADRs, governance docs). This instruction operates at the LLM steering level — it is a suggestion to the model, not an enforced system boundary.
Expected behavior: There should be a beforeShellExecution hook — a programmable callback that fires before any shell command execution — allowing operators to block commits that stage protected files before the shell operation completes. This would be a hard, cryptographic-level boundary that the LLM cannot override.
Actual behavior: No such hook exists in the current stable release. The only available boundary is LLM steering via rules files, which the agent has been observed to override under certain conditions.
Evidence:
- Cursor Support (Nathan) acknowledged today: "For a hard boundary, a beforeShellExecution hook that blocks commits when staged files match docs/adr/ADR-.md would enforce it programmatically."*
- Nathan confirmed this hook does not currently exist and recommended it as a future improvement.
- As a workaround, I have implemented: (a) cryptographic ADR hash inventory via
inv-adr.ps1+ SSH ed25519 commit signing, (b) CI-level rejection of commits that alter ADR hashes, (c) revocation of Cursor Web’s access to the repository. These mitigations required significant engineering effort that should not be necessary.
Minimum acceptable fix: Implement a beforeShellExecution hook API that operators can configure to intercept and block specific shell commands before execution. The hook should receive the full command string and have the ability to return a non-zero exit code to block execution. This is essential for enterprise and compliance-sensitive use cases.
Combined impact statement
A user who:
- Enables File-Deletion Protection (believing files are protected)
- Launches a Cloud Agent from Slack (expecting to be able to stop it from Slack)
- Has AGENTS.md governance rules (expecting the agent to respect governance document boundaries)
…has zero hard guarantees from the platform for any of these three expectations, despite explicit UI and documentation that implies otherwise.
This is not a configuration issue. All three settings were correctly configured and verified (screenshots documented). The failures are platform-level.
Requested actions
- Engineering RCA for Bug 1 (File-Deletion Protection) with root cause and fix timeline
- Internal bug number for Bug 2 (Slack STOP signals) with tracking link
- Roadmap item or ADR for Bug 3 (beforeShellExecution hook API)
- Update documentation to accurately reflect current behavior while fixes are pending
Report authored by a reliability engineer. Evidence is documented and preserved.
Does this stop you from using Cursor
No - Cursor works, but with this issue