2026 Cursor Agent Angst vor dem Löschen von Dateien? Mit Apple Container eine isolierte Sandbox erstellen

Löscht Cursor Agent Dateien außerhalb Ihres Projekts oder verändert eine wichtige Konfiguration? Die schnellste Lösung ist eine doppelte Absicherung: wegwerfbare Codekopie öffnen und Cursor-Befehle in einem Apple Container mit begrenzten Mounts ausführen.

Diese Cursor Agent Sandbox schützt jedoch nur das, was Sie nicht in den Container hineingeben. Ein aktiv schreibbarer Host-Mount bleibt für den Prozess veränderbar. Apple Container isoliert Linux-Werkzeuge, Builds und Tests, ersetzt aber weder eine vollständige macOS-Umgebung noch eine unabhängige Sicherheitsprüfung.

Für wen dieser Ablauf gedacht ist: für Entwickler, die Cursor Agent automatisch Abhängigkeiten installieren, Tests ausführen oder viele Dateien ändern lassen. Ebenso für technische Verantwortliche, die ein reproduzierbares Ausführungsmodell für kleine Teams benötigen. Wenn Sie lokale Container und eine zurücksetzbare, entfernte Mac-Umgebung vergleichen, erhalten Sie am Ende klare Entscheidungskriterien.

Zuletzt aktualisiert am 29.08.2026. Systemanforderungen, Mount-Optionen, Netzwerkparameter und Löschverhalten wurden anhand der aktuellen Apple-Container-Dokumentation sowie der offiziellen Cursor-Sicherheitsdokumentation geprüft.

Schutzmodell statt Befehls-Blacklist

Der häufigste Denkfehler lautet: „Ich verbiete rm -rf, also ist mein Mac geschützt.“ Das reicht nicht. Ein Agent kann Dateien auch mit Python, Node.js, find, Shell-Umleitungen, Git-Befehlen oder einem selbst erzeugten Skript löschen. Eine Befehlsliste erkennt deshalb höchstens bekannte Schreibweisen.

Cursor bietet Terminal-Freigaben, Run Modes, Sandbox-Regeln und .cursorignore. Diese Funktionen sind nützlich, aber sie bilden nicht allein die Dateisystemgrenze. Cursor selbst beschreibt Run Modes als Schutzmechanismen nach dem Best-Effort-Prinzip. .cursorignore schränkt außerdem den Index und bestimmte Agent-Zugriffe ein; Terminal- und MCP-Werkzeuge können davon nicht zuverlässig begrenzt werden. (prod.cursor.com)

Die belastbarere Architektur besteht aus zwei Ebenen:

1. Datenebene: Cursor öffnet nur eine temporäre oder reproduzierbar erzeugte Arbeitskopie.
2. Ausführungsebene: Build-, Test- und Installationsbefehle laufen in einem Linux-Container mit eigenem Root-Dateisystem, minimalen Mounts und optional vollständig abgeschalteter Netzwerkschnittstelle.

Apple Container führt Linux-Container als leichtgewichtige virtuelle Maschinen auf Apple-Silicon-Macs aus. Es handelt sich nicht um einen macOS-Container. Xcode-GUI, native Apple-Signierung, Keychain-Zugriffe, Simulator-Workflows und vollständige macOS-Buildketten bleiben daher auf dem Host oder gehören in eine separate Mac-Umgebung. (github.com)

Geeignet sind insbesondere:

• Installation von Linux-Abhängigkeiten innerhalb eines vorbereiteten Images
• Codegenerierung
• Python-, Go-, Rust- oder Node-basierte Tests
• Linter und statische Analysen
• reproduzierbare CLI-Builds
• Skripte, die nur mit der bereitgestellten Arbeitskopie arbeiten

Nicht geeignet ist das Modell als alleinige Grenze für:

• Xcode-Projekte mit nativer Signierung
• macOS-Frameworks und GUI-Anwendungen
• Produktionszugänge
• private SSH-Schlüssel
• exportierte Keychain-Daten
• persönliche Home-Verzeichnisse
• dauerhaft benötigte lokale Build-Artefakte

Voraussetzungen und Arbeitskopie

Apple Container setzt einen Mac mit Apple Silicon voraus. Die offizielle Dokumentation nennt macOS 26 als unterstützte Zielplattform und weist darauf hin, dass ältere Versionen nicht unterstützt werden. Prüfen Sie deshalb zuerst Hardware, Betriebssystem, Container-Version und Systemdienst. (github.com)

Führen Sie die Prüfung auf dem Host aus:

uname -m
sw_vers -productVersion
container system version
container system status

Erwartet wird bei der Architektur arm64. Wenn container system status keinen laufenden Dienst meldet, starten Sie ihn:

container system start

Installieren Sie Apple Container ausschließlich aus dem offiziellen signierten Release-Paket. Verwenden Sie für einen sicherheitsrelevanten Agent-Workflow nicht blind den Entwicklungszweig. Die aktuelle Befehlsreferenz kann sich zwischen Entwicklungsstand und Release unterscheiden; Apple weist ausdrücklich darauf hin, dass die Befehlsverfügbarkeit je nach macOS-Version und Release variieren kann. (github.com)

Geben Sie Cursor niemals das einzige Arbeitsverzeichnis. Für einen bereits versionierten Stand ist ein Git-Worktree praktisch:

cd ~/src/mein-projekt
git status --short
git worktree add --detach ../mein-projekt-agent HEAD

Wenn uncommittete Änderungen benötigt werden, sichern Sie sie zuerst als Patch:

git diff > ../mein-projekt-agent.patch
git diff --staged >> ../mein-projekt-agent.patch

Danach können Sie den Patch in die wegwerfbare Kopie einspielen:

cd ../mein-projekt-agent
git apply ../mein-projekt-agent.patch

Für nicht versionierte Dateien kopieren Sie nur die benötigten Inhalte. Verwenden Sie nicht pauschal cp -R ~. Eine Arbeitskopie unter ~/AgentWorkspaces/ ist weiterhin ein Host-Verzeichnis. Sie ist sicherer als das Original, aber kein magischer Schutz, solange sie mit Schreibrechten gemountet wird.

Legen Sie zusätzlich eine Lockdatei und eine Köderdatei an:

mkdir -p ~/AgentWorkspaces/mein-projekt-agent/_sandbox-test
printf 'NICHT LOESCHEN - TESTDATEI\n' \
  > ~/AgentWorkspaces/mein-projekt-agent/_sandbox-test/host-copy-marker.txt

Die Köderdatei gehört in die Originalkopie und darf im Test nicht verändert werden. Eine zweite Köderdatei kommt in die Arbeitskopie. So erkennen Sie später, welche Grenze tatsächlich eingehalten wurde.

Apple Container und vollständige macOS-Isolation im Vergleich

Apple Container ist interessant, weil Sie keinen vollständigen macOS-Gast für jeden Linux-Test starten müssen. Die Container laufen mit OCI-kompatiblen Images und können Host-Verzeichnisse, benannte Volumes oder temporäre Dateisysteme einbinden. Ein Root-Dateisystem lässt sich mit --read-only schreibschützen. (github.com)

Apple Container ist damit kein vollständiger Ersatz für eine isolierte macOS-Umgebung. Als Docker-Ersatz für einfache Linux-Entwicklungsaufgaben kann es sinnvoll sein, wenn Sie Apple Silicon und macOS 26 einsetzen. Die relevante Frage lautet nicht „Welches Tool ist allgemein besser?“, sondern: Muss der Agent macOS-Ressourcen oder nur einen Linux-Arbeitsstand bearbeiten?

Erstes Container-Image

Erstellen Sie im Projekt außerhalb der Arbeitskopie einen Ordner für das Image:

mkdir -p ~/AgentSandbox/cursor-linux
cd ~/AgentSandbox/cursor-linux

Speichern Sie dort als Containerfile:

FROM debian:bookworm-slim

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       bash \
       ca-certificates \
       build-essential \
       git \
       python3 \
       python3-venv \
       python3-pip \
    && rm -rf /var/lib/apt/lists/* \
    && useradd --create-home --shell /bin/bash agent

USER agent
WORKDIR /workspace

ENV HOME=/home/agent
ENV PIP_DISABLE_PIP_VERSION_CHECK=1

CMD ["/bin/bash"]

Dieses Beispiel enthält nur einen Linux-Grundwerkzeugsatz. Wenn Ihr Projekt Node.js, Java, Go oder Rust benötigt, ergänzen Sie das Image bewusst. Installieren Sie nicht bei jedem Agent-Lauf beliebige Pakete als Root. Besser ist ein geprüftes Image, das Sie bei Änderungen neu bauen und versionieren.

Bauen Sie das Image:

container build \
  --tag cursor-agent-linux:local \
  --file Containerfile \
  .

Der Image-Bau benötigt normalerweise Zugriff auf eine Registry oder Paketquellen. Der spätere Testlauf kann dagegen ohne Netzwerk erfolgen, wenn alle benötigten Werkzeuge bereits im Image liegen. Halten Sie Build- und Ausführungsphase deshalb getrennt.

Startskript mit begrenztem Schreibbereich

Legen Sie im selben Ordner sandbox-run.sh an:

#!/bin/bash
set -euo pipefail

if [[ $# -lt 2 ]]; then
  echo "Verwendung: $0 /absoluter/pfad/zur/arbeitskopie befehl [argumente ...]" >&2
  exit 64
fi

WORKSPACE="$1"
shift

if [[ "$WORKSPACE" != /* ]]; then
  echo "Der Arbeitskopie-Pfad muss absolut sein." >&2
  exit 64
fi

if [[ ! -d "$WORKSPACE" ]]; then
  echo "Arbeitskopie nicht gefunden: $WORKSPACE" >&2
  exit 66
fi

case "$WORKSPACE" in
  "$HOME"/AgentWorkspaces/*)
    ;;
  *)
    echo "Abbruch: Nur Arbeitskopien unter \$HOME/AgentWorkspaces sind erlaubt." >&2
    exit 77
    ;;
esac

exec container run \
  --rm \
  --read-only \
  --network none \
  --mount "type=bind,source=${WORKSPACE},target=/workspace" \
  --mount "type=tmpfs,target=/tmp,size=1G,mode=1777" \
  --mount "type=tmpfs,target=/home/agent/.cache,size=1G,mode=700" \
  cursor-agent-linux:local \
  "$@"

Aktivieren Sie das Skript:

chmod 700 sandbox-run.sh

Die einzelnen Sicherheitsentscheidungen haben unterschiedliche Aufgaben:

• --rm entfernt die Container-Instanz nach dem Ende.
• --read-only macht das Root-Dateisystem des Containers schreibgeschützt.
• --network none startet den Lauf ohne Netzwerkschnittstelle. Prüfen Sie diese Option gegen den installierten Release-Stand; sie wurde in der Apple-Container-Entwicklung nachträglich ergänzt und ist nicht mit jeder älteren Version verfügbar. (github.com)
• Der Bind-Mount stellt ausschließlich die Arbeitskopie unter /workspace bereit.
• tmpfs nimmt temporäre Dateien und Cache-Daten auf. Diese Daten verschwinden beim Stoppen des Containers. (github.com)
• Der Prozess läuft als Benutzer agent, nicht als Root.

Der entscheidende Vorbehalt bleibt: /workspace ist schreibbar. Wenn Sie dort eine Host-Datei mounten, darf der Prozess diese Datei verändern oder löschen. --read-only schützt nicht vor Änderungen in einem ausdrücklich schreibbaren Mount. Für reine Analyse können Sie den Code stattdessen schreibgeschützt einbinden:

container run \
  --rm \
  --read-only \
  --network none \
  --mount "type=bind,source=${WORKSPACE},target=/workspace,readonly" \
  cursor-agent-linux:local \
  bash -lc 'git status --short && python3 -m compileall -q .'

Netzwerk, Schlüssel und Umgebungsvariablen

Viele Agent-Läufe benötigen zunächst Netzwerkzugriff für Paketinstallation. Genau dort entstehen zusätzliche Risiken: Ein manipuliertes Skript kann Umgebungsvariablen auslesen, Daten an einen externen Dienst senden oder fremde Inhalte nachladen.

Verwenden Sie für Prüfungen und Tests zunächst:

./sandbox-run.sh \
  "$HOME/AgentWorkspaces/mein-projekt-agent" \
  bash -lc 'python3 -m pytest'

Wenn der Test wegen fehlender Downloads scheitert, entscheiden Sie bewusst zwischen zwei Phasen:

1. Vorbereitung mit Netzwerk: Image bauen oder Abhängigkeiten in einer kontrollierten Umgebung aktualisieren.
2. Ausführung ohne Netzwerk: Test, Linter und Build mit festgelegten Dateien starten.

Für einen kontrollierten Netzlauf können Sie unter macOS 26 ein eigenes internes Container-Netzwerk anlegen. Apple dokumentiert benutzerdefinierte Netzwerke und die Option --internal für hostinterne Netzwerke. Das ist nicht dasselbe wie freier Internetzugriff. (github.com)

container network create --internal agent-intern

Starten Sie dann nur Aufgaben, die diese Netzwerktopologie wirklich benötigen:

container run \
  --rm \
  --read-only \
  --network agent-intern \
  --mount "type=bind,source=${WORKSPACE},target=/workspace" \
  --mount "type=tmpfs,target=/tmp,size=1G,mode=1777" \
  cursor-agent-linux:local \
  bash -lc 'make test'

Montieren Sie niemals pauschal:

~/Library
~/.ssh
~/.aws
~/.config
~/Library/Keychains
Produktions-Env-Dateien

Übergeben Sie auch keine kompletten Host-Umgebungsvariablen. Ein Befehl wie --env AWS_ACCESS_KEY_ID oder das Weiterreichen einer ganzen .env-Datei macht die Containergrenze für diese Geheimnisse praktisch wertlos. Falls ein Zugriff unvermeidbar ist, verwenden Sie ein kurzlebiges Token mit minimalen Rechten und entfernen Sie es nach einem einzelnen Lauf. Die sicherste Standardeinstellung bleibt: kein Schlüssel, kein Socket, kein Produktionszugang.

Cursor Agent in die Ausführungskette einbinden

Öffnen Sie in Cursor ausschließlich:

~/AgentWorkspaces/mein-projekt-agent

Legen Sie dort eine Regeldatei an, die den Agent auf das Skript verpflichtet:

# Agent-Ausführungsregeln

- Führen Sie Tests, Linter und Build-Befehle nur über ../sandbox-run.sh aus.
- Arbeiten Sie ausschließlich in der geöffneten Arbeitskopie.
- Verwenden Sie keine Pfade unter /Users außerhalb von /workspace.
- Lesen oder verändern Sie keine SSH-, Cloud-, Keychain- oder Produktionsdateien.
- Löschen Sie keine Dateien ohne manuelle Bestätigung.
- Veröffentlichen Sie nichts und führen Sie keine Deployment-Befehle aus.

Die Regel hilft bei der Orientierung. Sie ist keine Betriebssystemgrenze. Wenn Cursor einen Befehl außerhalb des Wrappers vorschlägt, stoppen Sie den Lauf und prüfen Sie ihn. Lassen Sie die Terminal-Freigaben aktiviert. Cursor dokumentiert, dass Auto-Review, Allowlist und vollständige automatische Ausführung unterschiedliche Freigabestufen bieten; „Run Everything“ entfernt dabei die wichtigste menschliche Kontrollstelle.

Automatisch vertretbar sind in einer vorbereiteten, netzlosen Umgebung beispielsweise:

• python3 -m pytest
• npm test, wenn Node.js im Image vorhanden ist
• make test
• Linter und Formatprüfungen
• lokale Compiler-Aufrufe
• Lesen von Git-Diffs

Manuelle Bestätigung benötigen:

• rm, mv oder rekursive Löschoperationen
• Änderungen außerhalb von /workspace
• Zugriff auf Tokens und Zertifikate
• Paketinstallationen mit Netzwerk
• git push
• Veröffentlichungen und Deployments
• Änderungen an macOS-Konfigurationen
• Socket-, SSH-Agent- oder Keychain-Zugriff

.cursorignore können Sie ergänzend für .env, Zertifikate und große Build-Ordner einsetzen. Verlassen Sie sich aber nicht darauf, dass damit jeder Terminalzugriff blockiert wird. Die offizielle Dokumentation weist ausdrücklich auf diese Grenze hin.

Destruktive Abnahme

Führen Sie vor dem ersten echten Agent-Lauf einen absichtlichen Schadenstest durch. Eine Sandbox ist erst dann brauchbar, wenn Sie nicht nur einen erfolgreichen Test sehen, sondern auch einen verbotenen Zugriff nachweisen.

Abnahme-Checkliste

• [ ] Apple-Silicon-Architektur mit uname -m bestätigt
• [ ] macOS-Version und Apple-Container-Release dokumentiert
• [ ] container system status zeigt einen laufenden Dienst
• [ ] Cursor öffnet nur die wegwerfbare Arbeitskopie
• [ ] Original-Repository besitzt eine unveränderte Köderdatei
• [ ] Arbeitskopie besitzt eine separate Köderdatei
• [ ] sandbox-run.sh lehnt Pfade außerhalb von ~/AgentWorkspaces/ ab
• [ ] Container startet mit --read-only
• [ ] Container startet ohne Netzwerkschnittstelle oder mit kontrolliertem internen Netz
• [ ] Kein Home-Verzeichnis, kein SSH-Verzeichnis und keine Keychain-Daten sind gemountet
• [ ] Ein Test kann Dateien in /workspace erzeugen und ändern
• [ ] Ein Test kann die Originalkopie nicht erreichen
• [ ] Ein absichtlicher Zugriff auf /Users außerhalb des Mounts schlägt fehl
• [ ] Container wird nach dem Lauf entfernt
• [ ] Temporäre Dateien und Caches bleiben nicht im Arbeitsverzeichnis zurück
• [ ] git diff zeigt nur erwartete Änderungen
• [ ] Kein Token erscheint in Dateien, Logs oder Prozessargumenten

Ein einfacher Schreibtest sieht so aus:

./sandbox-run.sh \
  "$HOME/AgentWorkspaces/mein-projekt-agent" \
  bash -lc '
    printf "Container-Test\n" > /workspace/_sandbox-test/container-marker.txt
    rm -f /workspace/_sandbox-test/container-marker.txt
    test ! -e /workspace/_sandbox-test/container-marker.txt
  '

Der Test soll erfolgreich sein. Das beweist, dass die Arbeitskopie veränderbar ist. Danach prüfen Sie die Originalkopie:

cd ~/src/mein-projekt
git status --short
test -f _sandbox-test/host-copy-marker.txt

Wenn die Originaldatei fehlt oder verändert wurde, brechen Sie ab. Dann wurde entweder der falsche Pfad gemountet, ein anderer Prozess verwendet oder der Agent hat den Wrapper umgangen.

Prüfen Sie auch die Netzgrenze:

./sandbox-run.sh \
  "$HOME/AgentWorkspaces/mein-projekt-agent" \
  bash -lc 'getent hosts example.com || true'

Bei --network none darf daraus keine funktionierende externe Namensauflösung entstehen. Wenn Ihr Projekt einen internen Netzwerkzugriff benötigt, dokumentieren Sie exakt, welche Dienste erreichbar sein müssen. Eine pauschale Freigabe für alle Ziele macht die Containerisierung deutlich schwächer.

Wartung und Teamgrenzen

Aktualisieren Sie das Image kontrolliert. Ein neues Basisimage oder ein neues Paket kann das Verhalten der Tests ändern. Speichern Sie deshalb neben dem Containerfile auch die verwendete Image-Kennung und die Ausgabe von:

container system version
container image list

Löschen Sie nicht benötigte Container und Volumes regelmäßig. Bei benannten Volumes ist besondere Vorsicht nötig: Apple dokumentiert, dass container volume prune ungenutzte Volumes samt Inhalt sofort löscht und die Daten nicht wiederhergestellt werden können.

Für eine Einzelperson reicht die lokale Variante oft aus, wenn:

• nur eine Person den Mac nutzt,
• die Arbeitskopie jederzeit neu erzeugt werden kann,
• keine produktiven Schlüssel im Agent-Lauf liegen,
• Linux-Werkzeuge ausreichen,
• die Container-Befehle nachvollziehbar bleiben.

Für ein Team steigt der Aufwand schnell. Sie benötigen dann ein gemeinsames Image, feste Versionen, nachvollziehbare Logs, eine einheitliche Cursor-Konfiguration und Regeln für Geheimnisse. Wenn mehrere Agenten parallel arbeiten, Remotezugriff erforderlich ist oder jede Aufgabe per Knopfdruck zurückgesetzt werden soll, ist eine unabhängige Mac- oder Cloud-Umgebung häufig sauberer als viele individuelle lokale Skripte.

Ihre aktuelle Host-Lösung hat dabei drei typische Nachteile: Sie exponiert versehentlich das persönliche Home-Verzeichnis, sie macht die Sicherheitsregeln von jedem einzelnen Entwickler abhängig und sie lässt sich bei einem beschädigten Arbeitsstand nicht immer sofort reproduzieren. Eine gemietete, getrennte Mac-Umgebung von MacHTML kann für temporäre Agent-Aufgaben angenehmer sein, wenn Sie einen frischen Arbeitsstand, getrennte Zugänge und einen schnellen Reset benötigen. Für dauerhaft hohe Last oder Anforderungen an physische Geräte ist der Kauf und die eigene Verwaltung eines Macs weiterhin die ehrlichere Option.

Wenn Sie die lokale Variante zuerst auf einer getrennten Umgebung erproben möchten, können Sie die verfügbaren Mac-Umgebungen prüfen, die Konsole für den Zugriff verwenden und bei Fragen die technische Hilfe heranziehen. Entscheidend bleibt nicht der Name des Containers, sondern die nachweisbare Kette: wegwerfbare Kopie, begrenzter Mount, keine unnötigen Schlüssel, kontrolliertes Netzwerk und eine bestandene destruktive Abnahme.