An agent that does not silently overwrite your code

The usual advice for keeping an AI agent off your work is a list of habits: commit first, work on a branch, watch the diff. Those help, but they treat a structural problem as a discipline problem. If an agent edits files as it thinks, review is impossible by design, and the fix is to change where edits land rather than to watch more carefully.

Why silent writes are the actual risk

An agent that writes to your working tree as it reasons makes review impossible. By the time you read the diff, the changes are already on disk, mixed in with your own uncommitted work. A wrong edit is not a suggestion you can ignore; it is a file you now have to untangle.

The risk is not that the model is careless. It is that the default loop — read, edit, edit, edit, report — leaves no point where a human can say no. Anything you cannot reject is something you have to clean up.

Four checkpoints before a change lands

Vortex puts four points between "the agent has an idea" and "your files changed".

• A plan you approve. Plan mode writes <workspace>/.vortex/plans/<name>.plan.md. You read the approach, edit it, or discard it before implementation starts. The plan is a file, so it diffs and it survives the session.
• Pending patches. Review mode keeps every agent file edit as a pending patch in the Changes panel. Nothing touches disk until you approve it.
• Plan-mode-safe carve-outs. Plan files, canvases, and notepads are written directly so planning stays usable, and they carve out of patch staging. Implementation edits do not.
• Git as the backstop. Approved patches are ordinary file writes, so your existing branch, stash, and commit habits still apply. Review mode is the checkpoint; git is what you fall back on.

How pending patches survive a restart

Pending patches are persisted in ~/.vortex/vortex.db, not held in memory. If you quit the app mid-review, the patches are still in the Changes panel when you come back. You can review a large change set over more than one sitting instead of deciding under pressure.

What approval and rejection actually do

• Approving a patch writes that change to disk. It is a normal file write, and it shows up in your working tree.
• Rejecting a patch discards it. The file on disk is untouched, and the change does not return unless the agent proposes it again.
• Approving one patch does not approve the rest. Each pending patch is a separate decision.

That is the difference between "the agent changed my code" and "the agent proposed a change and I accepted it".

Keeping your own work safe

Pending patches protect the agent's edits from landing unreviewed. They do not protect your own uncommitted changes from mixing into the same review.

• Commit before a long job, so the diff you review is only the agent's.
• Work on a branch when a job touches many files; approved patches are ordinary file writes.
• Keep unrelated local changes stashed so a rejected patch is easy to spot.
• Treat the plan file as the scope contract. If the plan is wrong, fix the plan before approving patches.
• Reject first and re-run. It is cheaper than approving a patch you will revert by hand.

When a patch is large

A large patch is usually a large plan. If the Changes panel is showing dozens of files, go back to the plan file and check whether the scope is what you asked for.

1. Read the plan file first and cut anything you did not ask for.
2. Approve the patches that belong to one coherent step, and reject the rest.
3. Re-run the job against the narrower plan instead of approving a change set you cannot read.

A worked sequence

# 1. Plan mode writes the approach to a file you approve
#    <workspace>/.vortex/plans/rename-config-loader.plan.md

# 2. Agent mode implements; every edit stages as a pending patch
#    Changes panel: 6 pending patches, 0 files written

# 3. You approve 5 and reject 1

# 4. A verification check defines success
#    requires exit code 0 and output containing "PASS"

# 5. Git is still your backstop
git status
git diff

The loop is understand → plan → implement → verify, with a human decision sitting between implement and verify.

Honest limits

• Review mode is a checkpoint, not a sandbox. It controls where file edits land. It does not confine the agent, and it does not make a run risk-free.
• The agent still runs commands you approve. A terminal command is not a pending patch, so read what you are approving.
• Keep your work committed. Approved patches are real writes, and git is the backstop you control.
• Verification gates are advisory in this beta. The agent does not hard-block a run on a failing gate.

Try it

Vortex is invite-only on macOS 12+. Join the waitlist for access, or read review mode and plan files for the mechanics. The comparison pages and Vortex vs Cursor cover where this fits next to an editor-first tool.