# SixWays Endpoint

> A daemon, a CLI, and a desktop app that run AI coding agents in a monitored, policy-enforced sandbox. Open source, no account, no server required.

Source: https://sixways.ai/endpoint/

## 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](mailto:beta@sixways.ai?subject=Early%20access%3A%20Endpoint)

### 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](mailto:beta@sixways.ai?subject=Early%20access) [Talk to us](https://sixways.ai/contact/)