AI Agents Deleting Home Folders? Run Your Agent in Firejail and Stay Safe

Source: Dev.to

Introduction: The Double‑Edged Sword of AI Agents

As a developer, I’m always looking for tools that boost productivity. While building Tunnelmole, an open‑source tunneling tool and a popular alternative to ngrok, I’ve increasingly used AI agents for various coding and business‑related tasks. When used correctly and with human oversight, these agents are incredibly powerful. However, giving them unrestricted access to your development machine is like handing over your password to an unpredictable intern—powerful, but potentially catastrophic. If something disastrous happens, you can’t blame the intern; you must set up a secure environment for the agent to run in.

The convenience of letting an agent read files, run commands, and write code directly on your machine is undeniable, but it comes with a massive, often overlooked, risk. What happens when the AI misunderstands a prompt? Or worse, what if a bug in the agent’s logic causes it to execute a destructive command?

This isn’t a theoretical problem. A recent Reddit post reported that the Claude CLI deleted an entire home directory, effectively wiping a Mac:

“Claude CLI deleted my entire home directory – wiped everything.”

The culprit was a single, terrifying command generated by the AI:

rm -rf tests/ patches/ plan/ ~/

Most of that command targets project‑specific directories, but the final ~/ expands to the current user’s home directory. The result: a recursive, forceful deletion of all documents, photos, dotfiles, and years of work.

This incident is a stark warning. We must build guardrails. The solution is sandboxing: running the AI agent in a restricted, controlled environment where its capabilities are strictly limited.

In this guide, I’ll show you how to use a powerful tool called Firejail to create a secure sandbox for your VS Code‑based AI agent. Although I personally use Kilo Code, the instructions apply to other agents like GitHub Copilot, Windsurf, or any tool that runs within VS Code.

Note: Firejail relies on Linux kernel features such as namespaces, so this guide works on Linux (host or VM). It may or may not work on Windows Subsystem for Linux with GUI apps like VS Code.

What is Firejail and Why is it Effective?

Firejail is a SUID (Set owner User ID upon execution) security sandbox program for Linux. In simpler terms, it lets you run any application in a tightly controlled environment. It uses kernel‑level security features—namespaces and seccomp‑bpf—to isolate the application from your system.

Why this approach works

• Kernel‑Level Enforcement – Restrictions are enforced by the OS kernel. If the sandboxed application (e.g., VS Code and its AI agent) tries to access a file or execute a disallowed command, the kernel blocks it.
• Default‑Deny Philosophy – A well‑configured sandbox starts with “deny everything” and then explicitly allows only the minimal set of needed actions. This is far more secure than trying to list everything an application cannot do.
• Lightweight and Transparent – Firejail is not a virtual machine; it’s a lightweight wrapper with minimal performance overhead. Once configured, you launch an app with firejail and it runs inside a secure bubble.

You can install Firejail from your distribution’s package manager. For example, on Debian or Ubuntu:

sudo apt-get update && sudo apt-get install firejail

Crafting a Secure Firejail Profile for VS Code

Out of the box, Firejail includes default profiles for many common applications, including code (VS Code). To protect against the specific risk of home‑directory deletion, we’ll create a custom, more restrictive profile that limits VS Code (and any extensions) to designated project folders.

Step 1: Create the custom profile directory

mkdir -p ~/.config/firejail

Step 2: Create a new profile file for VS Code

touch ~/.config/firejail/code.profile

Step 3: Populate the profile

Open ~/.config/firejail/code.profile in your favorite editor and paste the following configuration. Adjust the paths to match where you keep your projects.

# Firejail profile for Visual Studio Code
# Highly restrictive for running AI agents safely.

# Persistent local customizations
include code.local
include globals.local

# Disable potentially unsafe includes
ignore include disable-devel.inc
ignore include disable-exec.inc
ignore include disable-interpreters.inc
ignore include disable-xdg.inc
ignore whitelist ${DOWNLOADS}
ignore whitelist ${HOME}/.config/Electron
ignore whitelist ${HOME}/.config/electron*-flag*.conf
ignore include whitelist-common.inc
ignore include whitelist-runuser-common.inc
ignore include whitelist-usr-share-common.inc
ignore include whitelist-var-common.inc
ignore apparmor
ignore disable-mnt

# Block D‑Bus to prevent inter‑process communication
ignore dbus-user none
ignore dbus-system none

# Allow files commonly used by IDEs, then override with a strict whitelist
include allow-common-devel.inc

# --- WHITELISTING ---
# Deny everything by default; only allow the paths listed below.

# VS Code configuration directories
whitelist ${HOME}/.config/Code
whitelist ${HOME}/.config/Code - OSS
whitelist ${HOME}/.vscode
whitelist ${HOME}/.vscode-oss

# IMPORTANT: Change this to point to where you keep your coding projects!
whitelist ${HOME}/projects

# Shell configuration for the integrated terminal
whitelist ${HOME}/.zshrc
whitelist ${HOME}/.bashrc
whitelist ${HOME}/.oh-my-zsh
whitelist ${HOME}/.profile

# Create the Code config directory structure if it doesn't exist (VS Code crashes without it)
mkdir ${HOME}/.config/Code
mkdir ${HOME}/.config/Code/logs

# Security hardening
nosound          # disable sound
noexec /tmp      # prevent execution of files in /tmp

# Load common Electron settings
include electron-common.profile

Step 4: Launch VS Code inside the sandbox

firejail code

Your VS Code instance now runs with the restrictions defined in the profile, preventing accidental or malicious access to files outside the whitelisted locations.

Deconstructing the Security Profile

The profile may look complex, but its strategy is straightforward:

• ignore directives disable default allowances that could grant broader access than desired.
• whitelist entries explicitly grant read‑write access only to the essential configuration files and the directories where you store code.
• nosound and noexec /tmp add extra hardening by disabling unnecessary subsystems.
• include statements pull in minimal, common settings needed for Electron‑based apps like VS Code without opening additional attack surfaces.

By default‑denying everything and then selectively allowing only what the IDE truly needs, you dramatically reduce the risk that an AI agent (or any compromised extension) can execute destructive commands such as rm -rf ~/.