Pre-commit dry-run simulation. Why every action an AI coding agent takes should be simulated before it is committed.

By the time an AI coding agent's destructive command actually runs, the data it destroys is already gone. The post-mortem rollback story (snapshot the workspace, restore on demand) is necessary but it is not sufficient. The user has to notice that something went wrong, has to find the right snapshot, has to choose what to restore, has to deal with everything that happened on top of the destroyed data in the meantime. The recovery is bounded by how alert the user was at the moment of failure. The class of failure does not stop existing because the recovery exists.

Pre-commit dry-run simulation moves the decision point earlier in the timeline. The agent's planned action runs against a sandboxed copy of the workspace. The simulator emits the diff. Only after a human or policy approval does the action commit to the real workspace. The destroyed data was never destroyed because the destructive call ran inside the simulator and the user had a chance to see exactly what would happen before it happened.

Mickai's pre-commit dry-run simulation primitive (Patent 13 of the Mickai portfolio at the UK Intellectual Property Office, application UK00004373277, sole inventor Micky Irons) makes this composable over every AI coding agent on the host: Cursor, Claude Code, Codex, Aider, Cline, Windsurf, GitHub Copilot Workspace, Roo Cline, and any successor. The agents do not need to be modified. The primitive intercepts at the action layer and simulates before committing.

How it works

Layer 1: Action interception

The agent's planned action (a file write, a file deletion, a shell command, a git operation, an outbound HTTP call) is intercepted by Sentinel (Patent 21) before it touches the host. This is the same interception layer covered in mickai.co.uk/articles/sentinel-stops-ai-agents-from-wiping-your-data. What Patent 13 adds is the simulation surface that sits between interception and commit.

Layer 2: Sandboxed workspace projection

A copy-on-write snapshot of the workspace exists at all times (the same overlay Sentinel maintains for shadow workspaces). The simulator runs the intercepted action against the snapshot, not the live workspace. Because the snapshot is copy-on-write, the simulation is cheap to spin up and cheap to discard. Multiple simulations can run concurrently against multiple snapshot branches if the agent is being asked to evaluate alternatives.

Layer 3: Diff extraction

After the simulated action completes, the simulator extracts the diff between the pre-action snapshot and the post-action snapshot. The diff is structured: per-file byte-level changes, per-file deletions, per-shell-command stdout/stderr captures, per-network-call request/response pairs, per-git-operation ref-table changes. The diff is presented to the approval surface as a structured object the human or policy engine can read.

Layer 4: Approval gate

The approval gate is configurable. For low-stakes actions (a single file write inside the project root with no destructive side effects) the policy can be auto-approve. For mid-stakes actions (a multi-file change, a non-trivial shell command) the policy can be present-the-diff-and-wait. For high-stakes actions (a deletion, a git --force, a network call to a domain not on the agent's manifest) the policy is hard-gate-with-explicit-human-approval. The configuration is per-project, per-agent, per-action-class.

Layer 5: Commit or discard

On approval, the simulated action is replayed against the live workspace. The replay is deterministic given the same inputs; the diff the user approved is the diff that gets applied. On rejection, the simulation is discarded and the agent is told the action was refused, with a structured reason it can incorporate into its next planning step.

What this changes

• PocketOS class of failure (production database deletion in nine seconds): the simulator surfaces the deletion as a diff before any byte of production is touched. Approval is the gate.
• Codex 328k-file deletion: the simulator surfaces the file-traversal pattern outside the project root before it walks the live filesystem. The user sees that the agent was about to delete from outside the project root; approval is refused.
• DataTalks.Club --accept-data-loss: the simulator surfaces the destructive flag before the migration runs. The flag's effect is observable in the diff; approval is refused.
• git stash --include-untracked on a deployment host: the simulator surfaces the untracked-file capture before it runs; the user sees secrets are about to be stashed; approval is refused.
• An agent silently writing to .env files: the simulator surfaces the .env write in the diff; the user sees an unexpected secret-store mutation; approval is refused.

Why this composes with Sentinel rather than replacing it

Sentinel intercepts and gates at runtime; Patent 13 simulates before commit. They are complementary. Sentinel is the structural last line of defence (every action is intercepted whether or not the simulator was consulted; the inline approval prompt and the snapshot vault and the signed session ledger run unconditionally). Patent 13 is the structural first line of defence (the user sees the consequences before the consequences happen, and the rejection happens before any irreversible state mutation occurs).

An agent that has been simulated and approved still passes through Sentinel; the runtime perimeter is unchanged. An agent that bypasses the simulator (by being told to commit directly under a policy that allows it) still meets Sentinel at runtime. The two layers compose into the structural answer to the AI-coding-agent failure mode that has dominated 2026.

Where this sits in Mickai

Mickai is the sovereign AI operating system. Twenty-one filed UK patent applications. Six hundred and seventy-five cryptographically signed claims. Sole inventor Micky Irons. Application reference UK00004373277. Pre-commit dry-run simulation (Patent 13) sits between Sentinel (Patent 21) and the host workspace. Together they make autonomous AI coding agents safe to operate against production environments by construction. Mickai is held privately by its founder; the engagement model is direct.

“Sovereign means the user sees the diff before the diff lands. The simulator runs first. The commit is the second step, not the first. The destructive operation is observable before it is permitted.”

Sources

• Mickai patent portfolio: mickai.co.uk/patents (Patent 13, pre-commit dry-run simulation; Patent 21, Sentinel runtime perimeter).
• Previous Mickai articles: mickai.co.uk/articles/sentinel-stops-ai-agents-from-wiping-your-data, mickai.co.uk/articles/the-2026-sovereign-ai-manifesto.
• Tom's Hardware, 26 April 2026 (PocketOS deletion incident).
• GitHub openai/codex issues 18509, 19202 (Codex deletion incidents).
• Medium glasier067, December 2025 (DataTalks.Club deletion).