The remote model sandbox
What happens on your machine when you share a CLI model — and exactly what is, and isn't, enforced on each operating system.
Why a sandbox exists
When you share your models, API-key providers run nothing on your machine — only the model call does, and the other person's files never touch your disk. But CLI models (Claude Code, Grok, Cursor, Devin, Cline, Antigravity) are agents that run on your computer. To do that, the other person's project is copied into a temporary folder on your machine and the CLI works there.
A temporary folder is a location, not a boundary — on its own it wouldn't stop the CLI from reading the rest of your disk. The sandbox is what confines that CLI to just the shared project.
The threat model
The sandbox is designed for the realistic risk of model sharing: a person you chose to share with, running an agent that might be careless — not a determined attacker trying to break out of your machine. It stops the agent from wandering into your secrets or tampering with files outside the project. It is not a defense against someone deliberately writing an exploit. Only share subscription-backed CLI models with people you trust, and pick the preset that matches how much you trust them.
Two layers of enforcement
1. Kernel-hardened jail (when available on Linux & macOS)
When the host capability check succeeds, Linux uses bubblewrap (the unprivileged-namespace sandbox Flatpak uses): the CLI sees a filesystem containing only the shared project and its own config — your home, keys, and other projects aren't even visible — and its network can be cut. When sandbox-exec is available, macOS uses Seatbelt (sandbox-exec): writes are confined to the project, reads of your secret stores (.ssh, .aws, Keychains…) are blocked by the OS, and the network can be cut. The kernel enforces these — the CLI can't escape them, even through its own shell.
2. Soft jail (every platform)
Underneath the kernel jail — and on its own where none exists — Koryphaios always scrubs your other API keys and credentials from the CLI's environment and redirects its home directory to a throwaway folder, so ~/.ssh, ~/.aws and the like resolve to nothing. Because almost everything reaches secrets through ~, this covers the common path on any OS.
What each OS enforces
| Host OS | Mechanism | Enforcement |
|---|---|---|
| Linux | bubblewrap when available + soft jail | Kernel-enforced filesystem jail & network block when Bubblewrap and user namespaces are available. |
| macOS | Seatbelt when available + soft jail | Kernel-enforced write confinement, secret-read blocking & network block when Seatbelt is available. |
| Windows | soft jail only | Secret scrub + home redirect. Not kernel-enforced — see below. |
Windows: why it's soft-jail only
If you host CLI models on Windows, the sandbox cannot be kernel-enforced. The soft jail still applies, but it is not a hard containment boundary.
Enforcing “this process may not read C:\Users\you\.ssh” is a job only the operating-system kernel can do. Linux and macOS expose primitives for exactly this (namespaces, Seatbelt) that an unprivileged app can invoke. Windows does not ship an equivalent per-process filesystem jail that a normal application can drive: its isolation features are either heavyweight (Windows Sandbox is a full VM requiring Hyper-V) or require native code and elevated setup (AppContainer). There is no bwrap-style command to wrap a process in.
So on a Windows host, Koryphaios applies the soft jail: it scrubs your other credentials from the CLI's environment and redirects its home directory, which stops accidental and ~-relative access to your secrets. What it cannot stop is a program that reads a secret by its full absolute path, or writes outside the project — those require kernel enforcement.
Recommendations for Windows hosts:
- Prefer sharing API-key models — those never run anything on your machine, so the sandbox is irrelevant.
- Only share CLI models with people you fully trust, or use the Read-only / Hardened presets.
- For a real kernel jail on Windows, run Koryphaios inside WSL2 — it then uses the Linux bubblewrap path.
If you're the one using someone's models
The sandbox only ever runs on the host — the machine the CLI executes on. As a client, your operating system is irrelevant: you send your project to the host and receive the edits back, and none of that involves a sandbox. A Windows client connecting to a Linux or macOS host gets the host's kernel-hardened protection when the host reports that OS isolation is available.
Configuring it
The sandbox is fully configurable per host in Settings → Teams → Share Models: presets (Balanced, Hardened, Read-only, Trusted) plus per-option toggles for the filesystem jail, network, web search, edits, and shell — with a live indicator of whether kernel-level enforcement is available on your OS.