What Your Agent's File Changes Look Like Before You Accept Them
A diff view before every accepted file change, versioned history behind it, and a filesystem that refuses any key that isn't yours — the concrete answer to 'will it just change my files.'
"Will the agent just go change my files without telling me" is one of the most reasonable hesitations anyone has before giving an AI agent write access to anything real. It shows up constantly in the broader 2026 conversation about computer-use and agent autonomy — agents editing files, filling in forms, reorganizing systems — and it's consistently named as the single biggest trust gap keeping people from handing an agent write access at all. Piskes's answer is specific enough to actually evaluate rather than just take on faith.
Diff before accept
When your agent proposes a change to a file, you don't just get told it happened — you get shown a diff, the same way you'd review a code change before merging it. You can see exactly what's being added, removed, or altered, side by side with what was there before, and you decide whether to accept it. Nothing gets silently overwritten in the background while you're looking somewhere else.
Versioned history behind it
Beyond the diff at the moment of the change, the underlying sandbox filesystem keeps a version history — so a change you accepted isn't a one-way door. If something goes wrong after the fact, or you simply want to see what a file looked like before an earlier edit, that history is there to go back to.
The part that matters most: whose files these actually are
There's a quieter but arguably more important detail underneath both of those: the filesystem itself refuses any key that doesn't start with the caller's own user id. That's the tenancy boundary, enforced at the storage layer, not just assumed by the UI. And when a request comes in for something that isn't yours, the system answers "not found" rather than "not yours" — a small distinction with a real security purpose. "Not yours" confirms that the thing exists, which turns the endpoint into a way to probe for other people's files by trial and error. "Not found" gives an attacker nothing to work with either way, whether the file exists under someone else's key or doesn't exist at all.
Why the whole picture matters, not just one piece
Any one of these three things on its own would be a reasonable but incomplete answer to "can I trust it with my files." A diff without version history means you can review a change but can't easily undo it later. Version history without a diff-before-accept means changes happen first and get reviewed only in hindsight. And either of those without a hard tenancy boundary at the storage layer would mean the review process is protecting you from the wrong thing — a well-intentioned diff view doesn't help if the underlying filesystem doesn't actually enforce whose files are whose.
Together, they're a genuinely concrete answer to the hesitation at the top of this piece: you see the change before it lands, you can go back if it turns out to be wrong, and the storage layer itself won't let a request reach a file that isn't yours in the first place — not because the UI happens to be polite about it, but because the key it would need to reach that file doesn't belong to it.