Your Files, Versioned: Building Undo for AI

The file that disappeared

A user ran a background task that was supposed to refactor a Python script. The agent decided the best approach was to rewrite the file from scratch. It deleted the original, wrote a new version, hit an error halfway through, and stopped. The user came back to a half-written file and no way to recover what was there before.

That was early February. We shipped file versioning on February 10 (commit bf63a68).

Every edit, tracked

The fix was straightforward in concept: never overwrite, always append. Every time a file changes in a workspace, we create a new version entry. The previous content is preserved as a snapshot. The file viewer shows the latest version by default, but you can open the version panel and browse the full history.

This isn’t git. There are no branches, no merge conflicts, no commit messages to write. It’s automatic. The agent edits a file, a version appears. The user edits the same file, another version appears. You can restore any previous version with one click.

We chose this over a git-based approach because our users aren’t developers. They don’t want to think about version control. They want to know that if something goes wrong, they can undo it — the same principle behind the file write restrictions in our security layers. That’s the entire mental model: undo for AI.

Task rollback

Individual file versions solve the common case. But agents don’t touch one file at a time. A single background task might create three files, modify two others, and delete one. If that task goes sideways, restoring files one by one is tedious.

Task rollback reverts all file mutations from a specific background task at once. One button, everything the agent did in that task gets undone. The files return to their pre-task state. We track which versions belong to which task execution, so the mapping is exact.

This turned out to be the feature users actually wanted. Individual version history is nice for browsing what changed. Task rollback is what you reach for when something breaks.

Binary files were a mess

Text files were the easy part. The harder problem was binary media — images, audio, video. Our sandbox architecture runs agent tasks in isolated E2B containers. When a task produces an image, that file needs to get from the sandbox back to the user’s workspace.

The original approach stored binary content directly in MongoDB documents. Base64-encoded blobs crammed into a database that has a 16MB document size limit. It worked for small files. It corrupted large ones. It was slow for everything.

On March 19 (commit bc4b733), we moved binary file storage to Google Cloud Storage. The workspace database now stores a GCS reference — a pointer to where the actual file lives. The file viewer fetches binary content on demand from GCS. No size constraints from MongoDB. No base64 encoding overhead. No data corruption on large media files.

This mattered because we’d been seeing users run image generation tasks in sandboxes — charts, diagrams, AI-generated visuals — and the results were getting mangled on the way back. The VFS media storage fix resolved all of those reports.

Making files readable

While we were fixing how files get stored, we also fixed how they get displayed. Two changes shipped back to back on March 18-19.

First, syntax highlighting for Python and TypeScript files (commit 1806692, March 18). Before this, .py and .ts files rendered as monospaced plain text. No color, no structure, no visual distinction between keywords and variables. Now the file viewer applies language-aware highlighting. We started with Python and TypeScript because those are the two languages our agents write most often.

Second, a bug fix for Markdown rendering (commit 0c7b867, March 19). Markdown files were being parsed as CSV and displayed as tables. The content was technically visible, but the formatting was completely wrong. A simple MIME type detection fix resolved it.

These are small changes individually. Together with versioning and proper binary storage, they made the file viewer something you’d actually want to use instead of downloading files and opening them locally.

Desktop VFS proxy

One more piece of the file system puzzle: desktop app integration. Our desktop app lets users run agents locally, but those agents need access to the same workspace files as the cloud environment. On February 24 (commit d149b87), we shipped a VFS proxy that lets desktop app agents read and write workspace files through the same virtual file system API.

This means version history works identically whether a file was modified by a cloud sandbox task, a web editor session, or a desktop app agent — including the single consolidated agent from v3.0. Same versioning, same restore, same rollback. The platform evolution from chat interface to full agent platform required this kind of consistency across every surface where files get touched.

What’s next

We’re adding more syntax languages to the file viewer based on what users actually store — JSON, YAML, HTML, and CSS are the obvious next batch. The bigger feature on the roadmap is a proper diff view between file versions. Right now you can browse versions and restore them, but you can’t see exactly what changed between version 3 and version 7.

We’re also looking at version pruning. Right now we keep every version indefinitely. For workspaces with heavy agent activity, that’s a lot of snapshots. We need a retention policy that balances storage costs against the “I need to recover something from two weeks ago” use case.

The pace of shipping hasn’t slowed down. File versioning was one project among many running in parallel. But it was the one that most directly answered the question users kept asking: “What happens if the AI messes up my files?” Now the answer is simple. You undo it.