Skip to main content
Profiles are pre-configured capability sets that define what a sandboxed process can access. They codify security policy so you don’t have to specify flags manually every time.

​
Why Profiles?

Manually specifying capabilities for every tool is tedious and error-prone: 
# Without profiles - verbose and easy to misconfigure
nono run --allow . --read ~/.claude --read-file ~/.claude/config.json -- claude
Profiles simplify this: 
# With profiles - concise and auditable
nono run --profile claude-code -- claude

​
Profile Sources

Profiles can come from three sources, in order of precedence:
SourceLocationTrust Level
CLI flagsCommand lineHighest - explicit user intent
User profiles~/.config/nono/profiles/Medium - user-defined
Built-in profilesCompiled into binaryBase - audited defaults
CLI flags always override profile settings.

​
Profile Format

Profiles use TOML format: 
[meta]
name = "my-agent"
version = "1.0.0"
description = "Profile for my custom agent"

[workdir]
# Controls automatic CWD sharing: "none", "read", "write", or "readwrite"
access = "readwrite"

[filesystem]
# Directory permissions (recursive)
allow = ["$HOME/.config/my-agent"]
read = []
write = []

# Single file permissions (non-recursive)
allow_file = []
read_file = ["$HOME/.gitconfig"]
write_file = []

[network]
block = false  # Network allowed by default; set to true to block

# See "Secrets Section" below for configuring secrets

​
Working Directory Section

The [workdir] section controls whether and how the current working directory is automatically shared with the sandboxed process. This is set per-profile so each application can declare its own CWD requirements.
ValueMeaning
noneNo automatic CWD access (default if section omitted)
readRead-only access to CWD
writeWrite-only access to CWD
readwriteFull read+write access to CWD
When a profile specifies a [workdir] access level, nono will prompt the user to confirm CWD sharing (unless --allow-cwd is used to skip the prompt).

​
Secrets Section

The [secrets] section maps keystore account names to environment variable names. Secrets are loaded from the system keystore (macOS Keychain / Linux Secret Service) before the sandbox is applied, then injected as environment variables. 
[secrets]
openai_api_key = "OPENAI_API_KEY"
database_url = "DATABASE_URL"
To use secrets from a profile, add the --secrets flag: 
nono run --profile my-agent --secrets -- my-command
See Secrets Management for details on storing secrets in the keystore.

​
Environment Variables

Profiles support these environment variables in path values:
VariableExpands To
$WORKDIRCurrent working directory (from --workdir or cwd)
$HOMEUser’s home directory
$XDG_CONFIG_HOMEXDG config directory (default: ~/.config)
$XDG_DATA_HOMEXDG data directory (default: ~/.local/share)
$TMPDIRSystem temporary directory
$UIDCurrent user ID

​
Creating User Profiles

  1. Create the profiles directory: 
    mkdir -p ~/.config/nono/profiles
  2. Create a TOML file: 
    cat > ~/.config/nono/profiles/my-agent.toml << 'EOF'
[meta]
name = "my-agent"
version = "1.0.0"

[filesystem]
allow = ["$WORKDIR"]

[network]
block = true  # Block all network access
EOF
  3. Use the profile: 
    nono run --profile my-agent --trust-unsigned -- my-agent-command

​
Profile Verification

Built-in profiles are compiled into the nono binary. User profiles can optionally be signed using minisign for integrity verification. 
# Sign a profile
minisign -Sm my-profile.toml

# nono verifies signatures automatically when present
See Profile Signing for full details.

​
Built-in Profile Policies

These profiles are compiled into nono and can be used without any configuration. Each section documents the exact permissions granted.

​
claude-code

[meta]
name = "claude-code"
version = "1.0.0"
description = "Anthropic Claude Code CLI agent"

[workdir]
access = "readwrite"

[filesystem]
allow = ["$HOME/.claude"]

[filesystem]
allow_file = ["$HOME/.claude.json"]

[network]
block = false
Grants: Read+write to working directory (via [workdir]) and ~/.claude, read+write to ~/.claude.json, full network access.

​
opencode

[meta]
name = "opencode"
version = "1.0.0"
description = "OpenCode AI coding assistant"

[workdir]
access = "readwrite"

[filesystem]
allow = [
  "$HOME/.config/opencode",
  "$HOME/.cache/opencode",
  "$HOME/.local/share/opencode"
]

[network]
block = false
Grants: Read+write to working directory (via [workdir]) and OpenCode config/cache/data directories, full network access.

​
openclaw

[meta]
name = "openclaw"
version = "1.0.0"
description = "OpenClaw messaging gateway"

[workdir]
access = "read"

[filesystem]
allow = [
  "$HOME/.openclaw",
  "$HOME/.config/openclaw",
  "$HOME/.local",
  "$TMPDIR/openclaw-$UID"
]

[network]
block = false
Grants: Read-only access to working directory (via [workdir]), read+write to OpenClaw config, state, local data, and temp directories, full network access.

​
Overriding Built-in Profiles

CLI flags always take precedence over profile settings: 
# Use claude-code profile but block network
nono run --profile claude-code --net-block -- claude

# Add extra directory access
nono run --profile claude-code --allow ~/other-project -- claude
You can also create a user profile with the same name to override a built-in profile entirely.

​
Requesting New Built-in Profiles

If you’d like a built-in profile for a tool not listed here:
  1. Open an issue on the nono GitHub repository
  2. Include:
    • Tool name and repository URL
    • Required filesystem access patterns
    • Network requirements
    • Any special considerations
Built-in profiles are reviewed for security before inclusion.