Sometimes you want to run commands that you don't fully trust or that intentionally bypass security measures. A good example is running AI agents like:
claude --skip-permissions dangerously
If that command executes arbitrary shell commands, writes files, or installs software, running it in your primary administration session is risky.
A lightweight alternative to a full virtual machine is to create a separate macOS user session and connect to it via VNC in a window. This gives you a local desktop sandbox with minimal configuration.
No virtualization required.
The architecture looks like this:
Administrator user
↓
Screen Sharing (VNC)
↓
Restricted macOS user
↓
Run risky commands safely
Why this works well for developers
This configuration provides:
- separate
$START
- separate login keychain
- separate permissions
- no administrator privileges
- easy reset by deleting the user
You also get a windowed sandbox desktop, similar to a VM but much lighter.
This is great for things like:
- running
claude --skip-permissions dangerously
- test installation scripts
- experimenting with unknown npm packages
- isolate automation tools
- test shell agents
Step 1: Create a restricted user
Open:
System Settings → Users and Groups
Add a new user:
Account type: Standard
Name: sandbox
Important: DO NOT make him an administrator user.
This ensures that the sandbox cannot:
- install system software
- modify system settings
- easily escalate privileges
Step 2 – Enable Screen Sharing
Open:
System Settings → General → Share
Enable:
Share screen
Click the ⓘ information button.
Set access to:
Allow access to: Only these users
Add your restricted user.
Example:
sandbox
This ensures that only the account can initiate screen sharing sessions.
Step 3 – Log in to the Sandbox user
Enable fast user switching:
System Settings → Control Center
→ Quick user change
→ Show in menu bar
So:
- Click on your username in the menu bar
- Select login window
- Sign in as
sandbox
user
The sandbox session now runs in the background.
Step 4: Connect to the Sandbox desktop
macOS normally blocks the connection to its own screen and displays:
You can't control your own screen.
To avoid this, create local port forwarding.
Run:
ssh -NL 5901:localhost:5900 localhost
This forwards:
localserver: 5901 → localserver: 5900
Now connect using Finder.
Press:
⌘+K
Enter:
vnc://localhost:5901
This opens the Screen Sharing application in a window connected to the sandbox desktop.
Solution for "You can't control your own screen"
If you try to connect directly to vnc://localhost
, macOS will block it.
The above SSH tunnel solves this problem.
See the discussion on StackExchange which explains the workaround:
Step 5: Run your risky commands
Inside the sandbox desktop window you can now safely run things like:
claude --skip-permissions dangerously
Even if the agent:
- modify files
- install packages
- write scripts
will only affect:
/Users/sandbox
Your main development environment remains secure.
Convenience shortcut
To open the sandbox quickly:
open vnc://localhost:5901
You can even create a shell alias:
alias sandbox="open vnc://localhost:5901"
Now start the sandbox with:
sandbox
⚠️ Safety warning
A standalone macOS user is not a strong security sandbox. It helps prevent accidental corruption but does not completely isolate data.
The sandbox user can still access files in their main home directory that are world-readable.
For example:
/Users/realUser/.aws/config
/Users/realUser/.aws/credentials
~/.gitconfig
~/.npmrc
~/.env
If the permissions look like this:
-rw-r--r--
then any user of the machine can read them.
For example, the sandbox user could run:
cat /Users/realUser/.aws/config
Many tools block sensitive files automatically, but not all do.
You can audit files that other users can read:
find ~ -perm -o+r
And adjust permissions when necessary:
chmod 600 ~/.aws/*
chmod 600 ~/.ssh/*
This setting protects
.webp)
