Claude Code native einsperren

Linux

Diese kleine Anleitung ergibt sich aus einem Bedarf - ho ho ho - echt jetzt? Unter Linux soll Claude Code zum Einsazz kommen, aber stringenten Regeln unterliegen.

0. Voraussetzungen installieren

sudo apt-get install bubblewrap socat

Optional (für Unix-Socket-Blocking via seccomp):

npm install -g @anthropic-ai/sandbox-runtime

Das bedeutet, dass
Unter Ubuntu 24.04+ muss AppArmor bubblewrap erlauben, User-Namespaces zu erzeugen - zu prüfen mit:

sysctl kernel.apparmor_restrict_unprivileged_userns

Kommt hier 1 zurück, muss ein AppArmor-Profil für bwrap anzulegen.

1. Claude Code installieren

2. Sandbox aktivieren

Im laufenden Claude-Code-Prozess:

/sandbox

Dort Auto-allow mode wählen (Sandbox-Kommandos laufen automatisch, ohne Rückfrage) oder Regular permissions mode (mehr Kontrolle).

Um es projektübergreifend fest einzuschalten, in ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true
  }
}

3. Nur Startverzeichnis erlaubt, Unterverzeichnisse davon ausschließbar

Standardverhalten ohne weitere Config:

• Schreiben: nur im aktuellen Arbeitsverzeichnis (Working Directory) + Unterverzeichnisse + Session-Temp-Verzeichnis
• Lesen: die gesamte Platte, außer explizit gesperrten Pfaden — das ist dir vermutlich zu offen

Um auch das Lesen aufs Startverzeichnis zu beschränken (Whitelist-Ansatz), in .claude/settings.json im Projektverzeichnis (wichtig: . referenziert dort das Projekt-Root):

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

Das sperrt praktisch alles außerhalb, öffnet aber das Startverzeichnis wieder.

4. Unterverzeichnisse innerhalb des Startverzeichnisses ausschließen

Genau das deckt denyRead / denyWrite mit spezifischeren, engeren Pfaden ab — bei überlappenden Regeln gewinnt der spezifischere Pfad:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/", "./secrets", "./.env", "./node_modules/.cache"],
      "allowRead": ["."]
    }
  }
}

Da denyRead: ["./secrets"] spezifischer ist als allowRead: ["."], bleibt z.B. ein Ordner ./secrets gesperrt, obwohl der Rest offen ist. Gleiches Prinzip funktioniert für Schreibzugriff mit denyWrite.

5. Zusätzlich: Credentials explizit schützen

Auch innerhalb des erlaubten Bereichs sollten typische Geheimnisdateien separat gesperrt werden, da das Standardverhalten sie sonst mitliest:

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

6. Netzwerk mitdenken

Filesystem-Isolation allein reicht nicht — ohne Netz-Isolation könnte ein kompromittiertes Kommando Daten trotzdem exfiltrieren. Domain-Whitelist:

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Optional strikt (keine Prompts, harte Sperre bei nicht gelisteten Hosts):

{ "sandbox": { "strictAllowlist": true } }

7. Für ein Team verbindlich vorgeben

Stringenz für ein Entwicklerteam über Managed Settings zentral erzwingen, sodass einzelne Entwickler es nicht abschalten oder aufweichen können:

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ]
    }
  }
}

• allowUnsandboxedCommands: false verhindert, dass Claude bei Sandbox-Fehlern automatisch außerhalb der Sandbox ausweicht — sonst gäbe es ein Schlupfloch.
• allowManagedReadPathsOnly: true verhindert zusätzlich, dass einzelne Entwickler lokal weitere allowRead-Pfade hinzufügen.

Wichtige Einschränkung

Die Sandbox schützt nur Bash-Kommandos und deren Subprozesse — die eingebauten Tools Read/Edit/Write laufen über das separate Permission-System (Deny-Regeln dort zusätzlich setzen).

Außerdem: Standardmäßig terminiert der Proxy kein TLS, d.h. Domain-Fronting-artige Umgehungen sind theoretisch möglich — für einen Government-Kontext ggf. mit network.tlsTerminate oder eigenem Proxy nachschärfen.