Permission Denied Errors
Symptom
Command fails with “Permission denied” or “Operation not permitted” errors.Diagnosis
-
Check what access was granted:
-
Query capabilities from inside the sandbox:
-
Run with verbose logging:
Common Causes
| Cause | Solution |
|---|---|
| Path not in allowed list | Add path with --allow, --read, or --write |
| Sensitive path blocked | These paths cannot be granted (see below) |
| Relative path resolved differently | Use absolute paths |
| Symlink target outside sandbox | Grant 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
Network Connection Failed
Symptom
Commands likecurl, wget, or API calls fail with connection errors.
Possible Causes
- Network explicitly blocked - You used
--block-netflag - Actual network issue - DNS, firewall, or connectivity problem
- Application-specific issue - App needs specific configuration
Solutions
-
If you used
--block-net, remove it: -
Check if network is allowed from inside the sandbox:
-
Test network outside nono:
Command Not Found
Symptom
Solutions
-
nono not in PATH:
-
Target command not in PATH:
Sandbox Initialization Failed
Symptom
Linux (Landlock)
-
Check kernel version:
-
Check Landlock is enabled:
-
Enable Landlock (if missing):
Add
lsm=landlock,...to kernel boot parameters
macOS (Seatbelt)
-
Check macOS version:
- 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
Example
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:-
Verify the parent is sandboxed:
-
Check if you’re testing correctly:
Performance Issues
Symptom
Commands run slower under nono.Explanation
There is minimal overhead from sandbox initialization (microseconds). If you’re seeing significant slowdowns:- First run may be slower due to path canonicalization
- Many file operations may show overhead from kernel permission checks
Solutions
- Grant access to larger directories instead of many individual files
- Use
--readfor directories that don’t need write access (slightly faster path)
Using nono why --self for Debugging
When running inside a nono sandbox, you can query your own capabilities using nono why --self:
The
--self flag reads the sandbox state from NONO_CAP_FILE, which is the only environment variable nono sets. This is designed for programmatic introspection by AI agents rather than debugging via shell variables.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:
Linux: “Landlock not supported”
Your kernel may not have Landlock enabled. Check:Linux: Network Restrictions Not Working
Network filtering requires Landlock ABI v4 (kernel 6.7+):Using nono learn to Discover Required Paths
If you’re getting permission errors and aren’t sure which paths your application needs, use nono learn to trace file accesses:
nono learn is available on Linux (requires strace) and macOS (requires sudo for fs_usage and nettop). The command runs WITHOUT sandbox restrictions to accurately trace file and network accesses.Example Workflow
-
Run learn mode to discover paths:
-
Review the output to see which paths are needed:
-
Add the paths to your nono command or profile:
WSL2-Specific Issues
Sandbox initialization: EBUSY on seccomp
Symptom:Sandbox initialization failed with EBUSY when using --capability-elevation.
Cause: WSL2’s init process (PID 1) installs its own seccomp user notification filter. The Linux kernel only allows one notify listener per filter chain, so nono’s attempt to install a second returns EBUSY.
Solution: nono automatically disables capability elevation on WSL2. If you see this error, ensure you’re running a recent version. This is tracked in microsoft/WSL#9548.
Credential proxy refused on WSL2
Symptom:WSL2: proxy-only network mode cannot be kernel-enforced
Cause: The proxy’s network lockdown depends on seccomp notify or Landlock V4, neither of which is available on WSL2.
Solutions:
- Use
--env-credentialinstead of--credential(env var injection works normally) - Opt in to degraded proxy mode with
wsl2_proxy_policy: "insecure_proxy"in your profile’s security config (details)
Per-port network filtering unavailable
Symptom:--open-port or --listen-port fails on WSL2.
Cause: Landlock V4 (kernel 6.7+) is required for TCP port filtering. WSL2 ships kernel 6.6.
Solution: Use --block-net for full network isolation, or wait for a WSL2 kernel upgrade to 6.7+.
Verifying WSL2 compatibility
Runnono setup --check-only inside WSL2 to see the full feature availability matrix:
Getting Help
If you’re still stuck:- Search existing issues: GitHub Issues
- Open a new issue with:
- nono version (
nono --version) - OS and kernel version
- Full command that failed
- Error message
- Output of
nono run --dry-runwith same flags
- nono version (