Over one week in October 2026 I pointed nine AI coding agents at the same small project on my Windows PC and recorded the file activity in that project while each one worked. I wasn't trying to rank them on code quality. I wanted to know what actually happens on disk when an agent "edits a few files", and whether I could put everything back exactly as it was afterwards.
Full disclosure up front: I'm building a Windows tool that records which program changed which file and can undo an agent's session. That tool is what did the recording here, and this testing was its release gate. So read this as one developer's logs, not an independent benchmark.
The setup
-
The project: a small .NET notes app with a
srcfolder and atestsfolder, in its own local git repository. Before every run I made a commit, so afterwardsgit statusandgit diffshowed exactly what had changed and whether the undo really put everything back. -
The task: seven of the agents got the same task: add
DeleteCommand.cs, renameAddCommand.cstoNewCommand.cs, deleteListCommand.cs(moving its code intoProgram.cs), and add a line toREADME.md. Claude Code and OpenAI Codex had run earlier, during a previous gate, on different refactoring tasks in the same project (adding commands, moving a class into a new folder, updating the checks and README). - The rule for a pass: the agent's changes had to be recognized as that agent's work with no setup, and undoing the session had to leave the folder matching git exactly.
How I tested. The seven ran on 7–8 October 2026. Each agent had only a few runs. Where testing turned up issues in the recorder, I fixed them and re-ran those tests.
The nine: Claude Code, OpenAI Codex, Claude Desktop (Cowork), GitHub Copilot in VS Code, GitHub Copilot in Visual Studio, Cursor, Windsurf (now Devin), Gemini CLI and Aider. In the end all nine passed. Getting there was more interesting than the result.
At a glance
| Agent | What wrote the files | What surprised me |
|---|---|---|
| Claude Code | Claude Code, saving "atomically" (new copy swapped in) | Forcing an undo through a conflict also took my own README edit |
| OpenAI Codex | A fresh codex.exe for each edit |
One run first showed up as several sessions; it repaired a build a partial undo had broken |
| Claude Desktop (Cowork) |
claude.exe on the PC, despite the sandbox |
It skipped the delete and the rename |
| Copilot in VS Code |
copilot-runtime.exe (VS Code itself a week earlier) |
8 files touched for 4 requested changes |
| Copilot in Visual Studio |
devenv.exe, Visual Studio itself |
Saves via temp files, so existing files first looked newly created |
| Cursor |
Cursor.exe itself |
Without a repository, its Agents window worked on a copy in another app's folder |
| Windsurf, now Devin |
devin.exe, with PowerShell for deletes |
My recorder first credited its edits to Cursor, because I'd downloaded it from a link in Cursor |
| Gemini CLI | — | Google sign-in no longer works for individuals; the free key's daily allowance ran out |
| Aider | — | Commits to git by default, and left its own .aider* files behind |
What each one did
Claude Code
I asked it to add delete and find commands, move the NoteStore class into a new Storage\ folder, and update Program, the checks and the README, then build and run the checks. It moved NoteStore and then edited it in its new place. Undoing the session took eight actions with no failures, and the project matched the commit afterwards.
In this run it saved files "atomically" (write a new copy, then swap it in) rather than editing in place, which matters if you're trying to tell what changed.
In a second round I let Claude Code edit some files and then edited the README myself in VS Code. When I undid the agent's work but kept one of its files, my own README line went with the undo, because I'd told it to overwrite the conflict. That's what forcing means, but it's a reminder that "undo the agent" and "undo everything since the agent started" aren't the same thing.
OpenAI Codex (CLI 0.159)
Same kind of task: add an edit command, a check and a README line, then run the checks. Codex's process model surprised me: each edit was made by a fresh codex.exe started under a command runner, so on my first attempt one Codex run showed up as several separate sessions.
The more instructive part: the previous round had ended with a partial undo (one of Claude Code's files kept, the rest reverted), which left the project not building. In this case, Codex repaired the resulting build failure as part of its task. Lesson: a partial undo can leave code half-changed, and whatever runs next inherits it.
Codex also supports a hook that runs before each edit; in my test it fired 2 seconds before the edit landed.
Claude Desktop (Cowork)
Cowork changed 4 files, all written by claude.exe on the PC itself, even though Cowork works in a sandbox. In this run, with manual approval on, Cowork created and changed files but did neither the deletion of ListCommand.cs nor the rename of AddCommand.cs.
GitHub Copilot in VS Code (Agent mode)
Copilot touched 8 files for a task that named 4 changes: it also edited NoteStore.cs and the checks without being asked. "It changed more than I asked" is worth knowing before you hit Keep.
The writes came from copilot-runtime.exe. In an earlier run on 1 October, Copilot's writes came from VS Code's own process instead. Agents can change how they work between runs without telling you.
GitHub Copilot in Visual Studio (Agent mode)
Every change was made by devenv.exe, Visual Studio itself, so there is no separate "Copilot" process to point at. Visual Studio also saves by writing a temporary file and renaming it over the original, so existing files like Program.cs first looked newly created, and temp files with names like 54u00h4d.hp4~ appeared alongside them.
Cursor 3.22
My first try was in Cursor's Agents window with no repository attached. Nothing happened in my project, because the agent picked up a copy of the project in another app's scratch folder and did all its work there. Opened properly in the editor (Agent mode, folder open), it changed 7 files, all written by Cursor.exe itself, so on disk the agent's edits can't be told apart from your own typing.
Windsurf, now Devin 3.10
Windsurf had been renamed: the app is now Devin.exe, and its agent runs as a child devin.exe that starts PowerShell to delete files.
In this run it renamed AddCommand.cs using PowerShell and then edited it. It also edited NoteStore.cs, which wasn't in the task, and then put it back.
The odd part: I'd downloaded the Devin installer by clicking a link inside Cursor. Following the chain of processes (Devin, its installer, my web browser, Cursor), Devin's edits were first credited to Cursor, and landed in Cursor's session. If you ever wonder why "which agent did this?" is harder than it sounds, that's why.
My recorder had followed that process chain too literally. I fixed its attribution rules and repeated the test on version 0.10.3 of the recorder, with my hand-made rule deleted and Devin started from the Start menu. Devin's edits were now credited correctly as one session, and undo matched git exactly.
Gemini CLI 0.63
When I tried Google sign-in, Gemini CLI told me it no longer works for individuals and to "migrate to Antigravity", so I ran it on a free AI Studio API key. The key's daily allowance ran out on the first model, so a second model did the round. It changed 8 files.
Aider 0.86.2
By default Aider commits to git by itself. Even with --no-auto-commits it still stages new files with git add. I ran it with --no-auto-commits. It renamed AddCommand.cs to NewCommand.cs, and it left its own .aider* files in the project. Some of those were cache files Aider still had open while running; they could only be cleaned up after I closed Aider.
If you use Aider with auto-commits on, remember that putting your files back leaves git's history and index alone.
What I took away
-
Commit before every agent session. It cost seconds and made every undo checkable against
git diff. -
Agents do more than you asked. Copilot in VS Code and Devin both touched
NoteStore.cs, which wasn't in the task. - "The agent" is often just your editor. In Visual Studio and Cursor, the agent's edits come from the same process as your own typing.
- Partial undos are risky. Keeping one file from an agent's change left my project not building; in my case, the next agent happened to repair it.
- Know where your agent is actually working. Cursor's Agents window without a repository did its work in a different folder entirely.
-
Agents change under you. During that week's tests I found Windsurf running as
Devin.exe, Copilot writing from a different process than a week before, and Gemini CLI turning away Google sign-in for individuals. - Aider and git: know whether auto-commits are on before you run it.
The tool
The recorder and undo I used is FileSquirrelAI, a Windows app I'm building, currently in free public beta. It records which agent changed which file and can put a session back. It has been tested with all nine agents above, in the way described here. If you try it, I'd like to hear how it works with your setup: beta@filesquirrelai.com.
Top comments (1)
Atomic saves are the trap for a recorder doing this. If the agent writes a new copy and swaps it in, a watcher keyed on path sees no edit at all, and one keyed on inode sees a delete plus a create - either way the inode you edited is not the one that survives. Which keying did you land on?The harder half is the editor-as-agent cases. In Visual Studio and Cursor the writes come from the host process, so process-chain attribution cannot separate your own save from the agent's. I hit the same wall from the enforcement side, running Microsoft's agent-hooks conformance kit: the tool seam is the only place the framework can say which action was requested, and it only covers calls that pass through it - anything a provider executes on its own side never appears in the record.