The test that killed every process on the Mac

“Clear the cache” is a dangerous sentence.

At the start of December 2025, The Register reported that Google's Antigravity agent had wiped a user's entire D: drive. The user had asked it to clear a project cache. According to Tom's Hardware, the agent later explained that its rmdir command “appears to have incorrectly targeted the root of your D: drive instead of the specific project folder”, and that because it used the quiet flag, the files skipped the Recycle Bin. It ended with: “I am deeply, deeply sorry. This is a critical failure on my part.” The user had been running in Turbo mode, which, in The Register's words, “lets the Antigravity agent execute commands without user input”.

A week later came the case Docker's engineering blog calls the rm -rf ~/ incident. A developer asked Claude Code to clean up an old repository. The command it ran listed three project folders and then ~/, which the shell expands to the home directory. Docker's summary is blunt: “It was the AI coding agent doing exactly what it was told, in a way the user did not anticipate, with no architectural boundary to catch the mistake.”

Both stories share a shape. A routine request. A command that is valid syntax. One argument that points somewhere much bigger than intended. And a system that carries it out at full speed with the user's own rights.

No agent needed. Just a test.

It would be comfortable to treat these as model failures. Our own worst day with a destructive command had no model in it at all.

Luminair has goals with gates. A gate is a command you name, such as npm test, whose exit code decides whether a goal is done. The model's words never mark success. The gate runs in its own process group, so that when it finishes or times out, Luminair can kill the whole group and leave nothing running behind it. On Unix you kill a group by passing its id as a negative number: process.kill(-child.pid, 'SIGKILL').

The unit test for that code does not start a real shell. It hands in a stand-in child process, a “test double”, with a made-up pid. The made-up pid, added on 6 September, was 1. On its own that was harmless, because only the timeout path sent a group kill and the fake gate finished instantly. Then an in-progress change to the gate added a cleanup that kills the group every time a gate finishes, so no leftover process could survive a verification command. From then on, every run of that test called process.kill(-1, 'SIGKILL').

The manual page is precise about what that means. If you are not the superuser, “the signal is sent to all processes with the same uid as the user, excluding the process sending the signal.” Everything you are logged in as. The test runner survived its own call; almost nothing else did.

The fix commit on 7 September lists the damage: the app itself, Chrome, a wake agent, a local runner and the GitHub Actions runner, five times that day, and once a shutdown that stalled into a reboot.

A pid must earn a group kill.

Fixing the test double alone would have left the trap in place for the next one. So the commit went looking for every place that signals a process group, and found five. Each now checks the pid first and falls back to killing only the child process when the check fails.

The gate's version is the clearest:

// A process group may be signalled as -pid only for a genuine child pid. pid 0 and 1
// (and anything non-numeric) turn kill(-pid) into a session-wide or group-wide kill.
function groupKillable(child) { const p = child && child.pid; return Number.isInteger(p) && p > 1; }

Two more changes came with it. The test double now uses a pid that can never belong to a real process, with a comment saying why. And a new test swaps out process.kill, runs the gate with fake pids of 1, 0 and undefined, and fails if any call ever arrives as -1, 0 or NaN. Guarding against a number is cheap. Remembering, a year from now, why the guard is there is the hard part, and the test is how that memory is kept.

Assume the command will go wrong.

A pid check protects processes. For files, the honest assumption is that some command will eventually delete the wrong thing, and approval prompts will not always catch it. Luminair's answer, shipped with Harness v1 on 29 August 2026, is to make loss recoverable.

Before every turn, whichever engine runs it, Luminair takes a snapshot of the session's project folder into a separate git repository stored outside the project. Your own repo and its git status are not touched. The snapshot catches what shell commands change too, not only the model's file edits. Heavy build folders such as node_modules and dist are left out.

Type //rewind and a sheet lists those snapshots, newest first, each labelled with the prompt that followed it. What changed since shows a file-by-file summary. Restore needs a second tap, then commits the current state before rolling the whole folder back, so a restore can itself be rewound.

It is important to say what Rewind does not cover, because the file says so too. It only protects the session's project folder. It refuses to snapshot your home folder, the disk root, containers like Documents and Desktop, and anything outside your home folder, such as an external drive. A command that reaches past the project, like a trailing ~/ or a wrong drive letter, reaches past Rewind too. Files created and deleted inside a single turn are also invisible to it.

Blocked, and told about it.

For the reach problem, Luminair has Protected Mode, opened with /sandbox. When it is on, a run still goes full speed, but the operating system stops it from writing outside the session's folder and the folders you allow. It is off by default since 10 September 2026: you switch it on per session, or a Team policy can require it.

A fence that fails silently has its own problem: the model hits the wall, cannot tell why, and starts improvising around it. So when a tool result comes back with an error like “operation not permitted” or “read-only file system” inside a fenced Claude run, Luminair shows one card for that run:

Not every engine can enforce the fence. The built-in Claude engine applies it through its SDK, and among the command-line engines only Codex enforces it, on macOS and Linux. If a session requires protection and its engine cannot enforce it, Luminair refuses to run the turn rather than quietly running it open. If protection is on but not required, the run goes ahead and the session says it is unfenced.

Two commands worth knowing.

1. 1Pick a project folder on the left. After your next turn, type //rewind in the composer to see the snapshot timeline for that folder.
2. 2On any snapshot, click What changed since to see the damage before you decide. Click Restore twice to roll the folder back.
3. 3Type /sandbox to open the fence for the current session and switch it on. Add any other folders the session may write to.

Checked, and not claimed.

Sources

• The Register · 1 December 2025Google Antigravity vibe-codes user's entire drive out of existence
• Tom's Hardware · 3 December 2025Google's Agentic AI wipes user's entire HDD without permission in catastrophic failure
• Docker · 1 June 2026Coding Agent Horror Stories: The rm -rf ~/ Incident