2026 Cursor Agent craint les suppressions de fichiers ? Utilisez Apple Container pour un bac à sable isolé

Un rm -rf lancé au mauvais endroit, un fichier de configuration remplacé, puis votre dépôt principal est inutilisable.

La solution la plus rapide consiste à combiner une copie jetable du code avec un bac à sable pour Cursor Agent fondé sur Apple Container. Ne vous reposez pas sur une liste noire de commandes : le conteneur peut isoler un environnement Linux, mais il ne protège pas un dossier macOS que vous montez volontairement en écriture.

Dernière mise à jour : 29 août 2026. Les exigences système, les commandes et la version stable ont été vérifiées dans la documentation officielle d’Apple Container et dans la documentation de sécurité de Cursor. La version stable publiée la plus récente d’Apple Container est 1.3.0, publiée le 24 août 2026. (versions officielles d’Apple Container)

Cette procédure s’adresse à vous si vous laissez régulièrement Cursor Agent installer des dépendances, modifier plusieurs fichiers, compiler, lancer des tests ou exécuter des scripts. Elle convient aussi aux responsables d’un petit environnement de développement qui cherchent une règle d’exécution reproductible. Si vous comparez déjà une isolation locale avec un Mac distant réinitialisable, les limites de la dernière partie vous aideront à trancher.

Avant le premier lancement : ce qu’Apple Container isole réellement

Apple Container exécute des conteneurs Linux sous la forme de machines virtuelles légères sur un Mac équipé d’une puce Apple. Il ne lance pas un environnement macOS complet à l’intérieur du conteneur. Le projet officiel indique également que macOS 26 est la version prise en charge, car l’outil exploite les évolutions de la virtualisation et du réseau introduites dans cette version. (prérequis et installation officiels d’Apple Container)

Cette distinction évite une erreur fréquente : croire qu’un conteneur Linux remplace une machine virtuelle macOS. Pour un pipeline audio, vidéo ou design qui dépend de Xcode, de Metal, d’un trousseau de signature ou d’un outil graphique natif, Apple Container n’est qu’une partie de la chaîne.

Le second point concerne Cursor. Les règles d’agent, les approbations de terminal, les modes d’exécution et le fichier .cursorignore sont des garde-fous applicatifs. Cursor précise que ses protections sont des mesures « best-effort », et non une frontière de sécurité matérielle. De plus, .cursorignore limite l’accès de l’agent aux fichiers indexés, mais les commandes de terminal et les outils externes peuvent encore accéder à des fichiers ignorés. (documentation officielle de sécurité de Cursor)

Un conteneur Apple Container peut-il remplacer l’isolation habituelle d’un environnement de développement ?
Il peut remplacer une partie de la chaîne de développement Linux, mais pas l’environnement macOS complet. Il est pertinent pour les dépendances, la compilation, les tests et les scripts. Il ne doit pas recevoir votre dossier personnel, vos clés privées, votre trousseau exporté ou votre dépôt original avec des droits d’écriture.

Préparer une copie récupérable plutôt que protéger le mauvais dossier

Le premier objectif n’est pas de rendre Cursor inoffensif. C’est de faire en sorte qu’une erreur n’atteigne pas la seule copie valable du projet.

Commencez par vérifier les prérequis :

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

Sur un Mac Apple Silicon, uname -m doit retourner l’architecture ARM correspondante. La documentation officielle exige une puce Apple et prend en charge macOS 26. Utilisez ensuite l’installateur signé correspondant à la version stable publiée, puis démarrez le service :

container system start

Ne copiez pas une commande issue d’un article ancien sans vérifier sa présence dans la documentation de la version installée. La référence de commandes publiée sur la branche actuelle signale elle-même que la disponibilité peut varier selon la version de macOS et recommande de consulter le document associé à la version ciblée. (référence officielle des commandes Apple Container)

Créez ensuite un espace réservé aux copies de travail :

mkdir -p "$HOME/AgentWorkspaces"
cd "$HOME/AgentWorkspaces"

git clone /chemin/vers/votre-depot projet-agent
cd projet-agent

git status --short
git worktree add ../projet-agent-work agent-sandbox

Vous pouvez utiliser un clonage temporaire au lieu de git worktree. Dans les deux cas, Cursor doit ouvrir projet-agent-work, jamais le dépôt principal.

Ajoutez quelques éléments de contrôle :

mkdir -p .sandbox-check
printf 'FICHIER-LEURRE-NE-PAS-SUPPRIMER\n' > .sandbox-check/important.txt
printf 'ORIGINAL-HOST-TEST\n' > "$HOME/AgentWorkspaces/original-marker.txt"

git status --short

Le fichier leurre sert à vérifier que l’agent peut modifier la copie prévue. Le marqueur placé en dehors du projet permet de confirmer qu’une commande de suppression n’a pas débordé du périmètre autorisé.

Avant de continuer, vérifiez que les changements non validés sont sauvegardés. Une copie jetable n’est pas une sauvegarde si elle n’est jamais reconstruite.

Construire le conteneur minimal et non privilégié

Le fichier ci-dessous installe une base Linux générique. Il ne prétend pas connaître les besoins de votre projet. Ajoutez uniquement les outils réellement nécessaires dans la commande apt-get. Pour un projet Python, Node.js, Rust ou audio, adaptez l’image et les paquets plutôt que d’installer un environnement universel trop large.

Créez Containerfile dans un dossier séparé, par exemple ~/AgentSandbox :

FROM ubuntu:24.04

ENV DEBIAN_FRONTEND=noninteractive

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       bash \
       ca-certificates \
       build-essential \
       git \
       python3 \
       python3-pip \
       pkg-config \
    && rm -rf /var/lib/apt/lists/* \
    && useradd --create-home --shell /bin/bash agent \
    && mkdir -p /workspace /tmp/agent-cache \
    && chown -R agent:agent /workspace /tmp/agent-cache

USER agent
WORKDIR /workspace

CMD ["/bin/bash"]

Construisez l’image avec la commande officielle :

cd "$HOME/AgentSandbox"

container build \
  --progress plain \
  --tag cursor-agent-sandbox:local \
  --file Containerfile \
  .

Apple Container accepte un Dockerfile ou un Containerfile pour la construction d’une image OCI. Le paramètre --tag associe un nom local à l’image.

Le choix USER agent est important. Il empêche de transformer chaque commande de l’agent en opération root dans le conteneur. Il ne suffit toutefois pas à protéger l’hôte : un utilisateur non root peut toujours supprimer les fichiers d’un montage hôte si ce montage lui donne les droits nécessaires.

Créez ensuite sandbox-run.sh :

#!/bin/bash
set -euo pipefail

if [ "$#" -lt 2 ]; then
  echo "Usage : $0 CHEMIN_COPIE COMMANDE [ARGUMENTS...]" >&2
  exit 64
fi

WORKSPACE="$1"
shift

if [ ! -d "$WORKSPACE" ]; then
  echo "Le dossier de travail n'existe pas : $WORKSPACE" >&2
  exit 66
fi

WORKSPACE="$(cd "$WORKSPACE" && pwd -P)"

case "$WORKSPACE" in
  "$HOME/AgentWorkspaces"/*)
    ;;
  *)
    echo "Refus : le dossier doit se trouver sous $HOME/AgentWorkspaces." >&2
    exit 77
    ;;
esac

exec container run \
  --rm \
  --read-only \
  --network none \
  --no-dns \
  --mount "type=bind,source=$WORKSPACE,target=/workspace" \
  --tmpfs "/tmp:size=1G,mode=1777" \
  --tmpfs "/run:size=64M,mode=755" \
  --workdir /workspace \
  cursor-agent-sandbox:local \
  "$@"

Rendez-le exécutable :

chmod +x "$HOME/AgentSandbox/sandbox-run.sh"

Les options remplissent des rôles différents :

• --rm supprime l’instance après son arrêt ;
• --read-only rend le système racine du conteneur non modifiable ;
• --network none désactive l’attachement réseau ;
• --no-dns évite de configurer la résolution DNS ;
• le montage bind expose uniquement la copie du projet ;
• les montages tmpfs reçoivent les caches et fichiers temporaires ;
• --workdir /workspace place la commande dans le seul répertoire de travail prévu.

La documentation d’Apple Container confirme la syntaxe des montages, l’option readonly et l’usage de tmpfs. Le contenu d’un tmpfs disparaît lorsque le conteneur s’arrête. (documentation officielle des montages et systèmes temporaires)

Comment limiter Cursor Agent au seul dossier du projet ?
Vous devez combiner trois restrictions : ouvrir uniquement la copie jetable dans Cursor, refuser dans le script tout chemin situé hors de AgentWorkspaces, puis monter cette copie à /workspace. .cursorignore peut réduire l’indexation de fichiers sensibles, mais il ne remplace pas ces restrictions de chemin ni le montage contrôlé.

Comparer les modes réseau, les secrets et le degré d’automatisation

Le mode --network none est le choix par défaut pour une commande qui n’a pas besoin de télécharger quoi que ce soit. Il bloque les installations en ligne et les appels vers des services externes. Préparez donc les dépendances pendant la construction de l’image, ou utilisez un réseau contrôlé uniquement pendant une phase explicitement nécessaire.

Ne montez jamais ces chemins dans le conteneur :

$HOME
$HOME/.ssh
$HOME/.config
$HOME/Library/Keychains
$HOME/.aws
$HOME/.npmrc
$HOME/.config/gcloud

Évitez également de passer automatiquement tout l’environnement du shell. Une variable anodine peut contenir un jeton de registre, une URL privée ou une information de production.

Si une dépendance privée est indispensable, préférez un jeton à durée courte, limité à la lecture, injecté pour une seule commande. Ne l’écrivez ni dans le Containerfile, ni dans l’image finale, ni dans un fichier monté depuis votre dossier personnel.

Le montage en écriture reste le point critique. Même avec un système racine en lecture seule, l’agent peut supprimer, renommer ou remplacer les fichiers présents dans /workspace si ceux-ci sont accessibles en écriture. La protection vient donc d’abord de la nature jetable de la copie.

Un réseau désactivé n’est pas toujours compatible avec la construction de l’image. Dans ce cas, séparez les phases :

1. construisez l’image avec les outils nécessaires ;
2. lancez les tests sans réseau ;
3. réactivez temporairement un réseau contrôlé uniquement pour télécharger les dépendances ;
4. reconstruisez ou nettoyez la copie avant de reprendre les tests.

Une liste noire de commandes comme rm, sudo ou curl ne suffit pas. Un agent peut atteindre le même résultat avec Python, Node.js, un script shell indirect ou une commande composée. La frontière utile est le chemin monté, le compte utilisé et le réseau disponible.

Brancher Cursor Agent sur le script sans lui donner un faux sentiment de sécurité

Dans Cursor, ouvrez uniquement :

~/AgentWorkspaces/projet-agent-work

Ajoutez ensuite un fichier de règles de projet qui demande à l’agent d’utiliser le script pour les commandes Linux :

Pour installer des dépendances, compiler, tester ou exécuter un script Linux, utilise uniquement :
~/AgentSandbox/sandbox-run.sh "$PWD" <commande>

Ne lance pas directement de commande de suppression, de publication, de modification du trousseau, de gestion des clés SSH ou de changement de configuration macOS.
Demande une validation humaine avant toute opération hors du répertoire de travail.
Ne suppose jamais que .cursorignore protège le terminal.

Cette règle améliore la cohérence du comportement, mais elle ne garantit pas que chaque commande passera par le script. Cursor indique que les modes d’exécution et les approbations sont des protections à effort limité. Conservez donc l’approbation des commandes sensibles et utilisez le versionnement pour revenir en arrière.

Vous pouvez laisser l’automatisation couvrir :

• l’installation de paquets dans le conteneur ;
• la génération de fichiers dans la copie jetable ;
• la compilation ;
• les tests unitaires ;
• le formatage ;
• l’analyse statique ;
• la création de fichiers temporaires.

Demandez une validation manuelle pour :

• toute suppression récursive ;
• toute commande utilisant un secret ;
• toute écriture hors de /workspace ;
• toute publication ;
• toute migration de base de données ;
• toute modification de la configuration macOS ;
• toute opération de signature ou d’accès au trousseau ;
• toute commande qui réactive le réseau.

Pour une équipe, placez le script dans un dépôt d’outillage versionné et faites contrôler les fichiers de permissions au niveau de l’organisation. Cursor permet une configuration globale et une configuration de projet pour les modes et les règles ; utilisez la première pour le socle commun, la seconde pour les exceptions documentées. Ne laissez pas chaque développeur réécrire seul les chemins autorisés.

Vérifier la destruction, la sortie du conteneur et les fuites de secrets

La première exécution doit être volontairement destructive. Ne commencez pas avec un dépôt important.

Lancez une commande de diagnostic :

"$HOME/AgentSandbox/sandbox-run.sh" \
  "$HOME/AgentWorkspaces/projet-agent-work" \
  bash -lc 'id; pwd; find /workspace -maxdepth 2 -type f | sort | head -50'

Testez ensuite la suppression du leurre :

"$HOME/AgentSandbox/sandbox-run.sh" \
  "$HOME/AgentWorkspaces/projet-agent-work" \
  bash -lc 'rm -f /workspace/.sandbox-check/important.txt'

Le fichier leurre doit disparaître de la copie de travail. Le marqueur situé dans ~/AgentWorkspaces/original-marker.txt doit rester intact. Le dépôt principal doit également rester inchangé :

test -f "$HOME/AgentWorkspaces/original-marker.txt"
git -C /chemin/vers/votre-depot status --short
container list --all

Vérifiez les points suivants avant d’autoriser Cursor Agent à travailler sur un vrai projet :

• [ ] Le Mac utilise une puce Apple et macOS 26.
• [ ] La version stable d’Apple Container a été vérifiée sur la page officielle.
• [ ] Le service container démarre et répond.
• [ ] Cursor ouvre une copie jetable, pas le dépôt principal.
• [ ] Le script refuse un chemin extérieur à AgentWorkspaces.
• [ ] Le conteneur s’exécute avec l’utilisateur agent, non avec root.
• [ ] Le système racine du conteneur est en lecture seule.
• [ ] Le code monté est le seul volume hôte en écriture.
• [ ] Le réseau et le DNS sont désactivés pour les tests sans dépendances externes.
• [ ] Aucun dossier personnel, fichier SSH ou trousseau n’est monté.
• [ ] Le fichier leurre est supprimable uniquement dans la copie de test.
• [ ] Le marqueur hors projet reste présent après la commande destructive.
• [ ] container list --all ne conserve pas d’instance inattendue.
• [ ] Les différences Git sont examinées avant toute synchronisation.
• [ ] Aucun secret n’apparaît dans les journaux, les fichiers temporaires ou l’image.

Le nettoyage doit être explicite. --rm supprime le conteneur arrêté, mais les volumes anonymes ne sont pas nécessairement supprimés automatiquement. Si vous utilisez des volumes nommés pour les caches, inspectez-les puis lancez le nettoyage approprié, notamment la commande container volume prune documentée par Apple Container.

Si l’un des contrôles échoue, revenez à la copie de travail et ne montez pas le dépôt original. Une validation « partielle » n’est pas un résultat acceptable pour un agent qui peut exécuter des commandes arbitraires.

Choisir entre isolation locale et environnement Mac réinitialisable

Pour un développeur seul, Apple Container apporte une séparation utile sans déplacer toute la compilation vers une infrastructure distante. Vous gardez l’éditeur et les fichiers de travail sur le Mac, tout en déportant les outils Linux, les caches et les tests dans une machine virtuelle légère.

Pour une équipe, les limites arrivent plus vite : les images doivent rester identiques, les copies doivent être recréées rapidement, les journaux doivent être centralisés et les tâches à risque ne doivent pas partager les mêmes identifiants. Les projets audio, vidéo et design ajoutent une autre contrainte : les outils macOS natifs, les interfaces graphiques et les flux de signature restent sur l’hôte.

Si votre configuration actuelle expose directement le dépôt principal, elle vous laisse trois faiblesses concrètes : une suppression peut toucher l’historique local, les clés personnelles restent potentiellement lisibles par un processus autorisé à utiliser le terminal, et plusieurs utilisateurs ne disposent pas forcément du même environnement de nettoyage. Le remplacement par une copie jetable et un conteneur local corrige une grande partie de ces risques, mais pas le besoin de macOS natif ni celui d’un accès distant partagé.

Lorsque vous devez fournir un environnement isolé à plusieurs personnes, réinitialiser une machine après chaque tâche ou éviter complètement l’exposition des fichiers personnels, la location d’un Mac dédié via MacHTML peut être plus cohérente qu’un bricolage local répété. Vous pouvez consulter la console de gestion des environnements Mac pour évaluer le cycle de création et de remise à zéro, puis comparer les contraintes avec votre procédure locale dans le centre d’aide MacHTML.

La règle de décision est simple : utilisez Apple Container pour les tâches Linux jetables et vérifiables ; passez à un environnement Mac indépendant lorsque l’agent doit toucher à macOS, être partagé par plusieurs personnes ou manipuler des données que vous ne voulez jamais monter sur votre poste principal.