Cursor and all the agents that Cursor runs have full (read, with auto run in sandbox user-level access to your system. This means they can read, write, and execute files anywhere your user account has permissions. Using bwrap (Linux namespaces), we can limit that access to only what's necessary - your workspace folder and Cursor's own settings.

• Trust No AI: Prompt Injection Along The CIA Security Triad
• Agentic ProbLLMs: Exploiting AI Computer-Use and Coding Agents - Johann Rehberger @ 39C39

It's not a silver bullet, it compartmentalizes Cursor from the system hence adding another layer of defense. A viable alternative is running cursor and other agent frameworks inside a kernel-based virtual machine (KVM) and SSH'ing into it as a development environment.

Install bubblewrap (bwrap):

# Fedora/RHEL
sudo dnf install bubblewrap

# Debian/Ubuntu
sudo apt install bubblewrap

# Arch Linux
sudo pacman -S bubblewrap

Place your Cursor >= 2.0.77 AppImage in the versions/ folder:

mv Cursor-*.AppImage versions/

# Set the AppImage path and workspace directory
CURSOR_APPIMAGE=versions/Cursor-2.0.77-x86_64.AppImage \
WORKSPACE_DIR=$HOME/repos \  
./cursor-sandbox.sh

The first run will extract the AppImage (one-time operation). Subsequent runs will be faster.

Due to sandbox isolation, you must use the --remote flag to communicate with the Docker/Podman daemon running on the host system (outside the sandbox):

# Always use --remote flag
docker --remote ps
docker --remote build -t myimage .
docker --remote run -it ubuntu bash

podman --remote ps
podman --remote images
podman --remote start <container>

Cursor doesn't start?

• Check that bubblewrap is installed: bwrap --version
• Ensure the AppImage path is correct
• Check that your workspace directory exists
• Look for error messages in the terminal output

Display issues on Wayland?

• Ensure WAYLAND_DISPLAY environment variable is set
• Check that the Wayland socket exists: ls -la $XDG_RUNTIME_DIR/wayland-*

Permission errors?

• Ensure you have read/write access to the workspace directory
• Check Cursor config directories exist: ~/.cursor, ~/.config/Cursor, etc.

Docker/Podman not working?

• Always use the --remote flag: docker --remote ps or podman --remote ps
• Verify the daemon is running on the host (outside sandbox)
• Check the socket exists: ls -la /run/user/$(id -u)/podman/podman.sock

• Your workspace folder (/home/jpzk/repos/) - Full read/write access
• Cursor's own settings (.cursor, .config/Cursor, etc.) - Full read/write access

• System programs (/usr, /bin, /lib) - Can use but not modify
• Git config (.gitconfig) - Can read your git settings
• SSH keys (.ssh) - Can read for git authentication
• Internet - Full network access

• Screen (X11/Wayland) - Can display windows
• GPU - Can use for rendering
• Audio - Can play sounds

• Home directory - Cannot see files outside your workspace
• Documents, Downloads, Pictures - Not accessible
• Other projects - Only sees the workspace folder you specified

• Cannot install system packages - No sudo/root access
• Cannot modify system files - All system directories are read-only
• Cannot see other users - Isolated from other user accounts

• Cannot see all running processes - Only sees its own processes
• Cannot access other applications' data
• Limited hardware information access

Think of it like this:

• Cursor runs in a isolated container
• It can only touch: your workspace + its own settings + read system libraries
• Everything else on your computer is invisible and unreachable

What makes this secure:

• Cursor (or its AI) cannot accidentally or intentionally access your personal files
• Cannot modify your system
• Cannot see what else is running on your computer
• If compromised, damage is limited to your workspace folder

The sandbox provides access to your host's Podman/Docker containers via the API socket. This allows you to:

• List, inspect, and manage containers
• Run containers (they run on the host, not in the sandbox)
• Use docker-compose/podman-compose

How it works:

1. The sandbox mounts your Podman socket (/run/user/$(id -u)/podman/podman.sock)
2. Podman commands use --remote flag to communicate via the API
3. Containers are created/managed on the host system (outside the sandbox)
4. The sandbox cannot create its own isolated containers (user namespace limitation)

Security note: Containers you create will run on the host with your full user permissions, not limited by the sandbox.