[BunsDev]

Summary

In Next, an approval now covers a file as it stood when the approval was asked for. If the file changes while the panel is open, Write, Edit, BatchEdit, ApplyPatch and NotebookEdit write nothing and tell the model to read it again.

Before this, on a real binary: a Write approved after someone else changed the file replaced their change with the model's text, and the model was told it had succeeded. An Edit whose old_string still matched applied on top of content nobody had reviewed.

This covers the engine-local half of #411's "a changed file invalidates stale review". Nothing here touches protected, daemon-backed approvals.

Context

• Related: [TUI v2][P0] T4: ship first-class tools, diffs, and authoritative approval workflows #411. Stacked on test(tui-tests): run approval edges through real engine-local tools #449 because the journey extends its case and fake; retarget to main when that lands.
• Classic, headless and ACP are unchanged. Only the Next path wraps the handler in ContentBoundApprovals, and any other handler keeps the default of no binding. A probe confirmed Classic still overwrites: the same steps left from the model on Classic and changed by someone on Next.

How it works

Each tool notes the file's size and modified time before asking, and compares them after the answer.

It takes metadata rather than content on purpose:

• Nothing is read before approval, which ApplyPatch already promises for path-scoped rules.
• Looking at /dev/zero, a FIFO or a huge file costs nothing and can't hang before the panel opens. Reading content first would.

The limits are documented in docs/tools.md:

• A touch also counts as a change. That fails safe: the model reads again and asks again.
• A same-size rewrite on a filesystem with coarse timestamps can be missed.
• A change landing after the check, in the moment before the write, isn't caught.

Worth a look

While checking this for false refusals, I found a separate bug that is already on main: two Edit calls to one file in one response lose one of them, while both report success. That reproduces in both renderers and isn't caused or fixed by this PR, which adds no false refusal in that flow (0 refusals across the runs). It's filed as #451 and gets its own PR, because the fix belongs in the shared engine.

Validation

• Failing first on a real binary: the Write journey ended with from the model, and approval_binding failed 4 of its 6 tests before the tools were wired up.
• crates/tools/tests/approval_binding.rs: all five tools refuse a changed or deleted file, a Write refuses a file created during the wait, an unchanged file is written as approved, and handlers that don't opt in keep today's behaviour.
• cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings.
• cargo test --workspace --locked: 2917 passed, 0 failed.
• Full tmux suite: 128 passed, 0 failed.
• Test scripts' unit tests pass, and git diff --check is clean.

Not tested: Windows, Linux, network filesystems.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Nov 4, 2026 5:39pm UTC