Built by the team that brought you
Sigstore
The standard for secure software attestation, used by PyPI, npm, brew, and Maven Central
Note
In the lead-up to a 1.0 release, APIs are stabilizing. API changes may still occur where necessary, but will be kept to a minimum.
Run AI agents in a zero latency sandbox in seconds and with zero setup — Claude Code, Codex, Pi, CoPilot, Hermes, OpenCode, OpenClaw and more — nono gets you up and running within seconds, with no daemon, no container, no VM, and no disk space usage. Out of the box, nono enforces a least-privilege sandbox and supports macOS, Linux, and Windows (WSL2).
From here fork the config, tweak it, theme it, make it your own, and share it with your team or the community via the nono registry.
Want to operationalise and run at scale or within your team? Engineers at some of the largest tech companies in the world use nono as part of their workflows or to run AI agents in production.
Copied by many — nono pioneered the zero-latency, zero-setup agent sandbox, and continues to innovate and lead the way in agent sandboxing.
Quickstart
curl
curl -fsSL https://nono.sh/install.sh | shmacOS / Linux (Homebrew)
Other platforms — Debian/Ubuntu, Fedora, Arch, RHEL, openSUSE, WSL2, and Nix: see install instructions.
Run it!
Search for an agent in the registry, then run it:
$ nono search opencode always-further/opencode - Official Opencode Plugin $ nono run --profile always-further/opencode -- opencode
That's it. opencode now runs with read/write access to the current directory and nothing else — your SSH keys, your cloud credentials, the rest of your disk are invisible to it.
Profiles for all the popular agents live at registry.nono.sh, secured and ready to pull. Each one bundles the right filesystem scope, network allowlist, hooks, skills and more.
Make it your own!
Outgrow the defaults? Scaffold a profile and tweak it — same command you already know:
nono profile init opencode --extends always-further/opencode nono run --profile opencode -- opencode
nono profile init exports an extended and editable profile file for your agent, that inherits from the specified base profile. That profile is composable JSON, so you can review the exact filesystem, network, credentials, and tool rules before sharing it with a team or publishing it for the community.
Are you an agent developer and want to publish your own agent package? We would love to have you and promote your work! See the docs.
Sandbox the tools agents call
nono does not stop at "put the agent in a sandbox". Agents delegate real work to tools: git, gh, curl, kubectl, package managers, build scripts, MCP clients / servers, and whatever else is on PATH. Those tools are often where secrets, network access, and side effects show up. Most sandboxes just give the agent a blanket policy where a secret is universally available to the entire agent and every tool, but nono is different:
nono can put delegated tools in their own isolated child sandboxes, outside the agent's control. The agent gets its session sandbox; when it calls a controlled tool, nono's broker launches that tool with a separate policy, separate filesystem grants, separate network rules, and separate credentials. The tool does not inherit the agent's broad --allow grants, CWD access, raw credential paths, or network access unless its own policy says so.
That means a profile can express rules like:
- the agent may call
git, butgitonly gets the repo, trusted Git config files, and the Git object store - the agent may call
gh, butghonly receives a GitHub token through nono's credential proxy - that token may only be used against selected GitHub API methods and paths through L7 filtering
gitmay callsshunder a chained policy, while directsshfrom the agent stays denied
The policy lives in the profile, not in the prompt. The agent can ask for a tool, but it cannot widen that tool's sandbox, mint new keys, or bypass endpoint policy from inside the session.
{
"command_policies": {
"credentials": {
"github-api": {
"type": "proxy",
"upstream": "https://api.github.com",
"credential_key": "keyring://gh:github.com/example?decode=go-keyring",
"env_var": "GH_TOKEN",
"inject_header": "Authorization",
"credential_format": "Bearer {}"
}
},
"commands": {
"gh": {
"from": {
"session": {
"sandbox": {
"fs_read": ["."],
"credentials": [
{
"name": "github-api",
"endpoint_policy": {
"default": "deny",
"allow": [
{ "method": "GET", "path": "/repos/nolabs-ai/nono/issues/**" }
]
}
}
]
},
"invocation_policy": {
"default": "deny",
"allow": [
{ "argv": { "prefix": ["issue", "list"] } },
{ "argv": { "prefix": ["issue", "view"] } }
]
}
}
}
}
}
}
}Read more in Sandboxed Tool Execution.
Ready to go deep?
Head over to the docs and discover nono's rich composable policy system, credentials injection, L7 filtering, supply chain security, rollback, multiplexing, audit and more.
Library support
nono provides FFI bindings for Rust, Python, TypeScript, and Go.
Also available as Python, TypeScript, and Go bindings.
Contributing
We encourage using AI tools to contribute. However, you must understand and carefully review any AI-generated code before submitting. Security is paramount. If you don't understand how a change works, ask in Discord first.
Security
If you discover a security vulnerability, please do not open a public issue. Follow the process in our Security Policy.
License
Apache-2.0
