A Developer's Guide to a Private, Sandboxed AI Desktop

Two different things hide inside private

When developers search for a private sandbox ai desktop, they're usually asking about two separate properties at once, and it helps to split them before picking a tool. The first is confinement: can the AI agent or the code it runs escape the box and touch the rest of your machine? The second is confidentiality: does what you type, the files you open, the model's output, ever leave your machine at all?

A sandbox answers the first question. It says nothing about the second. Windows Sandbox, a Linux container and Qubes OS all confine what a process can touch, and every one of them can still have a wide-open network connection sending your data to a cloud API the moment you ask an agent inside them to do anything useful. Keep the two questions separate as you read the rest of this guide.

• Confinement: can the agent or its code reach outside the sandbox?
• Confidentiality: does your data leave the machine at all, regardless of confinement?
• A strong sandbox can still have an open network connection. The two are independent.

Windows: Windows Sandbox, built in but not everywhere

Windows Sandbox is a genuinely good option if you're on the right edition. Microsoft's own documentation describes it as a lightweight, isolated desktop environment using hardware-based virtualization for kernel isolation: a disposable VM that launches in seconds and is, in Microsoft's words, as clean as a brand-new installation of Windows every single time you open it. Closing it deletes everything inside, which is exactly what you want when you're running an untrusted script or trying an agent's suggested command without committing to it.

Two things catch people out. It ships with Pro, Enterprise, Education and Pro Education/SE, but Microsoft states plainly that it is currently not supported on Windows Home edition. And networking is enabled by default: if you want a sandbox that cannot phone out, you have to disable it yourself in the sandbox's configuration file. Windows Sandbox also only runs one instance at a time, so it isn't a place to supervise several agents in parallel.

• Disposable VM: fresh every launch, everything discarded on close.
• Available on Pro, Enterprise, Education and Pro Education/SE. Not supported on Home.
• Networking is enabled by default. Turn it off explicitly in the .wsb config file for confidentiality too.
• Only one instance runs at a time, so it doesn't fit running several agents side by side.

Linux: bubblewrap for one app, Qubes OS for everything

Linux gives you a lighter option and a much heavier one. Bubblewrap is the low-level sandboxing tool underneath Flatpak: an unprivileged user can wrap a single command in its own set of namespaces, user, PID, network, IPC and hostname, hiding the rest of the system from it and optionally cutting off its network namespace entirely. It's the right scale for confining one coding agent process without reaching for a VM.

Qubes OS goes much further. It's a full operating system built around assuming something is already compromised, using the Xen hypervisor to run each application domain in its own isolated virtual machine, called a qube, so a browser qube, a work qube and a personal qube can't touch each other even if one is breached. That's real security, and real overhead: you're running multiple virtual machines to do ordinary desktop work, which is a lot of friction for day-to-day coding and better suited to high-risk browsing or handling genuinely sensitive material than to running an AI pair programmer all day.

• Bubblewrap: per-process namespaces (user, PID, network, IPC, UTS), used by Flatpak. Can cut network access per sandbox.
• Qubes OS: Xen-based VMs per task, called qubes. Assumes compromise rather than trying to prevent it entirely.
• Qubes trades daily-use convenience for compartmentalization most coding workflows don't need.

macOS: the short version, and where the depth lives

macOS has its own sandboxing layer, Seatbelt, which both Claude Code and OpenAI's Codex build their agent sandboxes on top of, plus the option of a VM or container for a harder boundary. A separate guide covers those options in depth, what each one actually restricts and where it falls short, if you're specifically choosing a macOS sandbox rather than comparing across operating systems.

For this guide, the point that carries over from Windows and Linux stands here too: a Seatbelt profile or a VM confines the agent. Neither one, by itself, stops the agent from sending your prompts and files to whatever model answers them, because that's a network question, not a filesystem one.

The confidentiality half: keeping the AI itself private

If what you actually want is for your code and prompts to never reach a third party, sandboxing the process is the wrong tool entirely. What you want is a model that runs on your own hardware. Tools like Ollama and LM Studio run open models such as Llama, Mistral or Qwen locally, with GPU-aware builds for macOS, Linux and Windows, LM Studio does not support Intel Macs, so a prompt never leaves your machine in the first place.

The tradeoff is real. A local open model is usually smaller and weaker than a hosted frontier model, so you're giving up some capability for the guarantee that nothing you type gets sent anywhere. Plenty of developers run both: a private local model for sensitive work and a hosted one for everything else, each in its own sandboxed session so a mistake in one doesn't touch the other.

• Ollama and LM Studio run open models locally. Your prompts never leave the machine.
• LM Studio runs on Windows, Apple Silicon Macs and Linux. Intel Macs are not supported.
• Local models trade capability for actual data confidentiality.

How Forkbench fits on the Mac side

Forkbench is a desktop app for running coding agents, whichever model answers them, in real terminals on a Mac. A Thread can be locked to its own folders by the macOS kernel sandbox, so an agent confined to a Thread cannot read ~/.ssh, your other repositories or the rest of Documents, and the Vault lets a command use an API key from your Keychain by name instead of putting the value where the agent or a transcript can see it.

The limits matter here more than anywhere else in this guide. The folder lock is opt-in and does not restrict the network, so it answers the confinement question and not the confidentiality one: a locked agent can still send out anything it's allowed to read. An unpinned Vault key can still be read by the program that was run with it. And if you were hoping to run the same setup on Windows or Linux, that's in development, with no date yet.

• Folder lock, opt-in, confines reads and writes to the Thread via the macOS kernel. Doesn't restrict the network.
• Vault: an agent uses a Keychain key by name. The raw value stays out of its context.
• Windows and Linux support: in development, no date.

Choosing by what you're actually protecting against

Pick the sandbox for what you're defending against, not the one with the most features. Running an agent's suggested shell command without trusting it yet: Windows Sandbox or a disposable Linux container is enough, and both throw the whole thing away when you close it. Confining a daily coding agent to one project's folders without the overhead of a VM: bubblewrap on Linux, Seatbelt on macOS, or a tool like Forkbench that applies the kernel sandbox for you.

Handling something genuinely sensitive, where a single compromise would be a serious problem: that's Qubes OS territory, accepting the overhead on purpose. And if the real requirement was privacy, not isolation, none of the above gets you there. Only running the model locally does.

• Trying an untrusted command once: a disposable VM (Windows Sandbox) or container.
• Daily coding agent work: a lightweight, persistent boundary (bubblewrap, Seatbelt, Forkbench's folder lock).
• Genuinely sensitive work: Qubes OS, accepting the overhead.
• Needing privacy, not just isolation: run the model locally instead.