Cette page est traduite de la documentation anglaise. Les commandes, identifiants et exemples sont inchangés. Runtime 7.24.4 · SDK 2.6.7. Source anglaise

Mode autonome

Statut : Actif Portée : état actuel Dernière revue : 2026-08-25 Responsable : runtime ax-code

Le mode autonome permet à ax-code d’achever des tâches sans attendre une confirmation humaine à chaque étape à faible risque. Lorsqu’il est activé, les invites de permission sont approuvées automatiquement, sauf si elles sont explicitement bloquées, et les boîtes de dialogue de questions reçoivent une réponse automatique selon une heuristique de bonne pratique qui privilégie les choix recommandés, par défaut, courants, simples et minimaux, tout en évitant les options risquées ou sur-conçues.

Par défaut, le mode autonome est activé. Si vous l’avez déjà désactivé, cette préférence est enregistrée et rétablie au prochain lancement.

Démarrage rapide

Basculez depuis le TUI :

• Saisissez /autonomous dans l’invite, ou
• Appuyez sur Ctrl+P et recherchez « autonomous », ou
• Cliquez sur l’indicateur autonome activé/désactivé dans la barre d’état

La barre d’état affiche l’état courant :

• autonome activé (fond jaune, texte rouge en gras) — l’agent s’exécute sans pause
• autonome désactivé (texte vert) — l’agent s’interrompt pour les invites de permission ou de question

Le réglage persiste d’une session à l’autre dans ax-code.json.

Ce qui change

Fonctionnement

Le mode autonome agit sur trois couches :

Source de vérité

Cette page résume le comportement visible par l’utilisateur. Lorsque le comportement change, vérifiez la documentation par rapport à :

• packages/ax-code/src/session/processor.ts pour l’approbation automatique des permissions, le comportement de la boucle, la gestion des rejets et les plafonds autonomes.
• packages/ax-code/src/session/system.ts et les fichiers d’invite des fournisseurs sous packages/ax-code/src/session/prompt/ pour les instructions du flux de travail autonome.
• packages/ax-code/src/question/ et packages/ax-code/test/question/question.test.ts pour les heuristiques de réponse automatique aux questions et le comportement d’escalade.
• packages/ax-code/src/session/blast-radius.ts pour les plafonds de pas autonomes et de modifications de fichiers.
• packages/ax-code/test/session/system.test.ts, packages/ax-code/test/session/prompt.test.ts et les tests de session associés pour le comportement des invites et du registre de décisions.

Maintenez ici les garanties de sécurité alignées sur la documentation du bac à sable ; le mode autonome change le comportement d’approbation, pas l’application de l’isolation.

1. Approbation automatique des permissions (côté serveur)

Le mode autonome utilise une politique hybride qui refuse d’abord (ADR-004 / PRD v4.2.0). Lorsqu’un outil appelle ctx.ask() pour une permission, le module Permission classe la permission :

• Les permissions SAFE (read, glob, grep, list, lsp, code_intelligence, skill, todoread) sont approuvées automatiquement sans créer d’invite bloquante.
• Les permissions RISK (edit, bash, external_directory, task, webfetch, websearch, codesearch, …) passent au jeu de règles — les règles d’autorisation et de refus configurées pour l’agent s’appliquent toujours, et les règles de refus définies par l’utilisateur sont toujours appliquées. En mode bac à sable full-access, les permissions RISK sont approuvées automatiquement après l’évaluation des règles de refus.
• Les permissions inconnues demandent par défaut (experimental.autonomous_strict_permission: false conserve le comportement d’autorisation hérité).

Permissions qui atteignent toujours une décision par appel au lieu d’une approbation immédiate fondée sur les règles : isolation_escalation (demandes de contournement du bac à sable), les permissions INTERACTIVE_ONLY et l’ensemble NEVER_AUTONOMOUS_AUTOAPPROVE. Un resserrement (ADR-098) : en mode bac à sable full-access, les requêtes external_directory marquées comme interactives seulement — commandes bash dont les chemins ne peuvent pas être vérifiés statiquement parce qu’elles utilisent un glob, une variable ou une expansion d’accolades — sont aussi approuvées automatiquement, car un bac à sable en accès complet n’a plus de frontière de système de fichiers à protéger. Les règles de refus explicites s’appliquent toujours, et les modes avec bac à sable activé (workspace-write, read-only) conservent l’invite par appel.

« Autoriser une fois » au repos (activé par défaut) : Auto activé plus bac à sable désactivé (full-access) signifie une interaction minimale : chaque permission en attente peut recevoir une réponse automatique une fois après 15 secondes, y compris requireInteractive, les invites de hook et d’escalade du bac à sable. Auto désactivé ou bac à sable activé exige une réponse humaine aux invites en attente. WebMCP exige en plus que le pont correspondant soit connecté ; un autre pont connecté ne suffit pas. Les règles de refus explicites s’appliquent toujours. experimental.permission_idle_once.enabled: false désactive les comptes à rebours, et permissions peut en restreindre la portée. Le réglage hérité timeout_ms est accepté pour la compatibilité, mais ne modifie plus la durée fixe de 15 secondes.

Le serveur possède le compte à rebours. La requête la plus ancienne de chaque session reçoit une échéance ; les requêtes en file reçoivent 15 secondes nouvelles lorsqu’elles arrivent en tête. Les réponses humaines annulent le minuteur. Désactiver Auto, activer le bac à sable ou déconnecter le pont WebMCP concerné annule les comptes à rebours en attente. Rétablir l’éligibilité lance un nouveau compte à rebours. Les interruptions temporaires de rechargement de configuration suspendent le compte à rebours. Les réponses automatiques revérifient le mode courant, le pont et les règles de refus, et n’enregistrent jamais une approbation persistante. Le contournement interne de débogage et de test AX_CODE_PERMISSION_IDLE_ONCE_MS reste disponible et est plafonné au maximum du minuteur Node.

Les modes sont limités au répertoire actif. Un ax-code.json imbriqué peut remplacer les réglages de la racine du dépôt ; utilisez le basculement Bac à sable de la session active pour changer son mode effectif.

Chemins protégés non remplaçables : le mode autonome refuse aussi d’écrire un ensemble fixe de chemins du plan de contrôle et de politique — ax-code.json/ax-code.jsonc, .ax-code/**, .git/config et .git/refs/** — afin que l’agent ne puisse pas modifier sa propre configuration, relever ses propres plafonds d’autonomie ni installer des hooks Git. Contrairement à la liste configurable de chemins bloqués, ceux-ci ne peuvent pas être retirés par la configuration du projet ou de l’utilisateur.

2. Réponse automatique aux questions (côté serveur)

Lorsqu’un outil pose une question à l’utilisateur, le module Question choisit une réponse immédiatement. Il préfère les options marquées comme recommandées, par défaut, sûres, standard, courantes, conventionnelles, bonne pratique, simples ou minimales. Il évite les options marquées expérimentales, risquées, dangereuses, destructrices, avancées, complexes, réécriture ou sur-conçues. Si aucune option ne porte de signal, il choisit la première, car l’outil de question demande aux agents de placer l’option recommandée en premier.

3. Boucle du processeur (niveau session)

Si une permission est malgré tout rejetée (par exemple par une règle de refus explicite), la boucle du processeur ne s’arrête pas — elle passe à l’étape suivante au lieu d’interrompre la session.

4. Cadre de décision de style PRD/ADR

Le mode autonome ajoute un rappel de flux de travail léger à l’invite système. Avant la mise en œuvre, l’agent doit cadrer le travail avec le problème, les contraintes, la décision, les compromis, le plan et la validation. Pour des changements substantiels multi-fichiers, architecturaux ou visibles dans le produit, il peut créer ou mettre à jour un document du dépôt lorsque cela correspond au modèle de documentation du dépôt. Pour les changements triviaux, il doit garder ce cadre léger dans le plan afin d’éviter la sur-conception.

Autonome + bac à sable

Le mode autonome et le mode bac à sable sont indépendants. Vous pouvez utiliser les deux en même temps :

La posture d’exécution par défaut est autonome activé plus bac à sable désactivé : full-access avec le réseau activé. Cela offre le comportement CLI le moins frictionnel, mais aucune frontière d’isolation. Utilisez /sandbox, --sandbox workspace-write, AX_CODE_ISOLATION_MODE ou la configuration du projet pour activer des restrictions pour un travail non fiable ou sans surveillance.

Configuration

Fichier de configuration

Dans ax-code.json :

{
  "autonomous": true
}

Définissez la valeur false pour désactiver :

{
  "autonomous": false
}

Variable d'environnement

AX_CODE_AUTONOMOUS=true ax-code    # force autonomous on
AX_CODE_AUTONOMOUS=false ax-code   # force autonomous off

Préséance

Variable d’environnement > fichier de configuration > valeur par défaut (activé)

Budgets de charge (tours de modèle et appels d'outils)

Le mode autonome ne signifie pas une exécution illimitée. Plusieurs plafonds indépendants s’appliquent. Les valeurs par défaut ci-dessous sont les constantes livrées ; augmentez-les ou diminuez-les dans ax-code.json lorsqu’une charge a besoin de plus de marge.

Un tour de modèle est une requête de modèle de la boucle externe. Un appel d’outil est une invocation d’outil à l’intérieur d’un tour de modèle. Ce sont des budgets distincts : un seul tour de modèle peut émettre plusieurs appels d’outils. Les noms de configuration hérités contenant steps restent pris en charge, mais ils ne rendent pas les deux unités interchangeables.

Préférez l’objet de premier plan autonomy. Les clés héritées session.* et experimental.autonomous_caps.* fonctionnent encore comme alias (préséance plus basse).

Les fichiers binaires (cp d’un exécutable, curl -o d’une archive zip et les autres écritures non textuelles) comptent toujours pour le plafond de fichiers, mais ils imputent zéro ligne. Le plafond de lignes mesure le changement textuel. Les écritures textuelles du shell conservent l’estimation ceil(size / 80) afin qu’une charge dense ne puisse pas échapper au budget en ayant peu de sauts de ligne.

Les chemins non suivis que git check-ignore signale comme ignorés imputent aussi zéro ligne et comptent toujours comme un fichier. Cela couvre les arborescences générées telles que target/ lorsqu’un vérificateur y redirige sa sortie (cargo clippy > target/review/clippy.log). L’exemption ne s’applique que lorsque git se termine avec le code 0. Un dépôt manquant, un échec de git et un fichier suivi conservent l’imputation normale de lignes, y compris un fichier suivi dont le nom correspond à un motif d’ignorance.

Profils

Définissez autonomy.profile pour initialiser plusieurs champs à la fois (les champs explicites l’emportent toujours) :

Inspecter avec /limits

Dans une session, exécutez /limits pour afficher la pile de budgets résolue, le dénominateur TUI effectif de l’agent actif, les sources de configuration et les avertissements de doctor (par exemple lorsque agent.steps est plus serré que le segment de session). Utilisez /limits help pour les noms de clés.

Ce que le TUI affiche : pendant une exécution autonome, l’en-tête indique turn current/max · total current/max · cont current/max. turn est le segment de continuation courant et utilise le plafond de cadence effectif de l’agent actif — min(agent.steps, session.max_steps) lorsque l’agent est plafonné, sinon la limite par segment. total survit aux continuations automatiques. cont affiche ∞ lorsqu’un objectif actif ou le mode Super-Long lève le plafond de continuation ordinaire.

Routage automatique : le routage par mots-clés peut basculer la session vers un agent spécialiste (Debug, Security, DevOps, …). Les spécialistes partagent la même politique de tours de modèle non bornée par défaut que Dev, sauf si vous définissez agent.<name>.steps. Désactivez le routage avec "routing": { "disable": true } si vous ne voulez que l’agent Dev.

Exécutions longues : utilisez /goal ou Super-Long pour un travail de plusieurs heures — ils lèvent les plafonds de continuation ordinaires et utilisent le plafond cumulé plus élevé (20,000 par défaut), avec une sémantique de vérification et de pause documentée dans Mode boucle. /goal écrit d’abord un contrat révisable (critères d’acceptation + plan de vérification) et bascule en échec fermé vers l’état en pause si ce plan ne peut pas être produit.

Lorsqu'une limite arrête une exécution

Avant qu’une exécution ordinaire n’atteigne son plafond cumulé de tours de modèle, AX Code injecte une instruction de convergence bornée (au plus les 50 derniers tours, réduite pour les petits budgets personnalisés). Elle demande au modèle d’arrêter l’exploration large, de terminer ou de mettre en attente en toute sécurité le travail en cours, d’exécuter une vérification ciblée et de signaler honnêtement le travail inachevé. Elle n’ajoute pas de budget et ne contourne aucun plafond.

Lorsqu’un budget terminal est atteint, session.error inclut un code facultatif lisible par machine, et l’événement de rejeu session.end enregistre la même valeur comme stopCode. Les raisons de fin grossières existantes restent inchangées pour la compatibilité. Les codes de limite actuels sont :

• MODEL_TURN_SEGMENT_LIMIT
• MODEL_TURN_TOTAL_LIMIT
• AGENT_MODEL_TURN_LIMIT
• AGGREGATE_TOOL_CALL_LIMIT
• FILE_CHANGE_LIMIT
• LINE_CHANGE_LIMIT

À un plafond de segment, AX Code continue automatiquement tant que le budget de continuation configuré reste disponible. Une fois ce budget épuisé, l’exécution s’arrête et le message indique ce qui s’est passé. Envoyer une nouvelle invite telle que continue démarre une nouvelle exécution dirigée par l’utilisateur avec une nouvelle comptabilité d’exécution ; cela n’étend pas rétroactivement l’exécution arrêtée. Utilisez /goal lorsque l’objectif doit rester explicite et reprisable jusqu’à l’achèvement, un blocage ou une frontière de budget d’objectif ou d’exécution. /goal ne désactive pas les garde-fous de permission, d’isolation, de rayon d’impact, de blocage, de jetons, de temps ou de tours de modèle cumulés.

Exemple : relever les budgets pour un grand lot autonome

{
  "autonomous": true,
  "autonomy": {
    "profile": "long",
    "budget": {
      "model_turns": { "per_segment": 500, "total": 20000 },
      "tool_calls": {
        "per_segment": 1000,
        "rate": { "count": 40, "window_seconds": 10 },
        "per_tool": { "bash": 80, "edit": 150 }
      },
      "changes": { "files_total": 100, "lines_total": 10000 }
    },
    "stall": {
      "tool_only_turns": 50,
      "tool_only_nudge": 20,
      "failed_mutation_attempts": 30,
      "max_consecutive_errors": 3
    }
  },
  "agent": {
    "debug": { "steps": 200 }
  }
}

Quand désactiver le mode autonome

• Apprendre ax-code — voir ce que fait l’agent à chaque étape
• Opérations sensibles — examiner chaque modification de fichier avant qu’elle ne soit appliquée
• Déboguer le comportement de l’agent — comprendre pourquoi l’agent prend certaines décisions
• Code non fiable — examiner les appels d’outils lorsque vous travaillez avec des dépôts inconnus

Quand garder le mode autonome activé

• Tâches routinières — remaniement, corrections de bogues, migrations lorsque vous faites confiance à l’agent
• Pipelines CI/CD — exécution sans interface lorsque la tâche est déjà contrainte par une politique
• Usage du SDK — exécution programmatique de l’agent via createAgent()
• Grandes tâches — changements multi-fichiers où s’arrêter à chaque permission prendrait des heures

Usage sans interface / CI

En mode sans interface (ax-code run, ax-code serve, SDK), le mode autonome est essentiel — il n’y a pas de TUI pour afficher les invites. L’approbation automatique côté serveur garantit que l’agent s’exécute jusqu’au bout sans rester bloqué sur des invites sans réponse.

# Headless one-shot with autonomous on (default)
ax-code run "Fix all TypeScript errors in src/"

# Explicit override
AX_CODE_AUTONOMOUS=true ax-code run "Migrate API routes"

ax-code run affiche par défaut une sortie d’outil concise : la sortie de commande est réduite à sa fin, les modifications montrent un résumé de diff, et les écritures de tâches montrent un compteur de progression sur une ligne. Les erreurs ne sont jamais masquées — elles s’affichent avec le même plafond de fin que les autres sorties. Passez --full pour rétablir la sortie d’outil complète (diffs complets, sortie de commande non tronquée, listes de tâches complètes) pour l’audit.

Garanties de sécurité

Même avec le mode autonome activé :

1. Le bac à sable applique toujours les frontières — les écritures hors de l’espace de travail sont bloquées, quel que soit le mode autonome
2. L’escalade d’isolation demande toujours — l’agent ne peut pas contourner silencieusement les restrictions du bac à sable
3. Les règles de refus sont appliquées — les règles de permission explicites "deny" bloquent toujours les appels d’outils
4. Les choix autonomes sont enregistrés — les métadonnées de l’outil de question incluent un registre structuré autonomousDecisions, et la sortie d’outil inclut les réponses choisies afin que l’agent puisse les signaler plus tard
5. Éviter la sur-conception — la continuation autonome rappelle à l’agent de préférer le changement de pratique courante le plus simple et d’éviter les abstractions sans 3 cas d’usage concrets ou plus
6. Les instantanés de session sont enregistrés — chaque appel d’outil est journalisé pour l’audit et le rejeu
7. L’abandon fonctionne toujours — appuyer sur Esc (interruption) arrête l’agent immédiatement