Overview
BoxLite uses macOS’s built-in sandbox system (Seatbelt) to isolate theboxlite-shim process. The sandbox uses SBPL (Sandbox Profile Language) policies that whitelist specific operations. When an operation is denied, macOS logs the denial to the system log.
Quick Reference
Debugging Workflow
1
Enable real-time log monitoring
Open a separate terminal and start monitoring sandbox messages:
2
Run your test
In another terminal, run the operation that is failing:
3
Analyze denials
Sandbox denials appear in the format:Common denial types:
4
Update the policy
Based on the denial, add the appropriate rule to the SBPL policy:
5
Rebuild and test
After updating
.sbpl files, rebuild to pick up changes:Log Commands Reference
Real-time Streaming
Historical Queries
Filtering Tips
SBPL Policy Syntax
Basic Structure
Common Patterns
Testing Syntax
BoxLite Policy Files
BoxLite’s sandbox policy is split into multiple files:Viewing the Generated Policy
To see the complete generated policy:/tmp/debug-policy.sbpl.
Common Issues
1. Changes Not Taking Effect
The.sbpl files are embedded at compile time via include_str!. After modifying them:
2. Path Canonicalization
macOS uses symlinks (/var -> /private/var, /tmp -> /private/tmp). Use canonical paths in your policy:
3. Duplicate Denials
The log may show “X duplicate reports for…”. This means the same denial happened multiple times. Fix the root cause, not each duplicate.4. Silent Failures
Some denials do not appear in logs immediately. If the process hangs or crashes without logged denials:1
Check for crash reports
2
Verify process started
Check host logs to ensure the process actually started.
3
Run without sandbox
Try running without the sandbox to isolate whether the issue is sandbox-related.
5. Permissions vs Sandbox
Not all failures are sandbox-related. Also check:- File permissions (
ls -la) - Directory existence
- Hypervisor.framework entitlements
Debugging Checklist
Use this checklist when investigating sandbox denials:- Start log streaming before running test
- Filter logs for your process name
- Check for
deny(1)messages - Note the exact operation and target
- Add minimal rule to policy (prefer
literaloversubpath) - Document WHY the rule is needed (in comments)
- Rebuild and retest
- Verify no new denials appear

