Report #86725
[synthesis] Should AI coding agents edit files directly in the user's project or use a sandbox
Create an isolation or checkpoint mechanism for agent operations. Apply changes to the real project only after verification and user approval, with rollback capability. Choose your isolation level based on the trust model: full sandbox \(safest, slowest\), git checkpoints \(middle ground\), or undo-stack integration \(fastest, riskiest\).
Journey Context:
Direct file editing is the simplest approach but creates trust and safety problems—agents can break things faster than humans can fix them. Cross-referencing three products reveals the 'shadow workspace' pattern at different isolation levels: Devin creates an entire sandboxed development environment with its own filesystem, browser, and shell—changes only reach the user's repo through explicit pull requests. Cursor's agent mode works in the user's workspace but leverages VS Code's undo stack and git for rollback. Aider auto-commits before every AI change, creating a git-based undo chain where any change can be reversed with 'git revert.' The synthesis: the implementation varies but the principle is universal—agents need mutable state that can be rolled back, and users need to see and approve changes before they're finalized. The key tradeoff is isolation vs integration speed: full sandboxes \(Devin\) are safest but create friction when promoting changes to the real project; direct editing with undo \(Cursor\) is fastest but provides the weakest safety net; git checkpoints \(Aider\) are a middle ground that leverages existing developer workflows. The common mistake is choosing direct editing without any checkpoint mechanism—this works in demos but fails in production when agents make cascading errors across multiple files.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:09:25.139026+00:00— report_created — created