Developer gives Claude Code its own OS user for sandboxed security
Author pjungwir describes running Claude Code as a dedicated, unprivileged OS user on Debian 13, isolating it from credentials, secrets, and sensitive files while still allowing comfortable parallel development.
Score breakdown
The setup demonstrates a practical, host-native alternative to VM-based sandboxing for Claude Code, using standard Unix multi-user isolation to keep credentials and secrets out of the AI's reach without the complexity of virtualization.
- 01Claude runs as a separate, unprivileged Linux OS user with its own home directory, dotfiles, SSH key, and Postgres databases
- 02The author's home directory is set to `0700`, blocking Claude's user from accessing credentials, `.env` files, SSH keys, and VPN scripts
- 03Claude's tmux sessions use a yellow status bar (via `~/.tmux.conf`) to distinguish them from the author's own sessions
Pjungwir runs Claude Code with `--dangerously-skip-permissions` but mitigates the risk by giving Claude its own dedicated OS user on Debian 13 with xfce. The author's personal account holds AWS credentials, k8s configs, SSH keys, GitHub access, `.env` files from dozens of customers, VPN scripts, and a browser signed into everything — none of which Claude's user can access, since the author's home directory is set to `0700`. Claude's user has its own password-protected SSH key added to GitHub, its own non-superuser Postgres development and test users and databases, and similar dotfiles — but no secrets. Any operation requiring `sudo` requires the author to intervene manually.
The workflow centers on `tmux`: the author opens a terminal tab, `su`s to Claude's account, navigates to a project under `~/src`, and starts a tmux session.
The workflow centers on `tmux`: the author opens a terminal tab, `su`s to Claude's account, navigates to a project under `~/src`, and starts a tmux session. A yellow status bar in Claude's `~/.tmux.conf` makes those sessions visually distinct. Typically window 1 stays in bash for git operations (push/pull, reading diffs, running tests), window 2 runs the Claude session, and additional windows handle `psql`, `vim`, and so on. Many of Claude's git repos include a local SSH remote pointing back to the author's own copy of the same repo, enabling easy collaboration on work not yet ready to share publicly.
The author acknowledges lingering concerns: Linux privilege escalation bugs could theoretically be exploited by a future model, and the Docker situation is unresolved — adding Claude to the `docker` group or granting `sudo` feels too permissive, and rootless Docker as an alternative hasn't been tested yet. The author notes that a VM isn't obviously more secure given hypervisor escape vulnerabilities and the read/write access shared folders like `/vagrant` provide to the host.
Key facts
- 01Claude runs as a separate, unprivileged Linux OS user with its own home directory, dotfiles, SSH key, and Postgres databases
- 02The author's home directory is set to `0700`, blocking Claude's user from accessing credentials, `.env` files, SSH keys, and VPN scripts
- 03Claude's tmux sessions use a yellow status bar (via `~/.tmux.conf`) to distinguish them from the author's own sessions
- 04Many of Claude's git repos include a local SSH remote (`ssh://paul@localhost/~/src/...`) for easy collaboration without public sharing
- 05Claude's SSH key is password-protected; the author handles all git push/pull operations on Claude's behalf
- 06Docker access remains unresolved — the author is unwilling to add Claude to the `docker` group or grant `sudo`, and rootless Docker hasn't been tested yet
- 07The author runs on Debian 13 with xfce and has used this setup for several months
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 13, 2026 · 08:58 UTC. How this works →