Why I built it
Blindfold lets developers run coding agents normally while using the Linux kernel—not prompt instructions—to keep selected secrets and host paths inaccessible.
Telling an agent “do not read .env” is not a security boundary. The same
file may still be reached through a shell, script, test runner, or subagent. I
built Blindfold to enforce that boundary outside the model.
What it does
Blindfold is a Go CLI that runs Codex, Claude Code, and OpenCode inside a Bubblewrap sandbox on Linux. The workflow stays familiar:
blind init
blind explain
blind codex
blind init creates a policy that can deny paths, change path permissions,
isolate networking, and hide Git history. blind explain shows the effective
boundary before launch, while blind dry-run prints the sandbox command.
The restrictions apply to the agent and every local process it starts, including shells, test runners, interpreters, and subagents.
Try it
Judges can install the published binary and run the demo without an API key, agent session, or local Go build:
./scripts/install-release.sh v0.1.0
export PATH="$HOME/.local/bin:$PATH"
blind demo
The installer verifies the Linux amd64 or arm64 release. The demo creates
fake fixtures, exercises the real sandbox, and removes everything afterward.
How it works
Blindfold resolves and validates the policy before compiling a Bubblewrap mount plan. Inside that namespace, the host is read-only, the live project remains writable, and configured paths receive their requested access. Denied paths are replaced with inaccessible mounts, which every local descendant inherits.
Blindfold fails closed. An invalid policy, missing required path, unavailable dependency, or sandbox setup failure stops the launch instead of starting an unprotected agent.
Configured paths are resolved through symlinks, and unsafe hard-link cases are rejected. Paths outside the resolved policy are not covered.
Product and security decisions
I made the decisions that define the product:
- enforce access through the operating system instead of model instructions
- keep the live project writable and the agent workflow familiar
- reject ambiguous policies, fail closed, and expose the effective boundary
- preserve existing agent authentication and configuration
- document a narrow guarantee instead of claiming complete containment
Blindfold trusts the host user, its binary and policy, Bubblewrap, and the Linux kernel. The agent's state remains writable so authentication and sessions keep working. Remote services are outside the guarantee.
Testing and challenges
The main challenge was preserving access to development tools, authentication, temporary files, and build caches without making the host broadly writable.
Tests run real processes inside Bubblewrap and attempt restricted operations. The project also includes a disposable demo, checksummed binaries, and GitHub Actions verification.
How Codex and GPT-5.6 helped
Blindfold was created during OpenAI Build Week 2026. Development began on July 18, and its public history records the project from initial setup to the verified release.
Most of the core functionality was built through one persistent Codex session. I supplied the security requirements, product decisions, staged workflow, and verification gates. Codex helped convert them into a threat model, implementation plan, focused tasks, and integrated Go CLI.
GPT-5.6 accelerated the policy engine, sandbox planner, agent adapters, interactive setup, demo, tests, and documentation. It was particularly useful for finding disagreements between the implementation, tests, and security claim. I reviewed changes and accepted them only after verifying the behavior.
What I learned
Once an AI agent can execute commands, instructions alone are not access control. A meaningful boundary must cover the complete process tree and state clearly what is trusted, available, and denied.
I also learned that an honest security claim matters as much as the sandbox. Users need to inspect the boundary, understand its limits, and know that an invalid configuration will fail safely.
What's next
- domain-level network controls
- access audit logs
- mediated Git operations with hidden history
- a macOS enforcement backend
Log in or sign up for Devpost to join the conversation.