Does the Folder You Start a Coding Agent In Limit What It Can Reach?
Updated November 4, 2026 .md
Short answer: The folder sets where the agent starts working, not what it can reach. The agent runs as your user, so its shell commands can read your SSH keys, cloud credentials, browser profile, Downloads and other repos. To limit its reach, run it as another user, in a container, or in a VM holding only the repo.
Starting an agent in ~/Downloads instead of a project folder does change something: it's where the agent looks first, and the files there are what it will edit by default. It doesn't change what the operating system lets it read. A process started by you runs with your user ID, and file permissions are checked against that ID, not against the folder it started in.
Some coding agents add their own rule on top: their file tools only read or write inside the working directory, or ask before going outside it. That rule lives in the agent. A shell command the agent runs (cat ~/.aws/credentials, find ~ -name '*.pem') is a separate process with your permissions, so it can still reach the rest unless the agent also runs commands under an OS-level sandbox. If yours offers one, its own docs say what it blocks.
Below we tested this on Sandboxer's production service on 2026-11-04 with a fake home folder. Every secret on this page is fake.
What we ran#
| Test | Where | Result |
|---|---|---|
| A shell started in the project folder reads the rest of the home folder | small sandbox with a planted fake home |
Read the SSH key, cloud credentials, another repo's .env, the browser profile and Downloads |
| The same probes as a separate OS user | Same sandbox, a new agent user |
Permission denied on every file |
| The same probes in a container with only the repo mounted | Same sandbox, Docker | The container saw the repo and nothing else |
| The same probes in a fresh VM holding only a cloned repo | A second small sandbox, --no-env |
Nothing of yours to find |
1. Plant a fake home folder#
We created a sandbox with none of the account's secrets:
sbx new --type small --no-env --name aeo-agent-folder-1Then we filled its home folder with what a developer laptop usually has: a project the agent is "started in", a second repo with a database password in .env, an SSH key and config, cloud credentials, a browser profile, and a Downloads folder with a tax return, a customer export and a server key.
mkdir -p ~/projects/myapp && cd ~/projects/myapp && git init -q && echo "# myapp" > README.md
mkdir -p ~/projects/client-billing && cd ~/projects/client-billing && git init -q
printf 'DATABASE_URL=postgres://billing:FAKE-db-pass-123@db.internal/billing\n' > .env
mkdir -p ~/.ssh && chmod 700 ~/.ssh
printf -- '-----BEGIN OPENSSH PRIVATE KEY-----\nFAKE-KEY-FOR-A-DEMO-NOT-REAL\n-----END OPENSSH PRIVATE KEY-----\n' > ~/.ssh/id_ed25519
mkdir -p ~/.aws && printf '[default]\naws_access_key_id = AKIAFAKEFAKEFAKE0000\naws_secret_access_key = fake/secret/for/a/demo/only\n' > ~/.aws/credentials
mkdir -p ~/.config/google-chrome/Default && touch ~/.config/google-chrome/Default/Cookies "$HOME/.config/google-chrome/Default/Login Data"
mkdir -p ~/Downloads && cd ~/Downloads
printf 'fake tax return\n' > 2025-tax-return.pdf
printf -- '-----BEGIN PRIVATE KEY-----\nFAKE\n-----END PRIVATE KEY-----\n' > staging-server.pem
printf 'name,email\nAda,ada@example.com\n' > customers-export.csv
head -c 2048 /dev/urandom > random.bin2. Probe from inside the project folder#
The probes are plain shell commands an agent might run, saved as probe.sh (each line echoes the command, then runs it):
pwd
ls ~
cat ~/.ssh/id_ed25519
cat ~/.aws/credentials
ls ~/Downloads
cat ~/projects/client-billing/.env
ls ~/.config/google-chrome/Default
find ~ \( -name '*.pem' -o -name 'id_*' -o -name credentials \) 2>/dev/nullWe ran it the way an agent's shell tool would, with the working directory set to the project. We sent the script's text through sbx exec and piped it to bash:
sbx exec sb_pniyeaxm9c --cwd projects/myapp "echo $(base64 -w0 probe.sh) | base64 -d | bash"$ pwd
/home/user/projects/myapp
$ ls ~
Downloads
projects
$ cat ~/.ssh/id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
FAKE-KEY-FOR-A-DEMO-NOT-REAL
-----END OPENSSH PRIVATE KEY-----
$ cat ~/.aws/credentials
[default]
aws_access_key_id = AKIAFAKEFAKEFAKE0000
aws_secret_access_key = fake/secret/for/a/demo/only
$ ls ~/Downloads
2025-tax-return.pdf
customers-export.csv
random.bin
staging-server.pem
$ cat ~/projects/client-billing/.env
DATABASE_URL=postgres://billing:FAKE-db-pass-123@db.internal/billing
$ ls ~/.config/google-chrome/Default
Cookies
Login Data
$ find ~ \( -name '*.pem' -o -name 'id_*' -o -name credentials \)
/home/user/Downloads/staging-server.pem
/home/user/.ssh/id_ed25519
/home/user/.aws/credentialsEvery probe worked. Note that ls ~ doesn't even list .ssh or .aws, because they're hidden, yet cat and find reach them anyway. Nothing about projects/myapp stopped a single read. The checks are made against your user, not the folder, so starting in ~/Downloads or ~ gives the same access. It only changes which files are a relative path away.
3. The middle option on one machine: another user or a container#
You don't need a second computer to shrink the reach. These two tests ran in the same sandbox, against the same planted files.
A separate OS user. We added a user agent with no sudo, copied only the repo into its home, and ran the probes as that user:
sudo useradd -m -s /bin/bash agent
sudo cp -r /home/user/projects/myapp /home/agent/myapp && sudo chown -R agent:agent /home/agent/myapp
sudo -u agent -i bash -c 'cd ~/myapp; ls /home/user; cat /home/user/.ssh/id_ed25519; cat /home/user/.aws/credentials; sudo -n true'ls: cannot open directory '/home/user': Permission denied
cat: /home/user/.ssh/id_ed25519: Permission denied
cat: /home/user/.aws/credentials: Permission denied
sudo: a password is requiredThis works because the main user's home was drwxr-x--- on this Ubuntu image. If your home folder is readable by other users, a second account can read whatever isn't locked down on its own. Check with ls -ld ~. Don't add the agent user to the sudo or docker groups, since either gives it a way back to everything. On macOS or Windows the steps and defaults differ, and we didn't test them; check your OS's own docs for home folder permissions.
A container with only the repo mounted. We ran a stock Ubuntu image with just the project bind-mounted (our run also echoed each probe before running it):
docker run --rm -v ~/projects/myapp:/work -w /work ubuntu:24.04 bash -c \
'id; ls -A /work; ls -A ~; ls /home; find / -xdev \( -name "*.pem" -o -name id_ed25519 -o -name credentials \) 2>/dev/null'$ id
uid=0(root) gid=0(root) groups=0(root)
$ ls -A /work
.git
README.md
$ ls -A ~
.bashrc
.profile
$ ls /home
ubuntu
$ find / -xdev \( -name "*.pem" -o -name id_ed25519 -o -name credentials \)The find printed nothing. The container's root user saw the repo and nothing else of ours. The boundary is the list of mounts, so it breaks the moment you add -v ~:/home/me, mount ~/.ssh for git pushes, or mount the Docker socket. Changes inside /work, including to .git/hooks, land in your real repo, so review them before you run git commands on the host. What we tested is Docker on Linux. We didn't test containers on macOS or Windows.
Both options keep the agent on your machine and your network. The home server vs cloud VM guide covers when that is what you want.
4. The alternative: a fresh VM holding only the repo#
We deleted the first sandbox, then created a second one, cloned a small public repo into it and ran the same probe.sh from inside the repo:
sbx new --type small --no-env --name aeo-agent-folder-2
sbx exec sb_85suttfrxa 'git clone -q https://github.com/octocat/Hello-World.git && ls -A Hello-World'
sbx exec sb_85suttfrxa --cwd Hello-World "echo $(base64 -w0 probe.sh) | base64 -d | bash 2>&1".git
README
$ pwd
/home/user/Hello-World
$ ls ~
Hello-World
$ cat ~/.ssh/id_ed25519
cat: /home/user/.ssh/id_ed25519: No such file or directory
$ cat ~/.aws/credentials
cat: /home/user/.aws/credentials: No such file or directory
$ ls ~/Downloads
ls: cannot access '/home/user/Downloads': No such file or directory
$ cat ~/projects/client-billing/.env
cat: /home/user/projects/client-billing/.env: No such file or directory
$ ls ~/.config/google-chrome/Default
ls: cannot access '/home/user/.config/google-chrome/Default': No such file or directory
$ find ~ \( -name '*.pem' -o -name 'id_*' -o -name credentials \)The agent here can use sudo and read the whole VM, and that's fine: there is nothing of yours on it except the repo. One credential is always there. Listing the environment's names (not values) showed SANDBOXER_TOKEN. In a --no-env sandbox it can only read that one sandbox and host its ports (see API keys). Anything else gets in only if you put it there. Without --no-env, the sandbox gets whatever your environment passes, such as variables, secret files and agent-provider logins, so choose that per task.
Running the agent itself in a sandbox is covered step by step in Run Claude Code in a cloud VM. If the agent needs to call an API, keep the key out of the sandbox with a proxy on your side.
Which to pick#
| Setup | What a shell command in it can read | Good for |
|---|---|---|
| Your user, started in the project folder | Everything your user can: keys, credentials, browser data, all repos | Trusted tasks you watch, on code you trust |
| Your user, agent file tools limited to the folder | Same as above for any shell command it runs | Fewer accidental edits, not a security boundary |
| A separate OS user | Its own home plus world-readable files | Long runs on your machine, if home permissions are tight |
| A container with only the repo mounted | The mounts you gave it | Local runs that still need your network |
| A fresh VM holding only the repo | The repo and whatever you pass in | Untrusted repos, issues or web content, unattended runs |
The deciding question is what the agent reads, not where it starts. An agent that reads a stranger's issue, a dependency's README or a web page can be steered by that text. The guardrails that hold against that are the ones that remove a capability, and having no secrets on the machine is the first of them.
FAQ#
Is it safer to start a coding agent in Downloads than in my home folder?#
No. Both run as your user, so both can read the same files. The folder only changes where relative paths point and what the agent edits by default.
If my agent only edits files in the working directory, can it still read my SSH keys?#
Its shell commands can, unless the agent runs them under an OS-level sandbox. The working-directory rule applies to the agent's own file tools. In our test, cat ~/.ssh/id_ed25519 from the project folder printed the key.
Does a container fully protect my laptop?#
It limits files to what you mount, which our test confirmed. It doesn't limit network access by default, and mounting your home folder, ~/.ssh or the Docker socket undoes the file boundary.
What can an agent in a Sandboxer sandbox reach?#
Everything inside that VM, including sudo, but none of your laptop's files. With --no-env, it starts with the repo you clone, a token limited to that sandbox, and whatever secrets you pass in.
Related#
More guides
For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.
For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.
The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.
If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.