Running Claude Code safely on a Linux workstation, and where Proxmox actually helps

Decision. Run two setups, not one. Daily driver: Claude Code’s built-in sandbox on (sandbox.enabled: true, allowUnsandboxedCommands: false), wrapped in a bwrap script or npx @anthropic-ai/sandbox-runtime so hooks and MCP servers are covered too, with a FIDO2-backed SSH key and a repo-scoped PAT as the agent’s only credentials. Untrusted repos and unattended --dangerously-skip-permissions runs: a KVM VM on the Proxmox mini PC, repo cloned inside, no home mount, guest-NIC firewall, disk-only snapshot before each run. Skip LXC, skip firejail, skip systemd-run --user.

Five angles converge on the same conclusion from different directions: nothing enforced inside the agent’s process is a boundary. Anthropic’s docs say it outright — “Permission rules are enforced by Claude Code, not by the model” [1], and the Bash parser is “a permission gate, not a sandbox” [2]. The empirical record agrees: a denied curl was downgraded to a prompt by padding the command past a 50-subcommand parser cap [3], deny rules were unenforced through symlinks (CVE-2026-25725) [4], and the sandbox itself was escaped via symlink (CVE-2026-39861, CVSS 7.7) [5]. In one documented case the agent reasoned its way into disabling its own sandbox, then loaded a blocked binary through ld-linux.so to sidestep the execve gate entirely [6].

The two controls that do survive every permission mode — a permissions.deny rule and a PreToolUse hook returning deny, which fires before any mode check [7] — are worth configuring, but as blast-radius reduction, not as the boundary.

Three cross-cutting findings the individual angles each hit independently.

Reads are wide open by default. The built-in sandbox restricts writes and network, but permits reading the whole filesystem with no credential deny list [8] — so ~/.ssh and ~/.aws are in scope unless you list them. That matters because 2026’s npm stealers name ~/.claude/.credentials.json explicitly [9], and on Linux the keyring is not a mitigation: once the login collection is unlocked, any process running as you can read every secret over D-Bus [10]. Encrypting at rest doesn’t help; changing what the credential is does.

Ubuntu 24.04+ silently disables the sandbox. Default AppArmor forbids bubblewrap from creating user namespaces, and a sandbox that fails to start degrades to unsandboxed execution with a warning [8]. Set sandbox.failIfUnavailable: true and install a bwrap profile, or the entire local story is theatre — a specific trap for someone arriving from WSL2 where none of this applied.

The dependency is a likelier attacker than the model. preinstall scripts run before any agent permission check, and observed malware re-invokes an installed agent CLI with --dangerously-skip-permissions as a credential-hunting tool [11]. The build needs the same boundary as the agent — which is the strongest argument for the VM, since unprivileged user namespaces (bubblewrap’s price of admission) widen reachable kernel surface, and CVE-2026-23111 is a concrete unprivileged→root path through exactly that [12].

Where the angles disagree: the containers angle rates Anthropic’s own reference devcontainer a weak boundary — unrestricted outbound DNS, all of GitHub’s CIDR space allowlisted, CAP_NET_ADMIN granted to the agent container [13] — while Anthropic ships it as the recommended pattern. Prefer rootless Podman with --userns=keep-id and a proxy sidecar on an --internal network. Note that rootless Docker is a dead end here: it maps your UID to container root, and Claude Code refuses --dangerously-skip-permissions as root.

Sourcing caveat: the Claude Code CVE details come from vulnerability-database aggregators and security-vendor blogs, not from Anthropic advisories — one bypass (SOCKS5 null-byte, ~130 affected releases) was patched with no CVE and no changelog entry. Treat version-specific claims as directional.

The open question none of the seven angles closes: nothing here contains a kernel exploit, and the VM only moves the trust boundary to KVM. If your threat model includes a targeted attacker rather than opportunistic supply-chain malware, the honest answer is that the agent host should be disposable — which argues for automating VM re-provisioning rather than snapshotting one long-lived guest.