Kiro CLI 3.0 : le nouveau moteur V3 par défaut, l'ancienne interface retirée

Kiro est l'environnement de développement assisté par IA d'AWS. Il existe en éditeur, en version web et en ligne de commande. C'est cette dernière, Kiro CLI, qui passe en version 3.0.0 le 3 novembre 2026, avec une liste de ruptures plus longue que la liste de nouveautés.

Trois générations, une seule reste par défaut

Kiro CLI a connu trois moteurs d'agent, que l'éditeur appelle Classic (V1), V2 et V3. Avec la version 3.0.0 :

• V3 devient le moteur par défaut des sessions interactives. Les utilisateurs actuels de V2 reçoivent une question avant la bascule.
• Classic ne se lance plus. Si une commande, un alias ou un réglage le sélectionne encore, Kiro propose de continuer avec V3.
• V2 reste accessible avec la commande kiro-cli --v2.

L'option --v3, elle, n'est plus nécessaire.

Ce qui est retiré

• L'application de bureau n'est plus livrée avec Kiro CLI. L'outil devient un seul exécutable autonome, kiro-cli. Les installations macOS existantes basculent lors de leur prochaine vérification de mise à jour.
• L'autocomplétion et les suggestions en ligne dans le terminal sont abandonnées, sans remplaçant.
• Cinq commandes ne sont plus disponibles : autocomplete, inline, translate, theme et dashboard.
• kiro-cli doctor renvoie maintenant vers kiro-cli diagnostic ou kiro-cli issue.

Ce que V3 apporte

D'après le journal des modifications, V3 propose des fonctions absentes de V2 :

• des sessions dans le cloud, que l'on peut quitter puis reprendre depuis /sessions ;
• une mémoire qui conserve le contexte du dépôt d'une session à l'autre, une fois activée ;
• « Approve for me » : Kiro valide lui-même les actions courantes, bloque celles qu'il juge risquées et pose la question dans le doute. Vos règles d'interdiction, de demande et d'autorisation sont toujours examinées en premier ;
• /sandbox, qui isole les commandes du terminal ;
• /autonomous on, qui exécute les tâches sans validation commande par commande, avec le bac à sable activé ;
• des « workflows » qui affichent leur plan avant de démarrer, à activer dans /settings, rubrique Features.

Le point délicat : les scripts

Le comportement par défaut dépend désormais du mode d'appel :

• en mode non interactif, les scripts qui utilisent --trust-all-tools démarrent sur V3 ; les autres restent sur V2 ;
• via le protocole ACP (celui qui relie un agent à un éditeur tiers), les nouveaux clients démarrent sur V3, les clients existants restent sur V2 sauf s'ils sont déjà pris en charge.

Autrement dit, deux scripts voisins dans la même chaîne d'intégration peuvent tourner sur deux moteurs différents. Pour figer le comportement, l'éditeur recommande d'ajouter --v2 là où V2 est requis.

Autre point à surveiller : les agents personnalisés encore au format V2 sont convertis automatiquement. La version 2.37.0 du 30 octobre précise que chaque fichier est réécrit après une sauvegarde en .json.bak, et que la commande kiro-cli settings chat.enableAutoAgentUpgrade false désactive cette conversion.

Les limites

La page ne dit pas combien de temps V2 restera disponible. Elle ne détaille pas non plus les critères selon lesquels « Approve for me » classe une action comme courante ou risquée : avant de l'activer sur un dépôt de production, il faut l'observer sur un projet sans enjeu.

Notre lecture

Pour une petite équipe qui utilise Kiro CLI à la main, la mise à jour se résume à répondre à une question. Le travail se trouve ailleurs : dans les scripts et les pipelines. Cherchez-y les cinq commandes retirées, l'option --trust-all-tools et toute référence à Classic, puis décidez explicitement du moteur voulu. Et si vos agents personnalisés sont versionnés dans Git, validez leur état avant la première session V3.