Review mode

Review mode is the second control point in the loop. Plan review happens before implementation; Review mode happens after, when the agent has edits to show you. Every agent file edit becomes a pending patch instead of a write to disk.

What a pending patch is

With Review mode on, the agent produces a change and Vortex stages it. The file on disk is unchanged until you approve.

• Approve writes the patch to disk.
• Reject discards it, and the agent keeps working from the previous state.
• The Changes panel is the single home for agent edits. Each patch is a unified diff with the file path and the lines it touches.

Nothing is written behind your back, so you can point an agent at a repo you care about without a stash or a scratch branch.

Two checkpoints, not one

Plan files give you the checkpoint before code: an editable Markdown plan in .vortex/plans/. Review mode gives you the checkpoint after code: pending patches in the Changes panel.

1. Plan. Read and edit the plan file, then let the agent implement.
2. Review. Read each patch and approve or reject it.

If you only want one checkpoint, Review mode is the one that protects the working tree.

What carves out of patch staging

Plan files, canvases, and notepads are plan-mode safe. They write straight to their own locations instead of becoming pending patches, so the agent can keep planning notes while you review code.

Pending patches survive a restart

Pending patches are persisted in ~/.vortex/vortex.db. Quitting the app, switching workspaces, or restarting your Mac does not lose them: reopen the workspace and the Changes panel still holds the patches you had not reviewed.

That database also holds saved workspaces, chat sessions, runs, and traces.

Working with a large patch

A large change is easier to review in pieces.

• Read file by file. The Changes panel groups patches by file, so you can approve the mechanical files first and think about the interesting one.
• Ask the agent to split a change. "Split this into two patches: the refactor, then the behaviour change" gives you two reviewable units instead of one.
• Reject narrowly. Rejecting one patch does not throw away the rest of the run. The agent sees what you rejected and can try again.
• Re-request context. Ask the agent to explain a hunk or show the call sites before you decide.

Reviewing a patch, step by step

1. Open the workspace the run belongs to. The Changes panel keeps every staged edit for that workspace.
2. Open the Changes panel and pick the first patch. The header names the file and shows how many lines the patch adds and removes.
3. Read the unified diff. Removed lines are marked as deletions, added lines as additions, and unchanged context lines show where the change sits in the file.
4. Approve the patch to write it to disk, or reject it to discard it and keep the previous file.
5. Repeat until the panel is empty, then run your verification check.

Use ⌘K to switch modes and workspaces from the command palette, and hold ⌘ to reveal the shortcuts available in the current surface.

Review mode and verification checks

A verification check is how you say what "done" means: a command, a required exit code, and optionally a phrase that must appear in the output.

• Checks run against the workspace, so they see approved patches, not staged ones.
• Gates are advisory in this beta. A failing check is reported; it does not hard-block the run.
• Approving a patch and then running the check is the normal order.

When to turn Review mode off

Turn it off for trusted, mechanical edits where you would approve everything anyway: formatting, renames, dependency bumps, generated files, a migration script you already reviewed as a plan. Leave it on for anything that touches behaviour, configuration, credentials, or a public interface.

Limits in this beta

• Review mode stages agent edits. Plan files, canvases, and notepads are written directly to their own locations, so they never appear as patches.
• Rejecting a patch does not stop the run. The agent can propose a different approach for the same step.
• Verification gates are advisory, so a patch can be approved even when a check is failing. Read the check output before you move on.

Next steps

• Plan files — the checkpoint before implementation.
• Quickstart — the loop end to end.
• Models and keys — pick models per step.

Get an invite

Vortex is in a closed beta on macOS. Add your email to the waitlist to get an invite and a download link.