En bref
Préparez OpenCode V2 comme une migration, pas comme une mise à jour à l’aveugle
Vous pouvez essayer V2 si ses capacités actuelles de terminal ou de bureau correspondent à votre usage et si vous avez le temps de valider le changement. Gardez V1 disponible tant que vous n’avez pas vérifié modèles, identifiants, agents, permissions, serveurs MCP, extensions, clients d’éditeur et tâches réelles. Un usage personnel peut commencer dans un projet de test ; une équipe ou un dépôt avec des extensions personnalisées devrait procéder par étapes.
La documentation officielle indique que la configuration V1 prise en charge et les définitions enregistrées sous forme de fichiers sont destinées à continuer de fonctionner, et que la commande habituelle opencode est conservée. Trois points demandent néanmoins une vérification : les extensions V1 ne s’exécutent pas sur V2, le contrat de l’API serveur et des clients change, et les préférences du terminal passent à un fichier global cli.json. Une vérification reste nécessaire même si vous ne convertissez pas votre configuration principale.
Cette page regroupe les canaux officiels d’installation, les différences entre V1 et V2 et une liste de migration réversible. La documentation principale ne promet pas la conversion globale d’anciennes bases de sessions. Pour les choix de modèles, les clés API et les tarifs, consultez les pages sur les modèles, les fournisseurs et les offres.
OpenCode V1 vs V2 : les changements qui comptent au quotidien
Le numéro de version ne suffit pas à estimer le coût d’une migration. Examinez les éléments réellement utilisés : client en ligne de commande, extensions, API serveur et configuration. Un fichier de projet pris en charge n’est pas comparable à du code d’extension exécutable ou à un client API.
| Élément | V1 | V2 et impact |
|---|---|---|
| Commande CLI | opencode | Le nom reste le même. Les versions installées par gestionnaire de paquets ne cohabitent pas par défaut. |
| Configuration et fichiers pris en charge | Configuration V1 et fichiers dans .opencode/ | Les champs et définitions compatibles sont prévus pour continuer ; vérifiez fournisseurs et permissions. |
| Extensions | API et points d’entrée des extensions V1 | Nouvelle API ; chaque extension V1 doit être portée avant exécution. |
| API serveur et clients | Contrat V1 et clients générés | Nouveaux contrats ; migrez les clients et testez les intégrations. |
| Préférences du terminal | Fichiers tui.json ou tui.jsonc à plusieurs niveaux | Les réglages compatibles passent au cli.json global ; contrôlez le résultat. |
| Installation | Paquet ou installeur V1 | Choisissez un canal officiel V2 ; retirez éventuellement le paquet V1 d’abord. |
Ce tableau sert à délimiter les vérifications, pas à garantir la prise en charge de chaque ancien champ. La documentation de migration distingue les valeurs compatibles, acceptées mais non prises en charge et rejetées. Consultez-la avant de modifier la sécurité, l’accès aux fournisseurs ou l’automatisation, et examinez les avertissements au démarrage.
Faut-il passer à OpenCode V2 maintenant ?
Décidez en fonction de la compatibilité et de la possibilité de revenir en arrière, pas du seul numéro majeur. Un poste personnel utilisant des fonctions intégrées n’a pas le même coût de migration qu’un dépôt avec extensions maison et intégration d’éditeur.
Un essai de V2 est raisonnable si
- Votre flux repose surtout sur la configuration prise en charge, les fournisseurs, commandes intégrées, agents, compétences et MCP, et vous pouvez les tester dans un projet témoin.
- Vous souhaitez utiliser le terminal ou l’application de bureau V2 tout en conservant une copie fonctionnelle de votre installation actuelle.
- Vos extensions ou clients serveur ont déjà une version V2, ou une personne peut les porter et les valider.
Mieux vaut conserver V1 pour le moment si
- Une extension V1, une API serveur, un client IDE ou une automatisation critique n’a pas été testée avec le contrat V2.
- Vous ne pouvez pas restaurer votre paquet, votre configuration ou vos données de session en cas d’échec.
- L’outil est partagé par une équipe sans plan de mise à jour des environnements, de la documentation et du support.
En cas d’hésitation, utilisez un projet temporaire et notez la commande, le gestionnaire de paquets, la version OpenCode et le résultat attendu. Par exemple, un développeur qui utilise seulement les agents et un fournisseur peut tester une copie du dépôt pendant qu’un autre conserve V1 pour un plug-in serveur. La décision repose alors sur des vérifications concrètes, pas sur une affirmation générale à propos de la nouvelle version.
Installer OpenCode V2 depuis un canal officiel
L’introduction officielle de V2 présente plusieurs méthodes en terminal. Choisissez le gestionnaire déjà utilisé et suivez ses instructions à jour, y compris la prise en charge de votre système. Ne recopiez pas une ancienne commande de paquet V1 sans vérifier son rôle dans la migration.
| Canal | Commande de la documentation V2 | À vérifier |
|---|---|---|
| Installeur officiel | curl -fsSL https://opencode.ai/v2/install | bash | Confirmez que l’installeur et votre système correspondent aux consignes V2. |
| Homebrew | brew install anomalyco/tap/opencode-v2 | Vérifiez que le tap et le nom du paquet sont toujours actuels. |
| npm | npm install -g @opencode/cli | Le tag npm @latest indiquait 2.0.22 le 3 octobre 2026 ; vérifiez la version en direct. |
La documentation V2 présente aussi Bun, pnpm et d’autres méthodes. Le support dépend du système ; pour Windows, consultez les binaires indiqués plutôt que de supposer que chaque gestionnaire convient. Pour Yarn, Vite+ ou AUR, suivez les instructions V2 en vigueur et évitez les installateurs provenant de sites tiers.
Avant l’installation, identifiez l’origine de votre V1. Les instructions officielles précisent qu’un V1 installé par un gestionnaire de paquets doit parfois être désinstallé, car les deux versions utilisent la commande opencode. L’installeur curl V2 remplace le binaire V1. La suppression du paquet ne doit pas supprimer la configuration ou les données partagées : sauvegardez-les séparément et vérifiez ce que chaque gestionnaire enlève.
Migrer OpenCode V1 vers V2 sans perdre la maîtrise du changement
Rendez la première étape réversible. Il s’agit de confirmer que V2 démarre et que le projet fonctionne, pas de réécrire toute la configuration dès le premier jour. Utilisez les instructions officielles correspondant à votre système et à votre paquet.
- Documentez l’installation V1. Notez le gestionnaire, la version, les variables et les chemins de configuration. Gardez le paquet ou une méthode fiable pour le réinstaller.
- Faites une sauvegarde datée. Copiez les réglages, définitions de projet et données à conserver. Vérifiez que la copie est accessible et ne se trouve pas uniquement dans un dossier temporaire.
- Inventoriez le code dépendant. Listez extensions, clients API, commandes CI et intégrations d’éditeur. Pour chaque élément, indiquez s’il est testé avec V2, à porter ou inutilisé.
- Installez avec le canal approprié. Retirez le paquet V1 uniquement si les consignes le demandent. Une mise à jour normale de V1 n’est pas une installation de V2.
- Contrôlez la configuration. Lancez V2 sur un projet de test et examinez les avertissements, modèles, identifiants, permissions et connexions MCP avant toute tâche importante.
- Adaptez les extensions et clients. Portez les extensions vers la nouvelle API, actualisez les clients serveur et testez les cas d’erreur et de permission.
- Convertissez les préférences ensuite. Les préférences de terminal compatibles sont déplacées vers un
cli.jsonglobal. La conversion en configuration native V2 est optionnelle et peut attendre la validation initiale.
Lors des premiers essais, gardez les fichiers V1 compatibles dans leur forme d’origine. D’après la documentation, V2 peut normaliser les réglages pris en charge en mémoire sans réécrire le fichier source. Séparer l’installation, le portage des extensions et la conversion de configuration aide à trouver la cause d’un problème et à revenir à la version précédente.
Ce qui est conservé et ce qui doit être vérifié manuellement
Ne considérez comme compatible que le comportement explicitement pris en charge par la documentation V2 actuelle. Cette distinction répond aux questions de compatibilité sans sous-entendre que tous les anciens champs ou toutes les extensions fonctionnent encore.
| Élément | Attente prudente | Vérification pratique |
|---|---|---|
| Configuration et fichiers de projet compatibles | Ils sont destinés à continuer, mais certains champs peuvent être ignorés ou non pris en charge. | Lisez les avertissements et testez fournisseur, permissions et tâches réelles. |
| Agents, commandes et compétences sous forme de fichiers | La documentation les prend en charge si leur comportement est compatible. | Appelez chaque élément dans un projet témoin et comparez le résultat attendu. |
| Extensions | Les extensions V1 ne s’exécutent pas comme des extensions V2. | Portez le point d’entrée et testez le chargement, les permissions et les erreurs. |
| API et clients serveur | Le contrat change ; la compatibilité des clients V1 n’est pas acquise. | Migrez le client et validez appels, événements et authentification. |
| Anciennes sessions | La documentation principale ne promet pas la conversion des bases historiques. | Sauvegardez et vérifiez les sessions essentielles avant de changer votre usage quotidien. |
La documentation classe certains anciens réglages comme acceptés mais non pris en charge, avec des avertissements possibles. Pour les options liées aux permissions de fichiers, aux limites des outils ou aux fournisseurs, ne vous contentez pas d’un lancement réussi : vérifiez les logs et reproduisez un cas qui démontre le contrôle attendu.
Validez OpenCode V2 avant de supprimer votre solution de secours V1
Effectuez une courte recette dans un projet témoin et conservez le résultat dans vos notes de mise à niveau. Une équipe peut reprendre la liste sur chaque poste ; un usage individuel peut s’en servir pour décider objectivement de continuer ou de revenir à V1.
- La commande utilisée correspond à l’installation attendue et affiche une version V2.
- Le fournisseur, les identifiants et le modèle fonctionnent sans afficher de secret dans les logs.
- Les agents, commandes et compétences utiles produisent le résultat attendu.
- Les permissions de lecture et d’écriture respectent les règles du dépôt.
- Les serveurs MCP se connectent et une erreur ne déclenche pas d’action imprévue.
- Les extensions et clients indispensables ont une version compatible V2.
- Les sessions nécessaires sont accessibles ou disposent d’une sauvegarde vérifiée.
- Une tâche réelle se termine correctement et sa sortie peut être relue.
Si un contrôle critique échoue, suspendez V2 pour ce flux et revenez au paquet ou à l’installation V1 conservée. Ne faites pas lire à V1 une configuration réservée à V2. La méthode de retour dépend du gestionnaire ; gardez le paquet disponible et séparez les données utilisateur du logiciel. Ne supprimez la sauvegarde qu’après avoir terminé un cycle de travail normal.
Pour les mises à jour courantes après installation de V2, la CLI documente opencode upgrade et son alias update. Cette commande concerne une V2 déjà installée ; elle ne remplace pas les étapes distinctes pour passer de la version majeure V1 à V2.
Questions fréquentes sur OpenCode V2 et la migration depuis V1
OpenCode V2 est-il une mise à jour classique de V1 ?
Non. C’est une migration majeure. Les deux versions utilisent opencode et les installations par gestionnaire de paquets ne fonctionnent pas en parallèle par défaut. Identifiez votre méthode d’installation V1 et suivez les instructions officielles.
Dois-je réécrire ma configuration OpenCode pour V2 ?
Pas nécessairement. La documentation précise que V2 lit et normalise la configuration V1 prise en charge sans réécrire le fichier source. Examinez les avertissements et testez fournisseurs, permissions et MCP.
Les extensions OpenCode V1 fonctionnent-elles avec V2 ?
Pas telles quelles. Les extensions V1 ne s’exécutent pas comme des extensions V2. Portez leur point d’entrée et leur comportement selon les instructions officielles, puis testez le paquet installé.
Comment installer OpenCode V2 avec npm ?
La documentation V2 actuelle indique npm install -g @opencode/cli. Vérifiez la page officielle et la fiche du paquet pour confirmer la version et les conditions de votre système.
Quelle commande met à jour OpenCode V2 ?
Sur une installation déjà en V2, la CLI documente opencode upgrade et l’alias update. Le passage de V1 exige un traitement séparé du paquet et du canal d’installation.
La migration vers V2 transfère-t-elle tout l’historique des sessions ?
La documentation principale ne garantit pas la conversion complète des anciennes bases de données. Sauvegardez les données importantes et vérifiez vos sessions nécessaires avant de changer votre flux quotidien.
Sources officielles OpenCode
Les commandes et les informations de compatibilité ont été vérifiées dans les sources officielles le 3 octobre 2026. Les paquets et instructions évoluent ; confirmez-les avant une migration majeure.