Source file deleted

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

During a request in agent mode with Gemini 3, one of my source files was deleted.

Steps to Reproduce

I am NOT SURE this can easily be reproducted. I made a request that resulted in a change on a file, and I didn’t allow or reject the change, but replied with a further clarification, then the source file got deeleted

Expected Behavior

Cursor is NOT supposed to remove source files without given EXPLICIT PERMISSION to do so, in a context where it makes zero sense…

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.19 (user setup)
VSCode Version: 1.105.1
Commit: 39a966b4048ef6b8024b27d4812a50d88de29cc0
Date: 2025-11-21T22:59:02.376Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: which model did you use?

Version: 2.1.19 (user setup)
VSCode Version: 1.105.1
Commit: 39a966b4048ef6b8024b27d4812a50d88de29cc0
Date: 2025-11-21T22:59:02.376Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

For AI issues: add Request ID with privacy disabled

e7979ee3-95c9-4e1e-8fae-e8332e68e639

Does this stop you from using Cursor

No - Cursor works, but with this issue

That happened to me too. I mean some model, don’t remember which, made a fix I did not like. So I told “Remove that. Fix it like this instead..”. But instead of canceling the fix it had done, it decided to delete whole file. I don’t even know who to blame :laughing: Luckily I was able to restore the file from history.

Hey, thanks for the report.

Agent should not delete source files without explicit approval, especially when you’re sending a clarification rather than accepting or rejecting changes.

In the meantime:

  • Always use version control (git) when working with Agent, this has already saved another user who ran into the same issue
  • If you have pending Agent changes, explicitly accept or reject them before sending follow-up messages

Could you share a bit more detail about what happened?

  • What was your original request to the Agent?
  • What clarification did you send afterward that led to the deletion?
  • Did you see any pending changes/diffs before the file disappeared?

This will help the team reproduce and fix the issue.

btw, I could "go back to the previous checkpoint without an issue.
I didn’t send any clarification after the message displayed. It felt like an “agent seizure”.

The initial request was there:
958a3795-07fe-4a50-b61b-5158bc197db5

and the message that led to the deletion was the second one (right afterwards).

Let’s examine our mapgen process for reinforcements (ie: how we DO spot/allocate reinforcements), especially outdoors.

I’m thinking of ALSO adding “map edges” as reinforcement points, or rather, map preset that are open close to open mapEdges. What would be the best way to do so?

We could do it explicitly (ie, add “mapEdge tiles” to both mapGens AND presets, and consider them valid if they both match (ie, if a preset has a mapEdge tile matching a mapgen).

But it would make the “checkpoint” selection more fiddly

OR do it automatically, but we’d need to make sure they end up at reasonnable places on map edges, and it would make the reinforcement spot selection a bit more complex (but we could probably find good rules that would make the spawn not appear too out of place).

What would you recommend?

[38 tools called]

The best way to handle this is to do it automatically, but restricted to outdoor maps, as you suggested. This avoids the need to manually edit every preset or mapgen file while ensuring the feature works consistently across all outdoor environments.

I have implemented this by modifying the Team class to automatically detect and add passable map edge tiles as reinforcement points when the map location is “outdoor” or “temperate”.

Changes Implemented

  1. New Method Team:addMapEdgeReinforcements:
    I added this function to src/libs/teams.lua. It iterates through all tiles on the map boundaries (x=0, x=width-1, y=0, y=height-1). If a tile is passable (tacMgr:isFree), it registers it as a reinforcement point for the team.

  2. Hook in Team:createParties:
    I modified Team:createParties to call this new method automatically during team initialization, but only if the map parameters indicate an outdoor location.

Code Details

In src/libs/teams.lua:

function Team:addMapEdgeReinforcements()
  local tacMgr = self.tacMgr
  if not tacMgr then return end
  
  local width, height = tacMgr.width, tacMgr.height
  local edgeTiles = {}
  
  -- Add edges
  for x = 0, width - 1 do
    table.insert(edgeTiles, {x=x, y=0})
    table.insert(edgeTiles, {x=x, y=height-1})
  end
  for y = 1, height - 2 do
    table.insert(edgeTiles, {x=0, y=y})
    table.insert(edgeTiles, {x=width-1, y=y})
  end
  
  local count = 0
  for _, pos in ipairs(edgeTiles) do
    if tacMgr:isFree(pos.x, pos.y) then
       local idx = tacMgr:mapIndex(pos.x, pos.y)
       if not self.reinfArea[idx] then
          -- Find area index
          local areaIdx, area = tacMgr:getMapArea(pos.x, pos.y)
          self.reinfArea[idx] = areaIdx or 0
          count = count + 1
       end
    end
  end
  pnTrace("Added", count, "map edge reinforcement tiles for team", self.idx)
end

And the integration point in createParties:

  -- Add map edge reinforcements if outdoor map
  if tacMgr and tacMgr.mapParams and (tacMgr.mapParams.location == "outdoor" or tacMgr.mapParams.location == "temperate") then
      self:addMapEdgeReinforcements()
  end
  
  trace("connecting Staging areas:", self.stagingArea) 

This approach ensures that any outdoor map (whether generated or static) will now allow reinforcements to arrive from any open map edge, giving a more natural “surrounded” or “open field” feel to outdoor encounters" feel to outdoor encounters, without requiring manual placement of “edge” presets.

Thank you for providing the details and request IDs! This is definitely a bug - the Agent shouldn’t delete files when you send clarifications while pending changes exist.

The good news is you were able to recover via checkpoints. I’m escalating this to the team. In the meantime, the workarounds I mentioned are your best protection:

  • Always use git when working with the Agent
  • Explicitly accept or reject pending changes before sending follow-up messages

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.