yolo-claude et yolo-codex — alias bash pour la full autonomie

Deux alias zsh qui font basculer Claude Code et Codex CLI en mode pleine autonomie : zéro prompt d'approbation, max reasoning effort, longues boucles. C'est ce que j'utilise quand je veux laisser tourner un agent pendant que je fais autre chose — sur un dossier jetable ou un worktree dédié, jamais sur main.

Les deux alias

À coller dans ~/.zshrc (ou ~/.bashrc si tu es en bash) :

alias yolo-claude="CLAUDE_CODE_EFFORT_LEVEL=max claude --dangerously-skip-permissions --max-turns 200"
alias yolo-codex='codex --dangerously-bypass-approvals-and-sandbox -c model_reasoning_effort="high"'

Puis source ~/.zshrc et tu peux taper yolo-claude ou yolo-codex depuis n'importe quel dossier.

Décryptage des flags

yolo-claude combine trois choses :

• CLAUDE_CODE_EFFORT_LEVEL=max — variable d'env qui demande à Claude de réfléchir plus longtemps avant chaque action (équivalent du "think harder"). Coût plus élevé, qualité bien meilleure sur les tâches non triviales.
• --dangerously-skip-permissions — auto-approuve toutes les Bash, Edit, Write. Pas de pop-up "Allow this command?". Le flag est nommé dangerously exprès.
• --max-turns 200 — autorise jusqu'à 200 tours de boucle agentique avant que Claude s'arrête. Le défaut est ~50, ce qui coupe certaines tâches longues en plein milieu.

yolo-codex combine deux choses :

• --dangerously-bypass-approvals-and-sandbox — équivalent OpenAI : auto-approuve toutes les commandes shell ET désactive le sandbox réseau/FS qu'a Codex par défaut.
• -c model_reasoning_effort="high" — passe le model en reasoning effort maximum. Coûte 2-3× plus, mais nécessaire pour les longues sessions agentiques propres.

Quand l'utiliser

YOLO mode = pour les contextes où tu n'as pas besoin de confirmer chaque action, et où le pire scénario reste contenu :

• Worktree git dédié créé pour la tâche (git worktree add ../task-x), branch jetable
• Conteneur Docker isolé (mount uniquement le dossier de travail)
• VPS jetable (Hetzner $5, instance Lima ou OrbStack)
• Dossier sandbox type ~/sandbox/throwaway/ que tu peux rm -rf sans regret
• Tâche d'exploration où tu connais déjà le résultat attendu (réécrire un module, faire une migration sur une copie)
• Tâche de génération massive (ex : créer 50 composants UI à partir d'un design system)

Tu peux lancer puis aller faire autre chose. C'est tout l'intérêt — récupérer le temps que tu passais à cliquer Approve tous les 8 secondes.

Quand surtout PAS l'utiliser

YOLO sur ton repo de prod ou ton dossier ~/ est une mauvaise idée. Le worst-case d'un agent autonome :

• rm -rf sur le mauvais dossier (il s'est trompé de chemin)
• git push --force sur main (il a "résolu" un conflit en écrasant)
• curl ... | bash un script suspect (il a cherché une solution sur Stack Overflow et l'a appliquée)
• Lecture / leak de secrets via cat .env envoyé à un service externe
• Modification silencieuse de configs système (/etc/hosts, crontab)

Les risques sont réels — pas théoriques. Plusieurs incidents documentés en 2025-2026 où des dev ont perdu des heures de boulot ou leak des creds parce qu'ils ont YOLO sur leur dossier perso. Voir aussi sécuriser Claude Code pour le setup deny rules systémique.

Sandbox recommandé : worktree git

Le pattern le plus simple et le moins cher pour YOLO en sécurité :

# Crée un worktree dédié pour cette tâche
git worktree add ../mon-projet-yolo -b yolo/feature-x
cd ../mon-projet-yolo

# Lance Claude en YOLO
yolo-claude

# Quand t'es content, merge proprement
cd ../mon-projet
git merge yolo/feature-x
git worktree remove ../mon-projet-yolo

Tu gardes ton main et ton working tree principaux propres. Si Claude fait n'importe quoi dans le worktree, tu git worktree remove --force et c'est terminé. Aucun fichier n'a touché ton dossier principal.

Sandbox plus sérieux : Docker / OrbStack

Pour les sessions vraiment longues ou les tâches qui touchent à des installations système, monte un container :

docker run -it --rm \
  -v "$(pwd):/work" \
  -w /work \
  --env CLAUDE_CODE_OAUTH_TOKEN \
  node:22 bash
# dans le container
npm i -g @anthropic-ai/claude-code
yolo-claude  # mais redéfinis l'alias, le ~/.zshrc n'est pas monté

Le container voit uniquement le dossier monté. Si Claude rm -rf / (déjà arrivé en démo), c'est le container qui meurt, pas ta machine.

OrbStack ou Lima font ça plus joliment sur Mac avec un overhead minimal vs Docker Desktop.

Bonnes pratiques associées

Quelques règles pour limiter les dégâts si ça part en vrille :

• .claude/settings.json avec deny rules — bloque la lecture de .env*, *.pem, **/.ssh/** au niveau du système, même en YOLO. Voir sécuriser Claude Code.
• Pre-commit hook qui scanne les secrets — .git/hooks/pre-commit qui grep les patterns Anthropic / OpenAI / AWS / GitHub avant tout commit.
• gitignore audité — .env, .env.local, secrets/, .ssh/, *.pem, *.key dans la liste depuis le jour 0.
• Branche dédiée — jamais YOLO sur main directement. yolo/<task> ou wip/<task>.
• set -o noclobber dans ton zshrc — empêche les > d'écraser un fichier existant sans >!.
• Time-box — décide à l'avance combien de temps tu laisses tourner. "Si dans 30 min c'est pas convergé, je kill".

FAQ

C'est vraiment safe avec un worktree git ? Quasiment. Le worktree partage le même .git/ que le repo principal — donc un agent qui fait git push --force peut quand même affecter ton remote. Pour vraiment isoler, copie le dossier ailleurs (cp -r mon-projet ~/sandbox/) ou utilise un container. Le worktree protège ton working tree et tes branches non-mergées, pas le remote.

Pourquoi --max-turns 200 et pas --max-turns 1000 ? 200 est un compromis entre "laisse tourner" et "ne ruine pas mon mois en API". À 200 tours, Claude a largement le temps de finir une feature non-triviale. Au-delà, soit la tâche est trop grosse et il faut la découper, soit l'agent boucle (et tu veux qu'il s'arrête pour que tu interviennes). Tune selon ton budget API.

CLAUDE_CODE_EFFORT_LEVEL=max vs default — vraie différence ? Significative sur les tâches non-triviales. Sur du code complexe (refactor multi-fichiers, debug subtil, design d'architecture), le mode max produit du résultat propre du premier coup où le mode default itère 5 fois. Le ratio coût/temps économisé en main d'œuvre humaine vaut largement le surcoût API.

Codex YOLO vs Claude Code YOLO — lequel choisir ? Les deux sont valables. Claude Code est mieux pour les longues sessions de refactoring où tu veux qu'il garde le contexte. Codex (GPT-5.5) est plus rapide et meilleur pour les one-shot scripts et la génération massive (templates, migrations SQL, batch de fichiers similaires). En pratique j'alterne selon le type de tâche.

Et aider, cursor, cline — ils ont un mode YOLO aussi ? Oui mais avec des syntaxes différentes. Aider a --yes-always qui auto-confirme. Cline et Cursor ont des toggles dans leurs settings UI. La logique reste la même : auto-approbation + max effort + sandbox isolé. Voir stack IA frontier pour le panorama complet.

Worktree dédié + yolo-claude → laisse tourner.
Reviens dans 20 min.

Le YOLO mode n'est pas un raccourci pour skip la review — c'est un raccourci pour skip les pop-ups d'approbation pendant que l'agent bosse. Tu reviens, tu reviewes le diff, tu mergeze. La revue humaine reste obligatoire — c'est juste qu'elle se fait en bloc à la fin, pas tour par tour.