Preview-first editing: coloured diffs before anything touches disk

Rysh agents don't edit your files and tell you afterwards. You see the diff — green, red, cyan — and the write waits for you.

There are two kinds of AI coding tools.

The first kind edits your file and then tells you what it did. If you don't like it, you get to archaeology your way back with git diff and hope the agent didn't touch anything you weren't watching.

The second kind shows you exactly what it wants to do — as a diff — and waits.

Rysh is the second kind, and we think that's not a UX preference. It's the difference between an agent you tolerate and an agent you trust.

The flow: propose → diff → approve → write

When a rysh agent wants to change a file, it uses the edit tool (targeted string replacement — a single old/new pair, or an atomic batch of edits) or file_write (full file). Both follow the same preview-first approval strategy:

1. The agent computes the change.
2. Rysh renders it as a unified diff in the pane.
3. The write does not happen until you approve.

That ordering is the whole feature. The diff isn't a receipt; it's a request. Disk state doesn't move until a human says so.

And it's honest at the failure boundary too: edit requires the old text to match the file exactly and uniquely, so an agent can't fuzzy-match its way into editing the wrong block. When the agent batches multiple edits to one file, they apply atomically — all or none. No half-applied refactors.

Coloured diffs, because reviewability is a rendering problem

A diff you won't actually read is security theater. So rysh renders edit previews the way your eyes already know how to parse them, via a diff colourizer in the shared agentic engine:

• green for additions
• red for removals
• cyan for hunk headers

Twenty years of git diff trained you to read this format at a glance. Rysh doesn't make you learn a review UI; it uses the one burned into your visual cortex.

The subtle part is that the same diff is rendered three different ways for three different readers:

• You (local terminal): full ANSI colour. Optimized for a fast, accurate human decision.
• The model: plain text. The agent's tool result carries the uncoloured diff — no escape-code noise wasting tokens or confusing the conversation.
• Remote viewers: rysh can share panes with teammates, and shared output is ANSI-stripped — so someone watching your session from another machine sees a clean, readable diff, not \x1b[32m soup.

One change, three audiences, each getting the representation that serves them. That's what "observable by design" means in practice.

"Doesn't approval slow the agent down?"

Yes — at exactly the moments it should.

Rysh doesn't gate everything. Reading files, grepping, running the test suite: free. The gates sit on the operations that change the world — file writes, and shell commands that mutate state. That's a deliberate two-tier design:

• Preview-first (edits, file writes): do the work, show the diff, await approval. You judge the actual change, not a description of it.
• Pre-approval (git_commit, mutating shell commands): show the intent, get the yes, then execute.

The asymmetry is the point. For an edit, the best evidence is the diff itself, so rysh produces it before asking. For a commit or a destructive command, you want to say yes before anything runs.

In practice the tax is small and the return is compounding: because every change passes in front of your eyes, you catch drift in seconds — the agent renaming something it shouldn't, touching a file outside the task — instead of discovering it three commits later. Cheap review now beats expensive archaeology later.

Trust is a ratchet, and diffs are the teeth

Here's the thing nobody tells you about adopting agents: the blocker isn't capability. Claude (which rysh runs on, with your own API key) is plenty capable. The blocker is that you can't extend trust to a process you can't see.

Preview-first editing turns every file change into a visible, reviewable, deniable event. Early on, you read every diff. After a while, you know this agent's edits to test files are reliably fine, and you skim those. Later still, you're reading closely only when it touches the payment code. Your attention goes where the risk is — but the option to see everything never goes away.

That's the model rysh applies everywhere, not just to edits: every tool call visible in the pane, dangerous ones gated, all of it on your machine (rysh is self-hostable — your files never route through anyone else's infrastructure to get edited).

An agent that changes your code in the dark is a liability with good manners. An agent that shows you the diff first is a colleague.

Read the green. Read the red. Then say yes.

Want agents editing real code with your team? We're recruiting design partners — direct line to the founders, roadmap shaped by your workflow: rysh.ai/design-partner.

More in this series: Approval gates: deciding which operations deserve a human · The bash allowlist: safe-by-default shell execution for agents