When your AI bot can send texts and access real files, how do you test the sandbox without blowing up your actual data? A four-phase approach.

The button is visible. The selector finds it. But clicks fail silently. The culprit: an invisible overlay you never saw coming.

A phased approach to testing Docker sandbox configurations without risking your real data - essential for personal AI bots with access to email, messaging, and notes.

The Idea

A systematic, phased approach to testing Docker sandbox configurations without risking the host machine - especially important for personal automation bots with access to real data.

Context

User setting up moltbot on Mac Mini with Docker sandbox. Concerned about:

• Signal-cli (can brick phone identity)
• Volume mounts to personal Obsidian vault
• Email credentials
• Resource limits not actually working

The Pattern

Phase 1: Isolated Container Test

# Use DUMMY mounts, not real data
mkdir -p /tmp/test-sandbox/{downloads,obsidian}
docker run --rm -it \
  --read-only \
  --cpus="2.0" \
  --memory="2g" \
  -v /tmp/test-sandbox/downloads:/mnt/downloads:rw \
  moltbot-sandbox:custom /bin/sh

Phase 2: Resource Limit Validation

# Stress test that stays inside container limits
docker run --rm -it --cpus="2" --memory="2g" container sh -c "
  stress-ng --cpu 8 --timeout 10s 2>/dev/null || echo 'expected'
"

Phase 3: Credential Testing (Read-Only First)

# Email: read-only commands only
himalaya list --folder INBOX -s 3  # Safe
# himalaya send ...  # NEVER in testing

Phase 4: High-Risk Components

• Signal-cli: Use burner number or skip entirely
• Backup identity before any testing: cp -r ~/.signal-cli ~/.signal-cli.backup

Raw Exchange

User: “this machine is mac mini. and sandbox is running in docker. tell me plan to test this config but not blowing up my device”

Read more