Terminal, iTerm und die gesandboxte Shell

Hilfe · Stand 12. September 2026 · Read in English

Terminal-Apps sind der eine Fall, in dem ScopeShelf nicht die App sandboxt, sondern die Shell darin. Diese Seite erklärt, warum das so ist, geht jede Einstellung durch und listet die Fehlermeldungen auf, die dir begegnen können, samt Abhilfe.

1. Warum ein Terminal nicht in der Sandbox laufen kann

Terminal.app, iTerm2, Alacritty, kitty und Co. starten deine Shell nicht direkt. Sie gehen über /usr/bin/login, ein kleines Programm mit gesetztem setuid-Bit. macOS weigert sich, setuid-Programme in einer Seatbelt-Sandbox zu starten, egal was im Profil steht. Das kannst du selbst nachprüfen:

$ sandbox-exec -p '(version 1)(allow default)' /usr/bin/login -fpl $USER /bin/echo hi
sandbox-exec: execvp() of '/usr/bin/login' failed: Operation not permitted

Ein Terminal, das in der Sandbox startet, öffnet also sein Fenster, versucht eine Session aufzumachen und scheitert. Es sieht aus, als wäre die App kaputt. Daran lässt sich in ScopeShelf nichts einstellen; es ist eine Regel des Betriebssystems.

ScopeShelf erkennt solche Apps beim Auswählen. Auf der Karte steht Terminal — die Sandbox gilt für die Shell, die du hier startest, der Start-Button heißt Shell starten, und es gibt für sie weder „Beenden“ noch „Geschützt neu starten“: das würde dein Terminal mit allen offenen Shells schließen, für einen Start, der nicht funktionieren kann.

2. Was ScopeShelf stattdessen macht

Dein Terminal läuft ganz normal, ohne Sandbox. Darin startet ScopeShelf eine gesandboxte Shell: eine zsh (oder welche Shell du benutzt), eingepackt in das Seatbelt-Profil des Launchers. Alles, was du aus dieser Shell startest, erbt die Sandbox: Claude Code, Codex, npm, Build-Skripte, git. Die Shell sieht deinen Projektordner und die freigegebenen Ordner, und sonst nichts aus deinem Benutzerordner.

Es gelten dieselben drei Zonen wie bei jedem Launcher:

• Schreibbar: der Arbeitsordner der Shell (dein Projekt) und jeder Ordner, den du als schreibbar freigegeben hast.
• Nur lesbar: Referenzordner, deine Shell-Startdateien, Programm-Ordner wie ~/.local/bin.
• Unsichtbar: alles andere in deinem Benutzerordner. ~/.ssh, ~/.gnupg, ~/.aws, ~/.config/gcloud und deine Schlüsselbunde bleiben gesperrt, auch wenn ein freigegebener Ordner sie enthält.

Alles außerhalb deines Benutzerordners (/usr, /opt/homebrew, /Applications, /tmp) bleibt erreichbar, wie bei jedem ScopeShelf-Launcher.

3. Terminal-Launcher in der App anlegen

1. Neuer Launcher. Unter Schritt 1 klickst du in der Zeile Oder eine installierte App direkt auf Terminal oder iTerm. Den Datei-Dialog brauchst du nicht. Wenn du ihn trotzdem nimmst: Terminal.app liegt unter /System/Applications/Utilities/; der Dialog zeigt versteckte Ordner, du kannst also dorthin navigieren oder Cmd+Shift+G drücken und den Pfad einfügen.
2. Name. Der daraus abgeleitete Kurzname ist das, was du später auf der Kommandozeile tippst (scopeshelf shell mein-name).
3. Freigaben. Die Vorlagen für Terminal und iTerm geben von sich aus nichts frei. Nach dem Projektordner fragt ScopeShelf beim ersten „Shell starten“ (siehe unten), den musst du hier also nicht eintragen. Trag hier ein, was die Tools drinnen über das Projekt hinaus brauchen. Typisch für Claude Code mit dem nativen Installer:

   # Schreibbar
   ~/.claude                     # Einstellungen, Sitzungen
   ~/.local/share/claude         # die Programmdateien
   # Dateien (als einzelne Dateien freigegeben)
   ~/.claude.json
   ~/.gitconfig

   Referenzmaterial, das die KI nur lesen soll, kommt als nur lesbar dazu.
4. Abschnitt „Shell“ (Schritt 4). Hier wird die Shell selbst eingestellt. Alle Listen sind auf deinem Mac gemessen, nicht geraten. Die Einzelheiten stehen im nächsten Abschnitt.
5. Sichern.

4. Der Abschnitt „Shell“, Einstellung für Einstellung

Du findest ihn unter Launcher bearbeiten → Schritt 4, Shell. Dieselben Einstellungen gibt es noch einmal unter Einstellungen → Shell als Vorgabe für alle Launcher; ein Launcher überschreibt nur, was du in ihm setzt.

5. Die gesandboxte Shell starten

Aus der App

Klick auf Shell starten, auf der Launcher-Karte, in der Detailansicht oder im Menü der Menüleiste. Dann passiert zweierlei:

1. Dialog „Arbeitsordner“ (nur beim ersten Mal, wenn kein Arbeitsordner eingestellt ist): wähl den Projektordner, in dem die Shell arbeiten soll. ScopeShelf speichert ihn im Launcher. Den Benutzerordner und gesperrte Ordner wie ~/.ssh lehnt der Dialog ab.
2. Dein Terminal kommt nach vorn, mit einem neuen Fenster. ScopeShelf tippt den Shell-Befehl hinein. iTerm und Terminal.app werden direkt gesteuert; jedes andere Terminal bekommt ein Fenster in Terminal.app.

Beim ersten Mal fragt macOS, ob ScopeShelf dein Terminal steuern darf (Systemeinstellungen → Datenschutz & Sicherheit → Automation). Erlaub es, sonst geht nichts auf.

Ein Dock-Starter (in der Detailansicht anzulegen) macht dasselbe, inklusive Ordner-Dialog.

Was der Banner dir sagt

Gesandboxte Shell (tttt, zsh) — beenden mit `exit`, Details mit `scopeshelf scope`.
Schreibbar: ~/repos/mein-projekt  ~/.claude  ~/.local/share/claude
Nur lesbar: ~/.zshenv  ~/.zshrc  ~/.local/bin
Arbeitsordner ~/repos/mein-projekt ist fuer diese Shell schreibbar freigegeben (zusaetzlich zum Profil).

• Die erste Zeile nennt Launcher und Shell.
• Schreibbar und Nur lesbar listen deine Freigaben; der Arbeitsordner steht vorn.
• Eine Zeile, die mit Nicht freigegeben, aber von einer Startdatei geladen beginnt, nennt Dateien, die du unter Dateien, die deine Startdateien nachladen anhaken solltest.
• Netzwerk: blockiert oder Netzwerk nur zu: … erscheint, wenn der Launcher das Netz einschränkt.

Nach dem Banner bist du in deinem normalen Prompt, im Arbeitsordner. Starte Claude Code, Codex oder was du willst. exit beendet die gesandboxte Shell und bringt dich zurück in die ungeschützte Shell dieses Fensters.

6. Was drinnen geht und was nicht

• scopeshelf scope zeigt das vollständige Profil der Shell, in der du gerade bist: schreibbar, nur lesbar, gesperrt, Netzwerk.
• cd ~ geht, aber ls dort antwortet mit Operation not permitted: der Benutzerordner ist unsichtbar. Genau das soll die Sandbox tun. Nimm die Ordner aus dem Banner.
• Schreiben außerhalb der schreibbaren Ordner scheitert mit Operation not permitted. Lesen von ~/.ssh oder dem Schlüsselbund scheitert genauso, immer.
• Alles, was du startest, erbt die Regeln: ein Build-Skript kann nicht schreiben, wo die Shell es nicht kann.
• Mit Netzwerk blockieren oder einem Domain-Filter am Launcher sind ausgehende Verbindungen aus dieser Shell gesperrt oder auf die gelisteten Domains begrenzt. Ein gesperrter Host wird im Terminal als scopeshelf: Netzwerk blockiert: host gemeldet.
• Deine History liegt pro Launcher im Konfigurationsverzeichnis des Sandkastens, nicht in ~/.zsh_history.

7. Dasselbe auf der Kommandozeile

Installier den Befehl einmal unter Einstellungen → Kommandozeilen-Werkzeug. Das legt einen Link auf das scopeshelf-Programm aus der App in ~/.local/bin (oder /usr/local/bin, falls dir der Ordner gehört). Danach in jedem Terminalfenster:

scopeshelf shell mein-name                      # Shell im Profil des Launchers, in diesem Fenster
scopeshelf shell mein-name --cd ~/repos/anderes # anderes Projekt, nur für diesen Start
scopeshelf shell mein-name --shell /bin/bash    # andere Shell, nur für diesen Start
scopeshelf shell mein-name --no-network         # ausgehendes Netz für diesen Start sperren
scopeshelf shell mein-name -e FOO=bar           # Umgebungsvariable setzen
scopeshelf shell --app /Applications/iTerm.app ~/repos/x ~/docs:ro
                                                # ad hoc, ohne gespeicherten Launcher: x schreibbar, docs nur lesbar
scopeshelf dry mein-name                        # Profil anzeigen, ohne etwas zu starten
scopeshelf scope                                # in einer gesandboxten Shell: was gilt hier?

Regeln für den Startordner auf der Kommandozeile:

• Ein im Launcher eingestellter oder mit --cd übergebener Arbeitsordner ist der Arbeitsbereich und wird für diese Shell schreibbar.
• Ohne beides startet die Shell dort, wo du den Befehl aufgerufen hast, aber nur, wenn dieser Ordner im Profil sichtbar ist. Sonst nennt sie dir die freigegebenen Ordner und bricht ab. Wo du zufällig warst, wird nie stillschweigend freigegeben; --cd ist die ausdrückliche Entscheidung.
• Dein Benutzerordner und gesperrte Ordner werden als Arbeitsordner abgelehnt.

Für ein Projekt im Team legst du eine Datei .scopeshelf ins Repository und rufst in dem Ordner einfach scopeshelf shell auf:

{
  "launcher": "mein-name",
  "shell": { "workingDirectory": "." }
}

Die Projekt-Einstellungen aus der Datei liegen über denen des Launchers; ein relativer Arbeitsordner wird gegen das Projekt aufgelöst.

8. Was die Sandbox durchsetzt und was nicht

Jede Aussage unten prüft ein Skript im Repository (Scripts/check-sandbox-escapes.sh), das jeden Ausbruchsweg aus einer gesandboxten Shell heraus wirklich versucht, mit Stand 1.1.2 sind es 21 Versuche; die vollständige Tabelle, was wo durchgesetzt wird, steht in docs/sandbox-enforcement-map.md. Regeln mit dem Vermerk Profil stecken in jeder ScopeShelf-Sandbox und lassen sich von innen nicht abschalten.

Durchgesetzt vom Profil oder vom Kernel

• Dein Benutzerordner ist unsichtbar, bis auf die Freigaben. Gesperrte Ordner (~/.ssh, ~/.gnupg, ~/.aws, ~/.config/gcloud, Schlüsselbunde) bleiben gesperrt, auch innerhalb eines freigegebenen Ordners.
• Kein Lockern von innen. Ein verschachteltes sandbox-exec kann nur weiter einschränken; setuid-Programme wie sudo, login und crontab starten gar nicht.
• Keine andere App lässt sich starten. open -a Terminal skript.command oder open https://… wird abgelehnt (Seatbelt-Regel lsopen): eine so gestartete App liefe ohne Sandbox. Das heißt auch: Links, die du in einer gesandboxten App anklickst, öffnen keinen Browser.
• Keine Signale an Prozesse außerhalb der Sandbox. Ein gesandboxter Prozess kann seine eigenen Kinder beenden, aber nicht den ScopeShelf-Prozess mit dem Domain-Filter und nicht deine anderen Apps.
• Kein Schreiben außerhalb deines Benutzerordners, außer in Temp-Ordner (/tmp, $TMPDIR) und in Freigaben. Sonst könnte ein Agent /opt/homebrew/bin/git austauschen, und dein nächstes ungeschütztes git führt seinen Code aus. Werkzeuge aus der Sandbox heraus in einen freigegebenen Ordner installieren.
• ScopeShelf selbst ist nicht veränderbar: das App-Bundle und der Launcher-Speicher sind schreibgeschützt, auch wenn ein freigegebener Ordner sie enthält.
• Die Sandbox überlebt ScopeShelf. Der Kernel hängt das Profil an den Prozess. Töte den ScopeShelf-Prozess (auch mit SIGKILL von außen), beende die App, lass sie abstürzen: jeder gesandboxte Prozess bleibt gesandboxt, und ein Domain-Filter fällt ganz zu, weil sein Proxy weg ist. Ein Prozess von innen kann dieses Signal gar nicht erst senden (siehe oben).
• Dein ssh-agent ist unerreichbar: der Socket des Agenten ist gesperrt, geladene Schlüssel lassen sich von innen nicht benutzen.
• Kein ungesandboxter Helfer von dir führt für sie Befehle aus. Ein screen- oder tmux-Server, ein Neovim- oder Emacs-Server, Docker oder Kurzbefehle, die schon außerhalb der Sandbox laufen, würden Befehle ohne Sandbox ausführen. Ihre Sockets, FIFOs und Dienste sind gesperrt; die Shell bekommt einen eigenen Temp-Ordner statt des geteilten. tmux und screen, die du in der Sandbox startest, laufen über private Ordner weiter.
• Hardlinks und Umbenennen helfen nicht. Eine geschützte oder nur lesbare Datei lässt sich nicht in einen beschreibbaren Ordner verlinken und dort ändern, und geschützte Ordner lassen sich nicht unter ihren Regeln wegbewegen.
• Bei „Netz aus“ lauscht auch nichts. Ein gesandboxter Prozess kann keinen Port öffnen, zu dem ein Prozess von außen verbinden könnte.
• Eine .scopeshelf-Datei kann ihre eigene Sandbox nicht weiten. Sie darf nur Ordner im Projekt freigeben; ein Agent, der sie umschreibt, gewinnt für den nächsten Start nichts.

Durchgesetzt von macOS, nicht vom Profil

• Apple Events (osascript -e 'tell application "Terminal" to do script …') hängen an der Automation-Freigabe in Systemeinstellungen → Datenschutz & Sicherheit, und die gesandboxte Shell zählt als Teil des Terminals, in dem sie läuft. Das Profil kann sie nicht sperren: wir haben gemessen, dass Seatbelt die Regel appleevent-send annimmt, sie aber nichts bewirkt. Erlaub deinem Terminal nicht, andere Terminals zu steuern, wenn darin KI-Agenten laufen.
• launchd lehnt Aufträge aus gesandboxten Prozessen ab (launchctl submit, bootstrap, load scheitern). Das ist Verhalten von launchd; ändert es sich, wird der Test rot.

Gar nicht geschützt

• Die Terminal-App selbst. iTerm oder Terminal.app läuft mit deinen vollen Rechten. Gesandboxt ist nur die Shell, die ScopeShelf gestartet hat, und was darin läuft.
• Andere Tabs und Fenster. Ein neuer Tab in iTerm ist eine normale, ungeschützte Shell. Lass KI-Agenten in dem Fenster, das den Banner zeigt.
• Ordner, die du als schreibbar freigegeben hast. Darin kann ein Agent weiterhin löschen und ändern. Dafür ist die Freigabe da; halt die Liste kurz.
• Terminals, die ScopeShelf nicht steuern kann. Alacritty, kitty, Warp und andere bekommen ihre gesandboxte Shell in einem Terminal.app-Fenster, oder du rufst scopeshelf shell selbst darin auf.

9. Fehlermeldungen und was zu tun ist

Fehlt etwas auf dieser Seite? Sag es uns, dann ergänzen wir es.