How AVL Code Is Designed to Prevent a “GPT-5.6 Wipes a Founder's Entire Drive in One Command”

Between safety and convenience, AVL Code leans toward safety — while still giving users ample choice and control.

In the small hours of July 11, Beijing time, AI startup founder Matt Shumer posted on X: "I'm so angry… this feels like something that should happen with GPT-3.5. Not a mid-2026 frontier model on the highest reasoning level."

As for what happened, X user @AYi_AInotes posted a detailed breakdown that morning: on his own Mac, Matt had granted the local agent Full Access, and had a subagent carry out a routine file cleanup — a task of the same kind that had already run hundreds of times before. This time, GPT-5.6-Sol failed to expand the $HOME variable correctly, and the command that actually ran became rm -rf /Users/mattsdevbox. By the time Matt noticed something was wrong and killed the process by hand, most of years' worth of code, files, and photos were already gone. Afterward the agent produced an incident report, admitting the path-expansion error. The report was written in earnest; the files could not be recovered.

1. More Dangerous Than the Accident Is “It Never Failed the Hundreds of Times Before”

The most alarming piece of information in this accident is not that the model made a mistake, but that one line of background: the same cleanup task had already run safely hundreds of times before.

A person grows practiced after hundreds of successes; a model does not. Its failures are probabilistic: the odds of an error on the five-hundredth run are not much lower than on the first, while human vigilance keeps declining with each success — this is exactly the "hit Enter without reading the diff" stage we described in The AI Coding Maturity Curve. The difference is that this time the price was no longer low-quality code, but an entire hard drive.

Break the accident down and it is three factors stacked together: full privileges always on, a destructive command, and long unsupervised autonomous operation. Remove any one of the three and the loss would still be within recoverable range. So this is not a question of prompt quality, nor something to be solved by hoping the next generation of models will be more reliable — a probabilistic capability must be paired with deterministic constraints; and those constraints cannot rely on the model itself, they have to be built into the harness layer (on how much the harness affects outcomes, The Specialized Harness Beat the General-Purpose One offers a measurable comparison). This is also the division of labor behind how we built AVL Code: capability comes from the model, constraints come from the harness.

What follows lays out, one by one, where AVL Code places its gates.

2. Behavior Is Visible: The Process Can Be Inspected, Without Your Having to Be There

Matt happened to catch the agent deleting files. Visibility is meant to address exactly this: knowing what the agent is doing and what it has done, without depending on the user happening to be present.

In AVL Code, every tool call is its own card in the session stream: the tool name and a summary of its arguments are visible at a glance, and exceptions like a rejected call or a failed connection carry a clear status marker. The arguments a command carried and the results it returned are right there in the conversation, no log-digging required. These calls and results are all written into the session record, restored exactly as they were when you reopen it; context compaction is append-only — the original records are never physically deleted, only marked as no longer entering the context window. Each execution of a hook also leaves a system message in the conversation stream. It is not a black box.

For the global view, the "Trace" panel reconstructs every tool a run called into a timeline: the order of calls, the duration and success or failure of each step, per-tool duration percentile statistics — and any step can be located back to its corresponding position in the message stream. The unrestricted mode mentioned later — the setting that skips even the approval dialog — logs each toggle of its switch, and the operations performed while it is on are still written into the session record as tool calls.

The same holds for subagents: the system instructions it received, its task input, and every single tool call can all be expanded and inspected one by one.

This visibility machinery we apply to ourselves first: every case on our website comes with an uncut session replay, the reasoning, tool calls, errors, and recovery all inspectable end to end (see Why AVL Code Publishes Its AI Sessions on Our Website). We can afford to make it public because every step was on the record to begin with.

3. Actions Are Controllable: Every Kind of Action Has a Gate, and Every Gate Has Levels

Visibility solves "knowing"; controllability solves "blocking". Every tool in AVL Code has a three-state switch — enabled, ask, disabled: enabled lets it through directly, ask pops up a confirmation before each call, disabled refuses outright; the three states can be configured separately across the five working modes — auto, plan, prepare, execute, and assess. The workflow we recommend is plan first, then execute: once you enter the plan state, from the next turn on the tool set exposed to the model is trimmed to a read-only set — this is not a prompt-level convention but a hard trim at the environment layer; after the plan is confirmed, "exit plan, enter execute" is an explicit action.

For several classes of high-risk actions: terminal commands use a built-in allowlist, with pass and block rules that can be customized per working mode and that support regular expressions — for example, writing a command like rm -rf / into a block rule; git operations such as push, merge, and rebase can be set to "pop up a confirmation before every run"; write operations that modify MCP configuration use a two-step process — the first step returns only a dry-run preview, and the write happens only after explicit confirmation, so no destructive change can be completed in a single step; threat intelligence by default only does hash lookups and does not send file contents out, sensitive files such as secret keys are never uploaded under any configuration, and when sample contents genuinely need to be sent out there is a separate, independent confirmation step.

Approval is not limited to the desktop: the same approval request is pushed to both the desktop and any bound IM at once, and replying /approve or /deny in WeChat works just as well, with whichever side responds first taking precedence; each approval request carries a unique ID, and any "always allow" grant you have checked is persisted per workspace, viewable and revocable. Thirty seconds with no response is treated as a denial — a timeout defaults to refusal, not to letting it through.

For short instructions there is an even earlier gate: intent restatement, on by default — the agent first restates the goal and execution approach as it understands them, and only begins once you confirm. The $HOME expansion error happened at the execution layer, but more accidents have already gone off course at the intent layer.

4. Boundaries Drawn First: What Can Be Accessed Is Settled Before Entry

Boundaries begin with choosing the workspace: paths are checked after symlink resolution, and sensitive locations — system directories, the home directory itself, ~/.ssh, along with their entire subtrees — cannot be set as a workspace. When you need to access a directory outside the workspace, it must be explicitly attached, in one of two tiers, read-only or read-write; attaching requires confirmation, and the grant is scoped per session — a write to a read-only attached directory is refused outright by the backend. The network has boundaries too: networking tools allow only the http(s) protocol, the target address is resolved from the first connection through every redirect, and intranet, loopback, and cloud metadata addresses are all blocked.

The strictest stretch of boundary is reserved for the most dangerous material. AVL Code's users handle malicious samples every day, and the samples/ directory under the workspace is a purpose-built analysis sandbox — nothing inside it may be executed, a rule that outranks all user configuration and cannot be lifted even by editing the config files. Before any execution-type action takes place, the target also goes through a threat check — by default only a hash lookup, with no file contents sent out.

The value of a boundary is that it comes first: it turns "what the agent can access" from something uncertain at each execution into an agreement already settled before entry.

5. High Privileges Do Not Stay Resident: The Dangerous State Is Hard to Enter, Easy to Leave

Back to where the accident started: Full Access, and left on for the long term.

AVL Code has a setting where every privilege is opened up too — the unrestricted mode. But it is deliberately designed to be hard to enter, easy to leave, and non-persistent: entering requires passing a risk-confirmation dialog whose wording is explicit — "Once enabled, the agent in this session will no longer surface any execution approval, and may run arbitrary commands and access any network address, including the intranet and the local machine"; the confirm button carries a 5-second cooling-off period and cannot be clicked before the countdown ends; while it is on, a danger indicator stays fixed in the interface, and it can be turned off with one click at any time; its scope is isolated per session, held only in memory, and cleared on restart. What it opens up is the approval dialog, the command allowlist, and the intranet-address filter — the user can enter this state, but will know clearly that they are in it, and it will not quietly carry on as the normal state without their noticing.

The same standard applies to operations on the product itself: none of the destructive buttons in Settings use a native dialog that takes effect on a single click — the first click does not execute, it only enters a pending-confirmation state with a countdown (3 seconds for a cleanup, 5 seconds for a full reset), and only a second click actually carries it out; for cleanup categories that involve sensitive data, a snapshot is generated automatically before execution, so you can roll back to a point close by.

6. Loss of Control Can Be Stopped: Subagents Are Always Under Control

The direct executor of this accident was an unsupervised subagent.

In AVL Code, when subagents run in parallel each branch is its own context, invisible to the others, and the failure of a single branch does not affect the whole batch; a single parallel run holds at most 16 branches, and the ceiling on background tasks running at once is 64. On the time dimension there are three layers of watchdog: an individual tool times out after 10 minutes idle, a subagent times out after 15 minutes idle, with an absolute cap of 60 minutes — there is no such thing as a subagent running for a long time that no one knows about.

When you need to stop, a single action stops everything: the stop operation first cascades down to terminate all spawned subtasks, then stops the main assistant, leaving no orphan processes. Matt could only rush to the computer and kill the process by hand; in AVL Code, that action is one click, and the termination is thorough. Interrupted tasks do not resume on their own either: after a restart they are listed in a banner, and whether to resume or ignore them is the user's decision; auto-resume is off by default, and even when it is on, at most 5 are auto-resumed at a time.

7. Red Lines: Unaffected by Any Switch

Every gate up to now has a switch — which is reasonable, since different tasks call for different scopes of permission. But the last layer has no switch. Even with unrestricted mode on, the following hard lines are unaffected:

• the samples/ sandbox — no execution of anything inside the directory, at a priority above any user configuration;
• argument checks on destructive commands — every path argument to rm, mv, or cp must lie within the workspace, absolute paths are refused across the board, and --no-preserve-root is blocked outright;
• the dangerous-injection blacklist — patterns such as fork bombs, writes to /etc, curl | sh, and eval are blocked before the allowlist even gets to rule;
• the protocol allowlist — only http(s) is allowed.

This is not marketing language but the product's own wording in the unrestricted mode confirmation dialog: "Only the hard-line blocks are kept: rm -rf-style destructive deletion, the samples/ sandbox, and dangerous injection."

Look back at Matt's command: rm -rf /Users/mattsdevbox — an absolute path, a target outside the workspace, falling squarely within what the argument checks explicitly block, even with every switch turned to its most permissive. We still would not say "this guarantees no accident can ever happen"; no engineering can make that promise. The point of a red line is that when the worst mistake does arrive, the system is not defenseless.

The Model Runs on Probability; the Harness Is Not a Gamble

At the end of the breakdown thread, @AYi_AInotes offered four lessons. We agree completely with the first three; the fourth — "model vendors have different safety bottom lines," with Matt saying the episode made him trust another vendor's model "a thousand times more" — we agree with only halfway. A model's caution is worth using as a basis for selection, but not as a basis for safety: however cautious, a model is still probabilistic, and entrusting critical data to probability is not fundamentally different from leaving Full Access on all the time.

Norbert Wiener, the founder of cybernetics, wrote in the journal Science in 1960:

If we use, to achieve our purposes, a mechanical agency with whose operation we cannot efficiently interfere once we have started it — because the action is so fast and irrevocable that we have not the data to intervene before the action is complete — then we had better be quite sure that the purpose put into the machine is the purpose which we really desire.

Sixty-six years later, "so fast and irrevocable" is a precise portrait of that one rm -rf. Behavior that is visible, actions that are controllable, boundaries, cooling-off periods, watchdogs, red lines — it all comes down to the same sentence: between "a single mistake" and "irrecoverable loss," place enough deterministic constraints. These mechanisms are written into the user manual and the reference manual, and they run exactly as described in the sessions behind every public case on our website — not a promise added after the accident, but a design the product has had since its very first version.

We'll be waiting for you in AVL Code, to rein the cyber donkey — the reins always in your hands.

AVL Code — the AVL security engine, with intelligence at your side. From the Antiy Landi team.