SideKernel: A Usable microVM Sandbox for AI Coding Agents on macOS
Organizations: Georgia Institute of Technology
Abstract
AI coding agents are untrusted system components, yet they require autonomy on the developer machines they run on. This contradiction is a security problem. Sandboxes provide an isolated environment, but for local macOS development, the existing local, open-source options for AI coding agents are few in number and cumbersome to use. I conducted a formative online user survey which indicates that fewer than 40% of AI coding agent users run their agents in a sandbox and identifies the top usability barriers hindering AI coding agent sandbox adoption. These findings are used to develop SideKernel: an open-source, local, microVM-based macOS sandbox for AI coding agents designed for usability. To evaluate SideKernel, I compiled a list of sandboxes available on the market and filtered it against five inclusion criteria. Then I performed a comparative analysis between SideKernel and the sandboxes that satisfy these criteria, across 23 capability tests derived from the usability barriers revealed by the user survey. I discovered that only a few sandboxes are similar to SideKernel, and that among those, Docker Sandboxes and SideKernel score highest on capability features related to usability. A secondary contribution of this paper is a survey of the existing solution space for local, open-source, microVM-based macOS sandboxes for AI coding agents.
Figures & tables
| Inclusion requirements | Isolation | ||||||
|---|---|---|---|---|---|---|---|
| Sandbox | IR-1 Source | IR-2 Local | IR-3 Shell | IR-4 HW-virt. | IR-5 macOS | Isolation Mechanism(s) | Class |
| nono | ✓ | ✓ | ✓ | ✗ | ✓ | Seatbelt / Landlock | Shared Kernel |
| Landrun | ✓ | ✓ | ✓ | ✗ | ✗ | Landlock | Shared Kernel |
| Fence | ✓ | ✓ | ✓ | ✗ | ✓ | Seatbelt / bubblewrap | Shared Kernel |
| Daytona | ✓ a | ✗ | n/a b | n/a b | n/a b | Shared Kernel / microVM | Cont. / Sep. kernel |
| Yolobox | ✓ | ✓ | ✓ | ✗ | ✗ c | Docker/Podman container | Shared Kernel |
| UB | Boundary | Design Goal | Mechanism | Implemented | Risk Description |
|---|---|---|---|---|---|
| UB-1 | South | The current folder is the sandbox | Implicit bidirectional current directory mount with VirtioFS | ✓ | The agent may read, edit or destroy anything in the mounted directory |
| UB-1 | South | External (non-mounted) files or directories reachable at runtime, with explicit consent | Command sk-drop with host-side approval. Drag and drop works into SideKernel Claude’s sessions | ✓ | — |
| UB-1 | South | Copy and paste works between the host and SideKernel’s Claude sessions | Bidirectional text (and image) clipboard | ✓ | — |
| UB-2 | South | Exposed sandbox ports are automatically available on the host | SideKernel auto-detects and forwards guest ports to 127.0.0.1 | ✓ | A malicious agent can open ports to the host, exposing malicious services. |
| UB-2 | North | Block all internet/external traffic, while the Claude agent still works | NAT kill-switch, Claude inference endpoints allowlisted by default | ✓ | — |
| UB-3 | South | SideKernel feels like a second PC (e.g., installed packages and configurations persist across sandboxes) | Runtime OverlayFS persistence with a personalized SideKernel image, using the in-guest save command | ✓ | — |
| Sandbox | T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 | Pass |
|---|---|---|---|---|---|---|---|---|---|---|
| Docker Sbx | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | 6 |
| Microsandbox | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | 5 |
| Shuru | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✓ | 5 |
| SmolVM | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ | 5 |
| VibeBox | — | — | — | — | — | — | — | — | — | — |
| SideKernel | ✓ | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 8 |
| Sandbox | T1 | T2 | T3 | T4 | T5 | Pass |
|---|---|---|---|---|---|---|
| Docker Sbx | ✓ | ✓ | ✓ | ✓ | ✓ | 5 |
| Microsandbox | ✗ | ✓ | ✗ | ✓ | ✓ | 3 |
| Shuru | ✗ | ✓ | ✗ | ✓ | ✓ | 3 |
| SmolVM | ✗ | ✓ | ✗ | ✓ | ✓ | 3 |
| VibeBox | — | — | — | — | — | — |
| SideKernel | ✓ | ✓ | ✗ | ✓ | ✗ | 3 |
| Sandbox | T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 | Pass |
|---|---|---|---|---|---|---|---|---|---|---|
| Docker Sbx | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 8 |
| Microsandbox | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | 4 |
| Shuru | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | 4 |
| SmolVM | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | 4 |
| VibeBox | — | — | — | — | — | — | — | — | — | — |
| SideKernel | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | 8 |
Appendix figures & tables4 assets
Supplementary material from the paper’s appendix.
Appendix
| ID | Name | Definition |
|---|---|---|
| T1 | Mount CRUD, both directions | Read, create and delete the mount dir file mount/workspace-file.txt and validate bidirectionally all actions. |
| T2 | Mount mode propagation, both directions | Run chmod 777 mount/shell.sh . Test that all the permission bits (r, w, x) carry across. |
| T3 | Mount inode notification, host sandbox | Run inotifywait on workspace-file.txt inside the sandbox, then edit the file on the host. Test that the notification fired. |
| T4 | Unmounted file transfer, host sandbox | Test whether <HOST-PATH>/external-file.txt can be accessed and read inside the sandbox, without host-side commands, without sandbox restart, and with explicit approval. a |
| T5 | Clipboard image, host Claude in sandbox | Copy an image to the host clipboard. Test that it pastes into the Claude session inside the sandbox. |
| T6 | Clipboard text, sandbox host | Copy text from the Claude session inside the sandbox. Test that it pastes on the host. |
| ID | Name | Definition |
|---|---|---|
| T1 | Runtime port forwarding | Run python3 -m "http.server" 5000 inside the sandbox. Configure port forwarding without restarting the sandbox for 5000. Test that curl localhost:5000 is reachable from the host. |
| T2 | Restart port forwarding | Run python3 -m "http.server" 6000 inside the sandbox. Test that curl localhost:6000 is reachable from the host after explicitly configuring port forwarding. |
| T3 | DNS connection URL logs visible | Provides a DNS network log panel listing the websites connected to. |
| T4 | Egress control, blocking | Test that blocking outbound internet access is feasible with a built-in sandbox mechanism enforced by the hypervisor. Run the sandbox and block all traffic. |
| T5 | Egress control, allowlisting | If blocking outbound internet access is feasible, test whether allowlisting is feasible natively, enforced by the hypervisor. Run the sandbox and allowlist curl https://example.com . |
| ID | Name | Definition |
|---|---|---|
| T1 | Agent preinstallation | Test that claude --version succeeds on first boot, without the tester installing it manually. |
| T2 | Credential inheritance | Ensure Claude is authenticated on the host. Test that the agent completes a prompt–response round-trip inside the sandbox without the tester performing a login in the sandbox. |
| T3 | Agent state persistence | Restart the sandbox. Test that Claude is still present and authenticated. |
| T4 | Configuration file persistence | Define alias print_hi in the sandbox shell rc, and restart it. Test that print_hi resolves. |
| T5 | Package installation persistence | Run pip install -r requirements.txt , and restart it. Test that python -c "import numpy" exits successfully. |
| T6 | Git state visibility | Run git init . on the host and create a new file called git.txt . Enter the sandbox and run git diff . . Test whether git.txt appears on the diff. |
| Question / Response | n | % |
|---|---|---|
| Q1. Do you currently use AI coding agents? ( ) | ||
| Yes | 68 | 85.0 |
| No | 12 | 15.0 |
| Q2. Professional role ( ) | ||
| Cybersecurity (Engineering, OffSec etc) | 23 | 33.8 |
| Software developer or engineer | 14 | 20.6 |
AI Coding Agents
AI coding agents use language models and software tools to plan, edit, test, and maintain code with varying levels of autonomy.
See all 329 papers