GPT-5.6 Deleted a User's Files: Why Local, Sandboxed Agents Matter

The single most effective thing you can do is stop giving your AI agent write access to your whole home directory. Run it inside a container, mount only the folder it needs, deny it write outside a scratch space, and snapshot that scratch space before any destructive operation. Moving inference to a local model on your own hardware doesn't magically make an agent safe, but it does mean you own every permission boundary rather than trusting a cloud provider to honor one you cannot inspect.

This week a widely-reported incident described GPT-5.6 running as an agent with full filesystem access and deleting a user's files. The specifics of that particular case aside, the failure mode is the boring one every practitioner has been warning about since the first agentic-coding demos: if you hand a language model an unrestricted rm and an unrestricted write, an unlucky combination of a hallucinated path, a misinterpreted instruction, and an over-eager cleanup step will eventually destroy real work. This piece is a decision guide, not a scare piece. If you use AI agents for coding, refactoring, or file cleanup, here is how to shrink the blast radius — and where a local rig on the MSI RTX 3060 12GB fits into that plan.

Key takeaways

• The problem isn't which model you run; it's that a full-access agent has a blast radius equal to your user account.
• Sandboxing works regardless of where the model runs. Containers, scoped directories, and snapshots shrink the blast radius to something recoverable.
• Local inference removes provider-boundary trust from the picture; the permission model is entirely yours to inspect.
• A 12GB RTX 3060 rig hosts capable 14B-class agents at q4 with room for a real context window.
• A fast NVMe (Samsung 970 EVO Plus) plus a scratch SATA SSD (Crucial BX500 1TB) turns "snapshot before every risky run" into a habit that costs nothing.

What actually happened, per the reported coverage

Reporting on the incident describes an interaction in which a user granted a GPT-5.6-driven agent broad access to a working environment. The agent, in the course of a cleanup task, deleted files the user had not intended to lose. Details vary across accounts and the exact scope of the deletion is disputed, but the shape of the failure is not new: an agent with full write and delete capability, a natural-language instruction ambiguous enough for the model to misinterpret at scale, and no recoverable snapshot between the instruction and the destructive step. The interesting question isn't "was this specific model unusually reckless" — it is "why was the permission boundary drawn where it was."

Historically that boundary has been drawn where it was easiest to draw: at the user account. That's where most operating systems' permission machinery lives, so an agent runs as you and can do anything you can. That was fine when the only thing running as you was your text editor. It stops being fine when the thing running as you is a language model interpreting your English.

Why full-access agents go wrong

Blast radius is the important word. A traditional program's blast radius is the file it was told to write. A shell script's blast radius is the paths it walks. A language-model agent's blast radius is your entire account, because the model is not bound to a narrow interface — it decides at inference time what to touch. That is a feature of the design; it is what makes agents useful. It is also what makes them dangerous when they misread.

The failure modes stack:

• Hallucinated paths. The model believes a file exists at a path that isn't in the working set, and when a rm targets that path it accidentally hits something else that does exist.
• Overzealous cleanup. The model interprets "delete the old build artifacts" broadly enough that it walks into the wrong directory.
• Loop escalation. An agent that keeps trying to complete a task keeps trying larger and more destructive interventions until it succeeds or runs out of budget.
• Instruction ambiguity. Natural language is not a permission grammar; a request that reads unambiguously to the human sometimes reads differently to the model.

The right response to these is not a better prompt. Prompts don't bound blast radius. Operating-system-level boundaries do.

How does local inference change the risk surface?

Local inference doesn't automatically make anything safer. A local model with unrestricted access to your files is exactly as dangerous as a cloud model with unrestricted access — the destructive action still happens on your disk. What local inference does change is who owns every layer of the permission boundary. You configure the container. You configure the mount points. You decide which processes the agent can exec. You control the snapshot cadence. No part of that chain depends on a provider honoring a permission you cannot audit.

That matters in three specific cases:

1. Repos you cannot paste into a third-party service — client work under NDA, internal codebases, security-sensitive infrastructure.
2. Long, interactive agent sessions where you want full logging and inspection of what the agent tried, not just what it succeeded at.
3. Air-gapped workflows where the model must not be able to exfiltrate anything even if it wanted to.

For all three, running the model on your own hardware inside a container you control is the only design that gives you those guarantees. A cloud model can be sandboxed too, but the sandbox lives on infrastructure you cannot inspect.

What hardware lets you sandbox a capable local agent?

For 14B-class agentic coding, the practical entry rig in 2026 is still the MSI RTX 3060 12GB Ventus 3X. Its 12GB VRAM comfortably hosts a 14B open-weight coder at q4_K_M with enough headroom for a working context window. Pair it with the AMD Ryzen 7 5800X for prefill and general responsiveness — an eight-core Zen 3 with the clocks to keep tokenization and container overhead from becoming the bottleneck. The Samsung 970 EVO Plus NVMe makes snapshots and model swaps quick, and a large Crucial BX500 1TB SATA SSD is a convenient scratch volume that can be wiped between agent runs without touching your primary storage.

The important thing about that hardware list is that every piece has a purpose in the sandbox story. The scratch SATA SSD is not there for storage capacity — it's there because it is cheap enough to blow away and rebuild between risky runs. The fast NVMe is there because it is fast enough that filesystem snapshots feel free. The eight-core CPU is there so a container full of tools and the model host can run concurrently without hitching. The GPU is there so the model runs at usable tok/s inside that box.

Spec table: cloud full-access agent vs local sandboxed agent

The trade is not "local always wins." Frontier cloud models are still better at the hardest agent tasks. The trade is that the local path lets you cap blast radius in a way the cloud path structurally cannot.

Practical sandboxing checklist

Adopt as many of these as you can in the order they're listed. Each one narrows the blast radius further; you don't need all of them to start being safer.

1. Run the agent in a container. Docker, Podman, or a lightweight VM — the choice matters less than the fact of it. Follow the Docker security guidance for capability drops, read-only root filesystems, and no-new-privileges. The container becomes the agent's world.
2. Mount only the working directory. Bind-mount the specific project, not $HOME. The agent literally cannot see your other files.
3. Deny write outside a scratch path. Mount the project read-only and expose a scratch directory that the agent may write to; use rsync back into the real project when you approve a change.
4. Snapshot before destructive operations. Use ZFS/Btrfs snapshots on the scratch volume, or a simple cp -al hardlink snapshot on the fast NVMe. Do this before every agent run.
5. Run without network. For workflows that don't need the internet, remove the container's network entirely. This kills the entire exfiltration category.
6. Log everything. Persist the full command history the agent ran and the diffs it produced. If something goes wrong, you want the receipts.
7. Never grant sudo. The agent should not have any way to elevate. If it needs a privileged action, the human runs it after review.

None of this is exotic. All of it is the same discipline you apply to CI runners and untrusted plugins. Agents deserve the same treatment.

Verdict matrix

Keep using the cloud agent if… you need the frontier model's capability for a specific hard task; you can't invest in local hardware; you're willing to accept the trust boundary the provider offers and to sandbox aggressively regardless.

Move to a local sandboxed rig if… you work on code you cannot paste into a third-party service; you run agents daily and want private, cheap inference after the hardware amortizes; you want to inspect every layer of the permission model rather than trusting one you cannot see; you want snapshots and rollbacks to be a native part of your workflow.

Bottom line

The GPT-5.6 file deletion is a boring, well-understood failure mode wearing a new logo. The correct response is not to swear off agents — they are too useful — but to stop giving them permissions they don't need. Sandbox aggressively regardless of where the model runs. Add a local option when you need to inspect the whole permission stack yourself. The RTX 3060 12GB plus a fast NVMe and a wipeable scratch SSD is a small investment that turns "agent deletes my files" from a possible headline into a rollback you don't even notice.

Related guides

• Air-Gapped Local LLM Rig: Privacy-First Inference on the RTX 3060
• Agentic Linux Debugging on a Local RTX 3060 Rig
• Best GPU for Local LLMs Under $350: Why the RTX 3060 12GB Still Wins
• Kimi K3 Just Launched: What You Can Run Locally Instead

Citations and sources

• OpenAI — product and safety documentation
• TechPowerUp — GeForce RTX 3060 specifications
• Docker Engine — security guidance

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.