Cursor agent ran a dangerous command: what to do now

If the Cursor agent ran a dangerous command, stop the agent, read the exact command in the chat history, restore the lost data from git or a backup, and then change the Run Mode so the agent asks before it runs shell commands. Do the repair work first and the settings work second.

This guide shows how to find out what the command did, how to undo it, and how to limit the agent in the future.

What does it mean when the agent runs a dangerous command?

It means that the model wrote a shell command, and Cursor ran it on your computer with your user rights. The command can delete files, change git history, install packages, call a cloud CLI, or send data over the network. The agent has the same rights as you in the terminal.

Three causes are common. The first cause is a loose request, such as “clean up the project”. The second cause is a model error, such as a wrong path or a wrong database name. The third cause is prompt injection. Text in a file, a web page, or a tool result tells the model to run a command that you did not ask for.

Cursor states the risk in its security documentation: “AI can behave unexpectedly due to prompt injection, hallucinations, and other issues.” The same page says that Run Modes are “best-effort guardrails rather than a hard security boundary.”

The danger depends on your Run Mode. In Run Everything mode, every tool call runs automatically, with no sandbox and no classifier. In the other modes, a command can still run if it matches your allowlist or if the classifier approves it. For this reason, check the mode before you check anything else. The Cursor run modes documentation lists the three modes and where to set them.

How do I confirm what the command did?

Read the command first. Do not guess from the symptoms.

1. Open the chat that ran the command. Scroll to the tool call. Cursor shows the full command text and the output.
2. Copy the command into a text file. You need the exact text for the later steps, and the chat can change.
3. Read each part of the command. Look for rm, git reset, git clean, git push --force, drop, delete, truncate, curl, wget, sudo, chmod, and chown. Also look for the | and ; characters, because one line can hold many commands.
4. Check the working directory. A command that ran in a parent folder can affect more files than you expect.
5. Check if the command touched a remote system. A command with a database URL, a cloud CLI, ssh, or an API token can change data outside your computer.

Then check the state of the project:

git status
git log --oneline -n 10
git reflog -n 20
git stash list

The git reflog command shows where the branch pointed before each change. It is the main tool to recover from a bad git reset or a bad rebase.

To find files that changed in the last hour, run this command from the project folder:

find . -mmin -60 -not -path "./node_modules/*" -not -path "./.git/*" | head -50

Warning: Do not run the agent again in the same project before you finish this check. A new command can overwrite the evidence or make the damage larger.

What do I do first? Fix it now, in order of urgency

Do the steps in this order. Steps 1 to 3 stop more harm. The later steps repair the harm.

1. Stop the agent. Select the stop button in the chat. Then close the agent tab. If a long command still runs, press Ctrl+C in the terminal that shows it.
2. Cut the network if the command could send data. If the command used curl, wget, or scp, turn off Wi-Fi until you read the command.
3. Rotate any secret that the command could read. If the command printed a .env file, uploaded a folder, or ran a script that you do not know, assume the secrets are public. Rotate API keys, database passwords, and tokens that were in the shell or in the project. The guide on environment variables security explains where these values live.
4. Restore tracked files with git. If the command deleted or changed files that git tracks, use git restore:

git restore --source=HEAD --staged --worktree -- path/to/folder

6. Restore a changed branch with the reflog. If the command ran git reset --hard or a bad rebase, find the earlier commit in git reflog and move the branch back:

git reflog
git reset --hard HEAD@{3}

Replace HEAD@{3} with the entry from before the command. Caution: git reset --hard removes uncommitted changes. Save a copy of the folder first.

7. Restore untracked files from a backup. Git cannot return a file that it never tracked. Check the system trash, a Time Machine backup, a cloud sync history, or a local history in your editor.
8. Restore the database from a backup. If the command changed a database, stop all writes to it. Then use the point-in-time restore or the latest backup of your provider. Do not try to repair rows by hand before you have a copy of the current state.
9. Reinstall the dependencies. If the command changed node_modules or the lock file, run git restore package-lock.json or the file for your package manager. Then run a clean install.
10. Change the Run Mode. Open Settings > Agents > Approvals & Execution and select Auto-review or Allowlist. See the prevention section for the full list of settings.

If you pushed the bad state to a remote repository, ask the team before you force-push a repair. A force-push can remove the work of other people.

How do I check the damage after the command?

Match the type of command to the place that holds the evidence.

Look at the lock file diff with this command:

git diff HEAD -- package-lock.json | head -100

If the command ran a script from the internet, scan for new files and new startup items. On macOS, look at ~/Library/LaunchAgents and /Library/LaunchDaemons. On Linux, look at your user crontab and the systemd user units. If you find anything that you did not create, treat the computer as compromised and read the last section.

Also check the deployed app. A command that changed an access rule or a storage bucket can make data public. Open the live app in a private window and test the pages and the API without a login. The guide to securing Cursor lists more checks.

How do I stop the agent from running unsafe commands again?

Use several layers. No single setting is enough, because the Cursor docs say that the run modes are not a hard boundary.

Choose a Run Mode that asks

The Cursor docs describe three modes:

Do not use Run Everything on a computer that holds real credentials. Use Auto-review with the sandbox, or use Allowlist with a short list of safe commands such as git status and npm test. Do not add rm, git, curl, sudo, or a shell like bash or sh to the allowlist without arguments. A shell can run any other command.

The same documentation says that Auto-review “is not a security boundary” and that the classifier can make mistakes. Treat it as a filter and not as a guard.

Write block rules in permissions.json

In Auto-review mode, permissions.json steers which calls the agent runs and which calls the classifier reviews. The file uses an autoRun object with allow_instructions and block_instructions. Each one is a list of plain sentences. Put the project file at .cursor/permissions.json, and the personal file at ~/.cursor/permissions.json. Cursor merges both files.

{
  "autoRun": {
    "block_instructions": [
      "Never delete files outside the current project folder.",
      "Never run git push --force or git reset --hard.",
      "Never run commands that contact a production database or a production cloud account.",
      "Never download and run a script from the internet."
    ]
  }
}

A classifier reads these rules, so it can make a wrong decision. Use them as one layer.

Limit what the sandbox can reach

The sandbox restricts what a command can reach, so it is the most useful layer in this list. The sandbox.json file controls the network policy and the extra paths that a sandboxed command can read or write. The network modes are sandbox.json Only, sandbox.json + Defaults (the default), and Allow All. Do not select Allow All.

The Cursor docs also describe a Read Access setting in Settings > Agents > Approvals & Execution. The default value is System, which lets the agent read files outside the workspace without approval. Select Workspace so that a read outside the project needs your approval. This setting needs a recent Cursor version, so check the documentation for your version.

Keep secrets and production access out of reach

A sandbox cannot protect a secret that the project itself holds. Use these rules:

1. Use a separate development database. Never put a production connection string in the .env file that the agent can read.
2. Use tokens with the lowest rights. A cloud token for development must not have the right to delete production resources.
3. Do not stay logged in to production CLIs. Log out of the cloud CLI, the database CLI, and the deploy CLI when you do agent work.
4. Add .env* to .gitignore. Cursor ignores these files by default for the agent file tools. The terminal can still read them. The Cursor ignore documentation says that the terminal and MCP tools “cannot block access to code governed by .cursorignore”.

Keep the default protections and a clean git state

The Cursor docs list protections that can require approval even in automatic modes: Browser Protection, File-Deletion Protection, and External-File Protection. Cursor recommends that you keep them turned on. Check that all three are on.

Before each large agent task, commit your work on a new branch. If the agent makes a mess, delete the branch.

Treat untrusted projects with more care

A cloned repository can hold text that changes the behavior of the model. This text can sit in a README, in a code comment, in an issue, or in a data file. For projects that you do not trust, turn on workspace trust. The Cursor security page says to add "security.workspace.trust.enabled": true to your user settings.json. It also says that for untrusted repositories you should use a basic text editor. For more about this attack, read about indirect prompt injection.

When should I get help?

Get help in these cases:

• The command ran on a computer that holds production credentials, and you cannot say which credentials the shell could read. Rotate all of them and ask a security engineer to review the access logs.
• The command downloaded and ran a script from a source that you do not know. Treat the computer as compromised. Back up the data that you need, and then reinstall the operating system.
• The command deleted production data, and no backup is available. Contact the support team of your database provider at once. Some providers can restore data for a short time.
• The command changed an access rule on a cloud resource, and you do not know if the data was public. Read the audit log of the provider, and test the live app without a login.
• Your app stores personal data and the command may have exposed it. You may have a legal duty to report the event, so ask a lawyer or a security professional.

After the repair, run one test. Start a new agent chat with a harmless task, and make sure Cursor now asks before it runs a shell command that is not on the allowlist.