Agent did remove file without confirmation

[fritse (Fritz Matthäus)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a command that tells the agent to draft a pull request and create it via the github cli. Afterwards it should remove the draft file. The rm command is not in my allowlist, so in general the agent asks for my permission to delete the file.

Now i have experienced with the Claude 4.5 Haiku model that the agent did remove that file without asking for permission. The permission has not been given at any time in the chat history.

This should not happen! I have already reported a bug like this a couple of months ago.

Steps to Reproduce

Hard to say:

This is the skill i have invoked:

---
name: create-pr-rule
description: Apply this rule when creating pull requests using the GitHub CLI
---
# Pull Request Creation Rule

## Prerequisites

- Use GitHub CLI (`gh`) for all pull request operations
- Apply [github-cli-rule.mdc](github-cli-rule.mdc)
- Ensure you're on the correct branch before creating the PR
- All pull requests target the `main` branch

## PR Creation Workflow

### Step 1: List All Commits

**CRITICAL**: Start by retrieving ALL commits to understand the full scope of changes.

Use this reliable method (works in all scenarios):

```bash
# Get current branch name
git branch --show-current

# List all commits between main and current branch with links
git log main..HEAD --pretty=format:"- [%h](https://github.com/your-repo/commit/%H) %s"

Fallback method (if above fails):

# Using GitHub API
gh api repos/your-repo/compare/main...HEAD \
  --jq '.commits[] | "- [\(.sha[0:7])](\(.html_url)) \(.commit.message | split("\n")[0])"'

Step 2: Analyze Commits for Summary

CRITICAL: Before writing the summary, analyze EVERY commit carefully:

1. Review all commit messages - identify distinct features, fixes, and changes
2. Group related commits - cluster commits by feature/purpose
3. Extract ALL key changes - don’t skip any significant changes
4. Identify the main purpose - determine the primary goal from branch name and commits

Summary Writing Guidelines:

• The summary MUST mention ALL significant features/changes from the commits
• Start with the primary feature (usually from branch/issue name)
• Include secondary features, additions, and improvements
• Use “and” or commas to connect multiple changes in one clear sentence
• Verify each commit is represented in either the summary or tasks section

Example Analysis:

Commits show:
- feat: add path matching → Main feature
- feat: add mock flag → Secondary feature (MUST include!)
- chore: add logout → Additional feature (MUST include!)
- test: add tests → Supporting work
- chore: update rules → Supporting work

Summary should mention: path matching AND mock flag AND logout AND rules

cho### Step 3: Create Draft File

IMPORTANT: Create a draft file for the PR message to allow user review and editing.

1. Write a comprehensive summary covering ALL changes (see Step 2)
2. List ALL commits with links (from Step 1) and order top-down in their order in the commit history. So the first commit included in the PR is first, the last one is last
3. Create task list reflecting all work done
4. Follow the template exactly
5. Verify every commit is accounted for in summary or tasks
6. Write the complete PR message to a file named pr_draft.md in the workspace root

Draft File Creation:

# Create pr_draft.md file with the complete PR message following the template
# The file should be created in the workspace root directory

Step 4: User Review

1. Inform the user that pr_draft.md has been created and is ready for review
2. Allow the user to edit the draft file as needed
3. Wait for user confirmation that the draft is ready

Step 5: Create the Pull Request

Only after user confirms the draft is ready:

# Create PR using the draft file
gh pr create --base main --title "<PR Title>" --body-file pr_draft.md

# After successful PR creation, delete the draft file
rm pr_draft.md

IMPORTANT: Always delete pr_draft.md after successfully creating the PR.

Pull Request Message Template

Use this exact template structure with proper formatting and line breaks:

### Summary

<!-- Briefly summarize the purpose of this pull request -->

This pull request [briefly state what the PR accomplishes, e.g., "adds login functionality to the Hypeguard app, including form validation and error handling."]

#### Commits

<!-- List all commits with links; each commit should be on its own line -->

<!-- For example:
- [abc1234](https://github.com/org/repo/commit/abc1234) Create login form UI
- [def5678](https://github.com/org/repo/commit/def5678) Add client-side validation
- [ghi9012](https://github.com/org/repo/commit/ghi9012) Implement API call for login
-->

#### Tasks Completed

<!-- Briefly describe each task; ideally each line corresponds to an atomic commit -->

<!-- For example:
- [x] Create login form UI
- [x] Add client-side validation
- [x] Implement API call for login
-->

### Breaking Changes

<!-- List any breaking changes here; be specific about how they impact other parts of the project or users -->

- <!-- e.g., "Updated API endpoint /api/login now requires additional security parameters" -->

### Linked Issues

<!-- Link to related issues by replacing #<issue-number> with the correct issue number(s) -->

Closes #<issue-number>

### Additional Notes

<!-- Add any additional context or considerations here, if needed -->

Formatting Requirements

Line Breaks

• Always include blank lines between sections
• Ensure proper spacing around code blocks and lists
• Maintain consistent indentation for nested lists

Markdown

• Use proper markdown syntax for headings (### for sections)
• Use checkboxes for task lists (- [x] for completed, - [ ] for incomplete)
• Use bullet points for commits and breaking changes (- prefix)
• Use inline code blocks for technical terms when appropriate

Commits Section

• Each commit MUST be on its own line
• Format: - [short-sha](commit-url) commit message first line
• Use 7-character short SHA
• Link to the full commit on GitHub
• Include only the first line of the commit message

Tasks Section

• Each task should correspond to one or more commits
• Mark all tasks as completed ([x]) since the work is done
• Be specific about what was accomplished

Breaking Changes

• If there are NO breaking changes, state: - None
• If there ARE breaking changes, list each one with specifics
• Explain the impact on users or other parts of the project

Linked Issues

• Always link to the issue(s) this PR addresses
• Use the Closes #<number> syntax to auto-close issues
• If multiple issues: Closes #123, Closes #456

Example PR Creation Session

# 1. Get current branch name
CURRENT_BRANCH=$(git branch --show-current)

# 2. List commits with links (primary method)
git log main..HEAD --pretty=format:"- [%h](https://github.com/your-repo/commit/%H) %s"

# 3. Analyze commits:
#    - Identify main feature from branch name
#    - Extract ALL key features from commit messages
#    - Group related commits
#    - Ensure nothing is missed

# 4. Draft comprehensive summary mentioning ALL significant changes

# 5. Create complete PR message following template and write to pr_draft.md

# 6. Inform user that pr_draft.md is ready for review
#    User can edit the file as needed

# 7. After user confirms draft is ready, create PR using the draft file
gh pr create \
  --base main \
  --title "Add user authentication feature" \
  --body-file pr_draft.md

# 8. Delete the draft file after successful PR creation
rm pr_draft.md

Checklist Before Creating PR

• All commits retrieved successfully with proper links
• Every commit analyzed for key changes
• Summary mentions ALL significant features/changes from commits
• Summary is comprehensive and doesn’t skip secondary features
• Tasks section reflects all work done
• Breaking changes documented (or marked as “None”)
• Issue numbers verified and linked
• Formatting verified (line breaks, markdown syntax)
• Self-check passed: each commit represented in summary or tasks
• pr_draft.md file created with complete PR message
• User has reviewed and confirmed the draft is ready
• Base branch is set to main
• Draft file will be deleted after PR creation

Common Mistakes to Avoid

DON’T:

• Skip commits when analyzing changes
• Write summary based only on branch name or main feature
• Ignore secondary features or improvements in commits
• Assume commits are only supporting work without checking
• Use GitHub API as first method (it may fail silently)
• Proceed without verifying all changes are mentioned
• Create PR directly without creating a draft file first
• Forget to delete pr_draft.md after PR creation

DO:

• Use git log as primary method for listing commits
• Analyze EVERY single commit for features/changes
• Mention ALL significant features in the summary
• Include secondary features even if they seem minor
• Verify the summary against all commits before showing to user
• Create pr_draft.md file for user review and editing
• Wait for user confirmation before creating the PR
• Always delete pr_draft.md after successful PR creation
• Use --body-file pr_draft.md when creating the PR
• Self-check: “Does my summary cover all the work done?”

Common Commands

# Create PR using draft file (recommended workflow)
gh pr create --base main --title "<PR Title>" --body-file pr_draft.md

# View PR draft in browser before creating
gh pr create --web

# Create PR with editor for message
gh pr create --base main --fill

# List current PRs
gh pr list

# View PR status
gh pr status

# Edit PR after creation
gh pr edit <number> --body "new body"

# View commits to analyze (most reliable)
git log main..HEAD --oneline

Expected Behavior

The agent should have awaited my explicit approval of removing the file.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

IDE:

Version: 2.6.20 (Universal)
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Haiko 4.5

For AI issues: add Request ID with privacy disabled

cb21c344-301c-4cfd-b543-458eb6e2265f

Additional Information

This is a critical bug. I have encountered it previously and i assume that smaller models to not “care” that much about the rules.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, this is known behavior. In Auto-Run in Sandbox mode, which is the default, the Command Allowlist is not applied. The sandbox replaces it with filesystem and network restrictions instead of per-command approval. The UI is confusing because the allowlist field still looks like it’s active.

So rm running without confirmation isn’t model-specific. It’ll happen with any model in sandbox mode.

Workaround: enable Legacy Terminal Tool in Cursor Settings > Agents > Inline Editing & Terminal. After that, the allowlist will be enforced and rm will require your approval.

More context here: Command Allowlist is silently ignored when "Auto-Run in Sandbox" is enabled

Let me know if that helps.