The endpoint is free, open, and complete.

One command runs a coding agent in a container sandbox you can see inside, with eBPF recording file, process, and network activity. On macOS, Windows, and Linux, with Docker or Podman.

Get early access

~/code/api-server

sixwaysd · outside the sandbox · not visible to the agent

What's in the box.

A daemon (sixwaysd), a CLI (sw), a TUI, and a desktop app for launching sandboxes, watching live events, and browsing session history. Updates are signed and checksum-verified, and a bad release can be recalled. No account, no server, and telemetry stays on your machine.

Container isolation

Each agent runs in a Docker or Podman container with CPU, memory, and PID limits, a controlled workspace mount, and your policy's network restrictions.

Kernel-level visibility

A separate eBPF monitor container records the sandbox's file opens, process execs, and network connections from the container engine's kernel, correlates them per session, and stores them locally in SQLite.

Kernel-level enforcement

An enforcement sidecar denies the destinations and paths your policy blocks, using BPF-LSM and cgroup hooks the agent process cannot disable. Free, no license key, pulled automatically as a prebuilt image.

Agent-specific settings

Translates your policy into the native settings format of each supported agent. Detects agents running outside a sandbox and reports them.

Devcontainer monitoring

Attaches the eBPF sidecars to existing dev containers in VS Code and supported VS Code-based editors, without changing those workflows.

Session recording

PTY sessions are recorded locally, with redaction, so you can replay an agent's actions and output.

One YAML file.

It defines which agents exist, how to recognize them, and what they may do. Create it with sw init and edit it in your editor or the app; the daemon hot-reloads either way. One line sets the mode:

enforce

Denied destinations and paths are actively blocked inside the sandbox.

audit

Nothing is blocked. Violations are logged so you can tune the policy first.

simulation

Like audit, plus a report of what enforce mode would have blocked.

meta:
  id: "my-policy"
  mode: "enforce"            # enforce, audit, or simulation

container_sandbox:
  require: true              # refuse to run agents unsandboxed
  image: "ghcr.io/sixways-ai/sixways-sandbox:node"
  resource_limits: { cpu: "2.0", memory: "4096", pids: 512 }

definitions:
  network:
    exfil_sites: ["pastebin.com", "transfer.sh", "file.io"]

guardrails:
  - id: "block-exfil-sites"
    subjects: ["*"]           # all agents
    resource:
      category: "network"
      spec:
        destinations: ["exfil_sites"]
        operations: ["connect", "send"]
    action: "BLOCK"

Pick the isolation the policy needs.

Same policy, same launch command. Policy can require a level, and SixWays refuses to start an agent anywhere weaker; it never downgrades silently. The desktop app gives free users the process sandbox where the host supports it (macOS, Windows 11 for standard users, Linux as root) and the container otherwise. sw run uses the container unless policy asks for another level.

Level	How it isolates	Platforms	Edition
Container sandbox	Hardened container with resource limits, a controlled workspace mount, and eBPF monitoring and enforcement	macOS, Linux, Windows	Free
Process sandbox	OS-native confinement for agents that can't move into a container	macOS (Seatbelt), Linux (Bubblewrap), Windows 11 (Microsoft process container)	Free for local use; org-wide enforcement on Team and Enterprise
MicroVM, required mode	A hardware-virtualized guest per agent. The agent never starts before enforcement is live inside the guest, and stops if the in-guest supervisor dies	macOS and Linux (libkrun)	Pro, Team, and Enterprise
NVIDIA OpenShell	Attach to an existing OpenShell gateway; SixWays governs, inspects, and verifies its sandboxes	Wherever your gateway runs	Attach free; governance on Team and Enterprise

SixWays Sandbox: hardened images, public on ghcr.

Built on Wolfi, a minimal CVE-tracked container OS. No sudo, the agent runs as uid 1000, and the strict tier keeps the rootfs read-only. Every variant builds on the base, so any variant can host any agent.

sixways-sandbox:base

Node and Python runtimes plus a native build toolchain

sixways-sandbox:node

JavaScript and TypeScript projects

sixways-sandbox:python

Python projects

sixways-sandbox:rust

Rust toolchain

sixways-sandbox:go

Go toolchain

sixways-sandbox:devcontainer

Dev-container-compatible variant

Images at ghcr.io/sixways-ai/sixways-sandbox. A larger desktop variant exists for GUI and browser agents.

A free extension for VS Code and VS Code-based editors.

Agent attribution

Attributes file, process, network, and terminal activity to the agent extension that started it, not to the IDE as a whole, and reports it to the local daemon.

Sandboxes from the IDE

Launch CLI agents into SixWays sandboxes with live progress, or add a SixWays dev container to a project and reopen it through the IDE's Dev Containers flow.

MCP inventory

Reports MCP server configurations from a supported agent extension and from workspace .vscode/mcp.json, including inside dev containers, to the inventory the daemon governs.

Requires VS Code 1.85 or later. Telemetry goes to the local daemon only; the extension's one direct download is the signed daemon from the public release feed.

Get early access.

Tell us about your agents and your team, and we will set you up.

Get early access Talk to us