AgentRewind

AgentRewind Code Change

Inspiration

If Dropbox were founded today, what would it look like with AI in the driver’s seat? Original Dropbox solved “files everywhere” before ChatGPT. Today, the bottleneck isn’t syncing—it’s trusting AI to read and write your files without losing history or control. We wanted a cloud drive that’s AI-native: agents can edit real files, but every change is snapshotted, reviewable, and reversible. So we built AgentRewuind: AI-editable cloud files with automatic snapshots, full version history, and one-click rollback.

What we built

Snapshot before every write —Before any edit, upload a snapshot to Supabase Storage, and record a version row in Postgres. Only then do we apply the edit and push to Dropbox.
Full version timeline — Every change is tagged with metadata (change kind, reason, risk score, approval state) and stored so you can see who (human or agent) did what and when.
Approve / disapprove governance — New edits start as pending. You can approve (retention-eligible) or disapprove; on disapprove we automatically revert to the previous safe snapshot and record a revert version.
One-click rollback — Ask your agent to revert usings the same snapshot pipeline: so the history stays consistent.

MCP-first agent integration We expose tools via HTTP (/api/mcp/tools, /api/mcp/call): dropbox2_list_files, dropbox2_read_file, dropbox2_write_file, dropbox2_versions, dropbox2_revert, dropbox2_approve_versions, dropbox2_disapprove_versions. A Clawdbot plugin calls these so AI agents edit your Dropbox through our safety layer.

Team workspaces Owner generates a shareable link; collaborators sign in with their own Dropbox and join. Files stay owner-scoped; actions are attributed (owner vs editor). Activity feed and version timeline reflect who (or which agent) did what. Search over file content is wired for a semantic path

Agents & API keys Users manage API keys for external MCP clients; internal server-to-server calls can use a shared secret. The app has an Agents panel for key management and usage.

How we built it

Atomic write contract POST /api/files/write validates the user/team, downloads the current Dropbox file, generates a storage path, uploads the pre-edit snapshot to Supabase, inserts the version row with that same storage_path, then applies the edit and uploads to Dropbox. Keeping storage_path in sync between Postgres and Storage was a strict requirement we enforced in code and docs. Governance model Versions default to pending. Approve marks them retention-eligible; disapprove triggers revert (Dropbox is restored from the previous snapshot) and links the new version as a revert. Cleanup only deletes approved snapshots that meet retention rules; we have a retry endpoint for failed cleanup. MCP adapter The Next.js API implements the tool list and POST /api/mcp/call with trace headers (x-session-key, x-tool-call-id, x-actor-type). The Clawdbot plugin in integrations/dropbox2-mcp maps plugin config (base URL, root path, user/team, API key or internal secret) to HTTP calls so agents get a single, consistent interface. Auth and scoping Dropbox OAuth populates a server-side session; we support owner workspace and team links. Team join requires the recipient to be logged in and recorded in team_members. File access is always scoped by owner; actor identity is used for attribution and audit.

Challenges we faced

Storage path consistency Version rows and Supabase Storage objects must share the exact path. We documented a single convention (e.g. {user_id}/{file_id}/{version_id}{filename}) and used a shared buildStoragePath (and validation) so no write could create a version without a matching snapshot path. _Auth and team flows Supporting both “just me” and “team link” without impersonation required clear separation of resource owner vs actor and consistent use of user_id / team_id and cookies in the API. We added an internal MCP bypass (e.g. x-mcp-secret) for trusted server-to-server calls while keeping user/team context. Governance semantics Making “disapprove = revert” and “revert creates a new version” clear in the UI and in the data model took a few iterations so that the timeline and activity feed always told a coherent story. Scope control We deferred real-time co-editing, delta compression, and full async job queues to keep the MVP shippable: synchronous write path, full snapshots, and a cleanup/retry story for heavy operations.

Dropbox 2.0 is our take on an AI-native cloud drive: trust your AI to touch your files—with a time machine and a map.