Skip to main content
Common issues and solutions when using nono.

​
Permission Denied Errors

​
Symptom

Command fails with “Permission denied” or “Operation not permitted” errors.

​
Diagnosis

  1. Check what access was granted: 
    nono run --allow . --dry-run -- command
  2. Check environment variables inside the sandbox: 
    nono run --allow . -- sh -c 'echo "Allowed: $NONO_ALLOWED"'
nono run --allow . -- sh -c 'echo "Blocked: $NONO_BLOCKED"'
  3. Run with verbose logging: 
    nono run -vvv --allow . -- command

​
Common Causes

CauseSolution
Path not in allowed listAdd path with --allow, --read, or --write
Sensitive path blockedThese paths cannot be granted (see below)
Relative path resolved differentlyUse absolute paths
Symlink target outside sandboxGrant access to the symlink target

​
Sensitive Paths

These paths are always blocked, even if a parent directory is allowed:
  • ~/.ssh/ - SSH keys
  • ~/.aws/ - AWS credentials
  • ~/.gnupg/ - GPG keys
  • ~/.kube/ - Kubernetes config
  • ~/.docker/ - Docker credentials
  • Shell history files
  • Shell configuration files
Why? These paths commonly contain secrets that an AI agent should never access.

​
Network Connection Failed

​
Symptom

Commands like curl, wget, or API calls fail with connection errors.

​
Possible Causes

  1. Network explicitly blocked - You used --net-block flag
  2. Actual network issue - DNS, firewall, or connectivity problem
  3. Application-specific issue - App needs specific configuration

​
Solutions

  1. If you used --net-block, remove it: 
    # Network is allowed by default
nono run --allow . -- curl https://example.com
  2. Check if you’re actually in nono sandbox: 
    nono run --allow . -- sh -c 'echo $NONO_NET'
# Should print "allowed" (default)
  3. Test network outside nono: 
    curl https://example.com
# If this fails, it's not a nono issue

​
Command Not Found

​
Symptom

nono: command not found
or 
error: No such file or directory: my-command

​
Solutions

  1. nono not in PATH: 
    # Add to PATH
export PATH="$PATH:/path/to/nono/target/release"
  2. Target command not in PATH: 
    # Use absolute path
nono run --allow . -- /usr/local/bin/my-command

# Or ensure PATH is set correctly
nono run --allow . -- sh -c 'which my-command'

​
Sandbox Initialization Failed

​
Symptom

Error: Sandbox initialization failed: ...

​
Linux (Landlock)

  1. Check kernel version: 
    uname -r
# Must be 5.13+ for Landlock
  2. Check Landlock is enabled: 
    cat /sys/kernel/security/lsm
# Should include "landlock"
  3. Enable Landlock (if missing): Add lsm=landlock,... to kernel boot parameters

​
macOS (Seatbelt)

  1. Check macOS version: 
    sw_vers
# Should be 10.15 (Catalina) or later
  2. Check for SIP issues: Some system integrity protection settings can interfere. This is rare.

​
Dry Run Shows Different Paths

​
Symptom

Paths in dry-run output don’t match what you specified.

​
Explanation

nono canonicalizes all paths:
  • Relative paths become absolute
  • Symlinks are resolved
  • .. and . are normalized
This is intentional to prevent symlink escape attacks.

​
Example

$ pwd
/home/user/project

$ nono run --allow . --dry-run -- command
Capabilities:
  [rw] /home/user/project    # Resolved from "."

​
Child Process Doesn’t Inherit Sandbox

​
Symptom

You expect a child process to be sandboxed but it seems to have more access.

​
This Shouldn’t Happen

Child processes always inherit sandbox restrictions. If you’re seeing this:
  1. Verify the parent is sandboxed: 
    nono run --allow . -- sh -c 'echo $NONO_ACTIVE'
# Should print "1"
  2. Check if you’re testing correctly: 
    # Parent and child are BOTH sandboxed
nono run --allow . -- sh -c 'sh -c "cat /etc/passwd"'
# Should fail if /etc is not allowed
If you have a reproducible case where a child escapes the sandbox, please report it as a security issue.

​
Performance Issues

​
Symptom

Commands run slower under nono.

​
Explanation

There is minimal overhead from sandbox initialization (microseconds). If you’re seeing significant slowdowns:
  1. First run may be slower due to path canonicalization
  2. Many file operations may show overhead from kernel permission checks

​
Solutions

  • Grant access to larger directories instead of many individual files
  • Use --read for directories that don’t need write access (slightly faster path)

​
Using Environment Variables for Debugging

When running inside nono, these variables are set: 
# Check if running under nono
nono run --allow . -- sh -c 'echo $NONO_ACTIVE'

# See what paths are allowed
nono run --allow . -- sh -c 'echo $NONO_ALLOWED'

# See what paths are blocked (sensitive)
nono run --allow . -- sh -c 'echo $NONO_BLOCKED'

# Check network status
nono run --allow . -- sh -c 'echo $NONO_NET'

# Get help text for requesting more access
nono run --allow . -- sh -c 'echo $NONO_HELP'

​
Platform-Specific Issues

​
macOS: “killed: 9” or Immediate Termination

This usually means the Seatbelt profile was malformed. Run with -vvv to see the generated profile: 
nono run -vvv --allow . -- command

​
Linux: “Landlock not supported”

Your kernel may not have Landlock enabled. Check: 
# Verify kernel version
uname -r

# Check LSM list
cat /sys/kernel/security/lsm

​
Linux: Network Restrictions Not Working

Network filtering requires Landlock ABI v4 (kernel 6.7+): 
# Check kernel version
uname -r

# If < 6.7, network filtering is unavailable via Landlock

​
Getting Help

If you’re still stuck:
  1. Search existing issues: GitHub Issues
  2. Open a new issue with:
    • nono version (nono --version)
    • OS and kernel version
    • Full command that failed
    • Error message
    • Output of nono run --dry-run with same flags