DocsSecuritySandbox & Execution Isolation
Back to Docs
Security

Sandbox & Execution Isolation

Understand what YeePilot's sandbox limits, how network and namespaces work, and which settings most users actually need.

Last updated: May 12, 2026

What The Sandbox Does

The sandbox is YeePilot's main execution safety boundary. It limits what commands can do while they are running.

For end users, the most important effects are:

  • optional namespace isolation on Linux
  • optional network access inside executed commands
  • CPU, memory, file-size, and process limits
  • denied paths that commands should not touch

The Settings Most Users Care About

yaml
sandbox:
  enabled: true
  use_namespaces: true
  network_access: true
  max_cpu_seconds: 300
  max_memory_mb: 512
  max_filesize_mb: 100
  max_processes: 64
  denied_paths:
    - /etc/shadow
    - /etc/gshadow
    - /root

Linux Namespaces

use_namespaces is the Linux-specific isolation feature.

  • on Linux, keep it enabled unless your environment does not allow it
  • on macOS and Windows, namespace behavior is not the same and the setting is typically less relevant

If a Linux machine blocks unprivileged namespaces, YeePilot may need that setting turned off for local commands to succeed.

Network Access

network_access controls whether sandboxed commands can reach the network.

Use:

text
/sandbox status
/sandbox net
/sandbox nonet

Typical use cases:

  • keep network on for package installs, remote checks, and downloads
  • switch it off for local-only review work or highly sensitive tasks

Denied Paths

denied_paths are locations sandboxed commands should not access.

Default examples:

  • /etc/shadow
  • /etc/gshadow
  • /root

You can add your own paths, such as application secret stores or private key directories.

Resource Limits

The resource limits are end-user guardrails:

  • max_cpu_seconds
  • max_memory_mb
  • max_filesize_mb
  • max_processes

Raise them only when you know a legitimate task needs more room, such as a large build or a heavier analysis command.

When The Sandbox Gets In Your Way

The sandbox is supposed to be protective, but some tasks genuinely need different settings. Common examples:

  • password-processing commands
  • commands that must reach the network
  • large builds that exceed default memory limits
  • Linux environments where namespaces are disabled

When that happens, change the smallest setting necessary instead of turning everything off.

Best End-User Advice

  • keep the sandbox enabled by default
  • disable network only when a task should stay fully local
  • prefer SSH keys and Vault workflows over password-based flows
  • only turn off namespaces when your environment forces you to