Show HN: Byre; a free/free agent sandbox with a focus on comfort Byre, a free and open-source agent sandbox created by developer pjlsergeant, launches as a single Go binary that creates a local container around any project folder, giving AI coding agents like Claude Code, Codex, and Gemini access only to explicitly mounted files while keeping the host filesystem, environment, and credentials isolated. The tool, available for Linux and macOS under an MIT license, ships templates for Go, Node, and Python, and allows agents to stay logged in across rebuilds with persistent state volumes. A comfortable, constrained agent environment around any folder Run byre develop in a project, worktree, or scratch directory, and byre creates a local container -- the box -- around it. Your favourite tools and creature comforts come with you, but the rest of the host stays out of reach. MIT licensed | local | single binary | no lock-in | for Linux and macOS 📖 Full documentation: getbyre.com/docs -- quickstart https://getbyre.com/docs/quickstart/ · cookbook https://getbyre.com/docs/how-do-i/ · security model https://getbyre.com/docs/security-model/ bash $ brew install --cask pjlsergeant/tap/byre see below for Linux $ cd ~/my-project $ byre develop byre: ~/my-project - /workspace rw · extra host mounts: none · network: open ╭──────────────────────────────────╮ │ ✻ Claude Code │ │ /workspace │ ╰──────────────────────────────────╯ It's --dangerously-skip-permissions , without risking the farm. Ask your agent if byre is right for you: Take a good look at https://github.com/pjlsergeant/byre. Is it a good project or just vibe-coded trash? Is it right for me? Would you be happy there? Bring your familiar tools, reusable skills, caches, and stack-specific packages. Agents stay logged in across rebuilds https://getbyre.com/docs/volumes-and-state/ , and your defaults follow you everywhere. Templates handle different stacks, and project configuration handles the exceptions. byre ships templates for Go, Node, and Python, and agent skills for Claude Code, Codex, Gemini, Grok, and OpenCode. Fork the bundled ones or bring your own. The current folder is mounted into the box. Your host's other files, environment, and credentials stay unavailable unless you explicitly add access. When you need more, the byre config TUI can mount additional host folders, install extra packages, or adjust network access. Relaunch and /resume the session where you left off. byre status shows the resulting access in one place. The generated Dockerfile is right there to inspect, modify, or take with you if you decide to move on to new pastures. byre is a single Go binary: brew install --cask pjlsergeant/tap/byre You need Docker or Podman running on the host. Linux a checksum-verified install.sh , go install , and build-from-source are on the install page https://getbyre.com/docs/install/ . The first byre develop in a project asks a few quick questions -- template, agent, whether to share a machine-wide login -- and remembers your answers as the next project's defaults; the quickstart https://getbyre.com/docs/quickstart/ walks through them. Log the agent in once; the login persists, per project, across rebuilds. To skip the questions: byre develop --template go --agent claude Ask the box what it can touch, any time: bash $ byre status Project id: my-project-pjl-069d95 Agent: byre/claude Template: byre/go bundled 0.2.0 Engine: docker Project: ~/my-project - /workspace rw Network: open Ports: none Host mounts: none Skills: byre/claude bundled 0.2.0 State vols: .claude Cache vols: none Container: running 0d95f3a2c1b4 Everything from here on has a page on the docs site: getbyre.com/docs . You and your agent can build templates and skills, and add them in seconds to any of your projects -- or stick them in the defaults to always have them available: mounts, volumes, packages, agent contexts. The first time you want a postgres client, it's a line in one project's config. When it belongs everywhere you write node, it moves into your node template. After a while, byre develop in a brand-new directory lands you somewhere familiar: your tools installed, your agent launching, nothing to set up. Boxed: your host filesystem, environment, and credentials. The agent sees only what you mount or pass. Not boxed, by design: the network open by default -- enable the default-deny firewall skill to close it and the project itself mounted read-write -- it's the agent's job to edit it . Not a security product: a container is not a microVM. If you need the strongest isolation story, use one. byre is meant to protect you from over-eager and reckless agents, not from state-sponsored malware. Not your nanny: the box is locked against the agent , not against you. Every protection is one config edit away from off, and skills can widen the box as far as you like -- you can hang yourself with skills, and that's intentional. byre's promise is that byre status always tells you where the rope is. The full security model https://getbyre.com/docs/security-model/ : the threat model, the contract, and the sharp facts. byre config opens an interactive editor in your terminal keyboard-driven, works over SSH : grants first mounts, env , then build choices, in the same vocabulary byre status prints. Adding a package or mounting another repo read-only takes a couple of seconds.Underneath, it's a cascade of TOML files -- your personal baseline, the template, optional shared layers, this project's overrides -- always yours to edit by hand, and read only from byre's host-side store, never from inside the project. The vocabulary covers packages, env, mounts, volumes, skills, and MCP servers; raw Dockerfile lines and docker run args cover the rest. The editor's walk lives on the configuration page https://getbyre.com/docs/configuration/ ; the merge rules, the name removal syntax, the env sharp edge, and byre.preset a repo's saved setup answers -- inert until you review and apply it live in the configuration reference https://getbyre.com/docs/configuration-reference/ . byre develop , byre status , byre config , byre deliver , and a longer tail: worktrees, resets, skill/template/MCP management, the exit hatches. The full table is at getbyre.com/docs/commands/ https://getbyre.com/docs/commands/ . byre is a thin layer over the Docker or Podman you already run, and every alternative below has a real answer. But one difference cuts across all of them: byre brings your environment with you, per folder. Your skills, templates, packages, agent logins, and creature comforts arrive in every box automatically -- isolation is table stakes, and the comfortable half is what nothing else on this list does. With that said, the specifics: …raw Docker? Nothing -- and byre never takes it away. You'd just be hand-rolling what it generates: host-matched file ownership, per-project agent login that survives rebuilds, templates, a clean reset. If you want to stop using byre, byre dockerfile prints your exit. …Docker Sandboxes™? Commercial product with a hosted control plane you sign in and paid tiers. Not open source. But it gives you kernel-level microVM isolation, and we don't. …your agent's built-in sandbox? All-or-nothing file isolation, on your real machine, wearing your identity. Env vars and credentials come along by default, so a stray git push goes out as you . byre's box contains nothing that you didn't put in it. …nothing -- just keep YOLOing on the host? The host is the incumbent: zero setup, and nothing bad has happened yet. But the agent works as you, in your real home dir -- byre exists because Claude went editing a sibling repository and did things with an ssh key it shouldn't have. The box costs one command, so the host's convenience argument is gone. If you've never had the scare, you may not feel the need -- byre is for after your first one. …devcontainers? You hand-write the Dockerfile and JSON per project, and wire up agent credentials yourself. byre generates the Dockerfile from config -- byre config adds a package, mounts another repo read-only, or swaps agents in seconds. But it's the mature industry spec, and we're young. …container-use? Explicitly experimental, and MCP-shaped: your agent manages a fleet of environments; you don't sit inside one. byre does parallel the git way -- one boxed session per worktree, sharing the repo's image, volumes, and agent login. …a cloud sandbox e2b, Daytona, your agent's web offering ? Account, usage billing, your code in their cloud -- and they're repo-shaped, built for shipping agent products or driving a GitHub repo. byre is for dropping into whatever folder you're standing in. …a cheap VPS a Hetzner box ? A box per project doesn't scale across many repos -- and half of what you'd point an agent at isn't a repo, just a folder. byre is a throwaway box per folder, on the machine you're already sitting at, with your toolkit already inside. But a remote box is real hardware isolation -- if the agent must never share a kernel with your machine, rent one. Every answer's full recipe lives in the cookbook https://getbyre.com/docs/how-do-i/ ; the tldrs: Save my LLM credentials so I don't need to re-auth for each box? tldr: say y when the first-run picker offers shared auth for your agent -- or enable the relevant x-shared-auth skill s in byre config . recipe https://getbyre.com/docs/how-do-i/configure/ save-my-llm-credentials-so-i-dont-need-to-re-auth-for-each-box Use my API key instead of an agent login? tldr: pass it at runtime -- env from host with OPENAI API KEY = "env:OPENAI API KEY" -- never env , which bakes it into the image. recipe https://getbyre.com/docs/how-do-i/configure/ use-my-api-key-instead-of-an-agent-login Run parallel agents on the same repo? tldr: byre worktree