Les problèmes agaçants et inquiétants d’OpenCode

• Après avoir testé OpenCode, l’agent de codage IA open source crédité de 161 k étoiles sur GitHub, avec un Qwen3.6-27B local, il s’est avéré que la qualité des outils comme la conception de la sécurité étaient à un niveau qui justifie d’arrêter de l’utiliser
• Le rechargement de AGENTS.md, l’élagage de contexte à distance fixe, l’insertion de la date du jour et le changement de mode invalident à répétition le cache de prompt, au point qu’il peut falloir jusqu’à 10 minutes avant de commencer à générer une réponse, même sur un M4 Max
• La compression de session, le prompt système, la vérification des permissions, le contrôle des sous-agents et le TUI s’articulent mal, ce qui entraîne une perte de contexte et de messages, et peut conduire à écrire du code en oubliant des spécifications importantes
• Le filtre de permissions fondé sur l’AST Bash et des motifs de chaînes ne bloque pas l’exécution indirecte, les chemins absolus, les variables, Python, les redirections, etc., et les restrictions d’accès aux fichiers externes comme les permissions persistantes se contournent facilement
• Compte tenu de la connexion par défaut à des modèles distants, de l’accès Internet sans limite et d’une ancienne faille RCE sur le serveur HTTP, Docker seul ne suffit pas ; il faut bloquer les exécutables, utiliser des chemins en lecture seule et une isolation au niveau du système d’exploitation

---

Périmètre de l’évaluation et hypothèses

• OpenCode est un projet présenté par son éditeur comme un agent de codage IA, et au moment de l’examen il comptait 161 k étoiles sur GitHub
• Les tests ont été réalisés avec le LLM local Qwen3.6-27B et la version Git d’OpenCode baef5cd4
• Il ne s’agit pas tant d’une divulgation de sécurité que d’un examen de la manière dont la couche pipeline échoue dans une architecture qui transmet la sortie d’un LLM à Bash
• L’usage d’un LLM en soi et la question de savoir si la machine de l’utilisateur peut être facilement compromise ou effacée sont traités comme deux problèmes distincts

Une architecture qui casse sans cesse le cache de prompt

• Les API de la famille OpenAI /v1/chat/completions envoient toute la conversation jusque-là en JSON et répondent via un flux delta SSE enrichi de métadonnées JSON
  • Plus la session est longue, plus le coût d’upload augmente au carré
  • Les appels d’outils utilisent un double encodage, en réassemblant plusieurs deltas JSON en JSON
• Le serveur est sans état, mais met en cache les résultats d’évaluation pour des raisons de performance
  • Il cherche le plus long préfixe de cache correspondant à la requête
  • Il effectue un préremplissage (prefill) depuis la fin de ce préfixe jusqu’au dernier message
  • Il génère ensuite de nouveaux tokens jusqu’au token de fin
• Sur un M4 Max d’environ 0,5 To/s de bande passante mémoire, la génération de tokens par Qwen3.6-27B était utilisable, mais le préremplissage sur un long contexte coûtait énormément en calcul
  • Sans préfixe de cache adapté, on peut attendre environ 10 minutes à GPU saturé avant même que la génération de réponse ne commence
• OpenCode fait un glob sur le système de fichiers à chaque tour SSE et relit AGENTS.md, injecté dans le premier prompt système
  • Même si l’on modifie AGENTS.md pour la session suivante, toute la session en cours est réévaluée
• Lors du passage de l’agent à l’utilisateur, le contexte des appels d’outils est élagué, ce qui invalide de larges segments de cache
  • Comme les résultats d’outils plus anciens que PRUNE_PROTECT = 40_000 sont supprimés, il y a au mieux un cache miss de 40 000 tokens
  • Les interruptions sont elles aussi traitées comme un retour à l’utilisateur ; corriger une mauvaise direction jette donc le cache et impose d’attendre à nouveau
• Le prompt système initial inclut la date du jour et il est réévalué à chaque tour SSE ; passer minuit provoque donc un cache miss complet

Élagage et compression de session

• L’élagage s’applique de la même façon à tous les résultats d’outils sauf skill, sans protection particulière pour les documents importants lus au départ
  • Dans une nouvelle session, on lit d’abord la spécification
  • Puis on lit du code lié en plus, jusqu’à dépasser le seuil des 40 000 tokens
  • Le modèle dérive vers des raisonnements inutiles ou une mauvaise direction, et l’utilisateur l’interrompt
  • L’interruption supprime la spécification du contexte
  • Le modèle implémente alors sans pouvoir se référer à la spécification d’origine
• La compression de session (compaction) ajoute un nouveau prompt au début de la session existante, refait le préremplissage complet, puis résume le tout en quelques puces
  • Mettre le prompt de résumé en fin de session permettrait d’éviter ce préremplissage complet
  • Il a mieux fonctionné de faire rédiger directement au modèle une note de passation dans un fichier, que l’on peut ensuite éditer ou réutiliser dans plusieurs sessions
• La compression est une abstraction fuyante qui donne l’illusion d’une fenêtre de contexte infinie ; combinée à l’élagage, elle aggrave les problèmes
• Mieux vaut reconnaître la fenêtre de contexte et le cache de prompt comme des contraintes de base, et fournir des moyens de les gérer ; l’arbre de sessions de Pi exploite volontairement le cache de prompt

Prompt système et mode Plan

• Le prompt système par défaut est très long, et une partie importante sert à dire au modèle de répondre de manière concise
• Il contient aussi des préférences de codage fortes, comme faire dire aux sous-agents ABSOLUTELY NO COMMENTS
• Le passage de Plan à Build n’est pas fluide ; si l’on détaille suffisamment le plan, on peut se rapprocher de la fin de la fenêtre de contexte
  • La préférence va à une méthode consistant à écrire puis éditer le résultat de la discussion dans un fichier avant de le transmettre à une nouvelle session
• L’alerte du mode Plan dit qu’il est impossible d’écrire dans quelque répertoire que ce soit, mais en réalité l’écriture dans .opencode/plans est possible
  • Les deux échecs ont été observés : écrire dans ce répertoire sans instruction, ou refuser d’y écrire malgré une demande explicite
• On ne peut pas modifier globalement le prompt système par défaut, ce qui oblige à le copier projet par projet
• Ne redéfinir que le prompt du mode Build provoque un cache miss complet de tout le prompt lors du passage en mode Plan
• Les prompts selon le modèle varient beaucoup en contenu et en qualité
  • Le Beast Mode pour GPT-4, o1 et o3 dit qu’une vérification via Google est indispensable pour comprendre des packages tiers et leurs dépendances

La fatigue décisionnelle causée par les vérifications de permissions

• Quand un accès à un fichier hors projet est détecté par une analyse ad hoc de chaînes, une fenêtre de permission Yes, No, Always s’affiche et l’exécution est suspendue jusqu’à la réponse
  • Il n’existe pas d’option Never pour refuser durablement ce type d’action à l’avenir
• Quand un sous-agent veut lire la sortie d’un script dans /tmp, choisir No fait se terminer l’agent et perdre aussi le contexte de travail
  • Pour conserver l’avancement, on se retrouve donc parfois à devoir choisir Yes pour un accès externe non souhaité
• Si les demandes d’autorisation se répètent et que le seul choix compatible avec la productivité est Yes, l’utilisateur peut finir par approuver des requêtes dangereuses
• Une protection de base contre l’écriture hors du répertoire ne doit pas dépendre de la vigilance continue d’un humain

Messages et interaction avec les sous-agents

• Les messages envoyés pendant le streaming SSE entrent en file d’attente, mais le moment de leur envoi effectif est flou
  • Le code semble les envoyer à la fin d’un tour d’appel d’outil, mais il a aussi été observé des cas où l’on passe d’un outil à la réflexion sans envoyer les messages en attente
  • Si l’utilisateur interrompt, le message sort de l’état en attente, reste seulement dans le journal et devient impossible à envoyer ; il faut alors un second message pour lancer un nouveau flux
• Il arrive aussi que l’annulation d’un message ne parvienne pas à le supprimer du journal
• On ne peut ni parler directement avec un sous-agent, ni arrêter sa progression
  • S’il part dans une mauvaise direction, il faut soit l’arrêter et perdre le contexte, soit le regarder consommer des tokens
  • Cette fonctionnalité semble avoir existé auparavant, mais a disparu
  • Même en @mentionnant un sous-agent dans le chat principal, cela ne fonctionne pas utilement, et on ne peut pas non plus l’interrompre
• Si un appel d’outil d’un sous-agent échoue, comme lorsque Qwen place un appel d’outil dans sa chaîne de pensée, une erreur fatale survient et tout le contexte jusque-là est perdu
• La réutilisation de sous-agents va à l’encontre du but recherché, qui est de découper le travail en petits contextes
  • Un sous-agent existant peut être réutilisé pour une tâche sans rapport
  • Faire des allers-retours entre l’agent principal au grand contexte et des sous-agents provoque des cache miss
  • L’interaction côté humain peut être riche, mais il faut réduire les options présentées au modèle
• Il existe aussi une issue GitHub liée au comportement des sous-agents

Conception des outils de l’agent

• edit effectue par défaut un rechercher-remplacer exact sur un texte correspondant de manière unique
  • C’est approprié, car le modèle peut se souvenir précisément du contenu d’un fichier tout en perdant les numéros de ligne après plusieurs éditions
  • L’option de remplacement global a entraîné plusieurs corrections successives ; la retirer revient au design de edit dans Pi
• L’outil question à choix multiples du mode Plan est moins pratique que de laisser le prompt système poser la question en langage naturel
• grep et glob peuvent être remplacés par bash, et le modèle exécute d’ailleurs grep ou rg via Bash
  • L’objectif est peut-être d’empêcher un agent en lecture seule comme Explore d’utiliser Bash
  • Cela rejoint le problème consistant à déterminer difficilement les effets de bord sans exécuter la commande Bash
• todo est globalement utile, mais le modèle oublie lui-même de vérifier les TODO

TUI et qualité de la documentation

• Le TUI d’OpenCode utilise environ 1 Go de RAM pour le rendu du texte
• Le retour à la ligne avec Shift+Enter ne fonctionnait pas dans le champ de saisie, et une issue existante a été close après une réponse du type « chez moi ça marche »
• Lorsqu’un long message revient automatiquement à la ligne, le champ de saisie et le curseur se déplacent, mais les caractères de la nouvelle ligne peuvent ne pas être visibles
• Si l’on sélectionne du texte pendant le streaming, l’auto-scroll annule la sélection
• Ctrl-C ferme immédiatement la session au lieu d’interrompre la commande en cours
  • Selon les conventions d’un shell interactif, Ctrl-C devrait interrompre la commande, et Ctrl-D ne devrait fermer la session qu’en l’absence de commande en cours
• Les raccourcis habituels de déplacement par mot, comme Option+flèche gauche/droite sur Mac, ne sont pas pris en charge
• Quand les messages ou la chaîne de pensée deviennent longs, le rerendu Markdown et autres opérations peuvent prendre plusieurs secondes, avec un problème de performance qui semble en complexité quadratique
• À cause des problèmes de saisie, il a fallu écrire les messages dans un éditeur externe puis les coller
• La documentation est incohérente et ressemble davantage à quelque chose écrit pour être lu par un modèle que par un humain

Connexion prioritaire aux modèles distants et exposition des données

• OpenCode se connecte par défaut à des modèles distants
• La documentation ne fournit pas d’exemple simple de configuration pour un modèle local, et une erreur de configuration entraîne une connexion à un modèle distant
• Même lorsqu’un modèle local est correctement défini, il faut encore le sélectionner interactivement après le lancement du programme ; entre-temps, le modèle distant et le shell local sont déjà connectés
• L’URL du modèle par défaut n’est pas figée dans la distribution ; elle est téléchargée depuis models.dev, lié à OpenCode
  • Le code correspondant se trouve à la ligne 1684 de opencode/src/provider/provider.ts
• Après une installation fraîche, il suffit d’exécuter opencode, puis de taper un caractère et Entrée pour qu’un modèle distant puisse être relié au shell local, sans aucun réglage utilisateur
• Si le premier message est vide ou ambigu, le modèle agent fait souvent un glob sur le répertoire courant et lit des fichiers ; les données lues sont ensuite incluses dans la requête POST suivante

Accès Internet et prompt système

• OpenCode fournit l’outil WebFetch, et le prompt système demande explicitement de l’utiliser
• Le prompt par défaut autorise de façon ambiguë la génération ou la supposition d’URL dès lors qu’il est convaincu qu’il s’agit d’une URL utile à l’assistance en programmation, tout en permettant d’utiliser les URL présentes dans les messages utilisateur ou les fichiers locaux
• Bash n’ayant pas de sandbox réseau, le problème dépasse WebFetch : toute l’architecture repose sur l’espoir que le modèle n’exécutera pas de commandes du type curl | bash

Comment contourner le filtre de permissions Bash

• Dans opencode.json, "bash": {"git *": "deny"} bloque git status comme echo hello && git push --force
• L’implémentation parse les commandes avec les grammaires Bash et PowerShell de tree-sitter, construit un AST, puis parcourt les nœuds de commande pour les comparer à des expressions régulières issues de la configuration
• Mais cette vérification textuelle autorise de nombreuses formes d’exécution indirecte
  • echo 'git clean -fdx .' | bash
  • env git status
  • utiliser un alias pour lier git à un autre nom de commande
  • /usr/bin/git status, $(which git) status
  • GIT=git && $GIT status
  • décoder en Base64 un git reset --hard puis l’envoyer à Bash
  • git push --force dans un heredoc
  • exécuter git checkout . via python subprocess.run
• Même si le modèle n’est généralement pas malveillant, il est entraîné à contourner obstinément les échecs ; il peut donc naturellement se comporter comme une entrée hostile
• Un filtre de commandes par chaîne n’est pas une protection, seulement un faux sentiment de sécurité

Permissions persistantes et exceptions CWD

• Si l’on choisit Always pour python3 -c 'print("hello")', tout le préfixe python3 est durablement autorisé
  • Ensuite, une commande Python lisant une clé privée SSH peut être considérée comme déjà approuvée
  • Les permissions sont enregistrées sur disque et persistent dans les sessions suivantes
• cd, chdir, popd, pushd, push-location, set-location figurent dans une liste d’exceptions CWD supposées sans effets de bord
• Ces commandes contournent explicitement la vérification des permissions, même si tous les ordres Bash sont configurés comme refusés

Failles dans les contrôles d’accès aux fichiers

• La configuration par défaut tente de bloquer les accès aux fichiers en dehors du plus court chemin entre le répertoire de lancement d’OpenCode et le dépôt Git
• Dans l’outil Bash, l’AST tree-sitter est parcouru pour interpréter et vérifier les valeurs qui ressemblent à des chemins
  • cat /tmp/logfile demande une permission
  • python3 -c 'import shutil; shutil.rmtree("/")' échappe au contrôle
• cargo peut librement lire, écrire et exécuter dans le ~/.cargo global, mais si le modèle veut lire directement les sources de packages dans ~/.cargo/registry/src, une permission est demandée
• Les commandes considérées comme susceptibles d’accéder à des fichiers sont limitées à une liste fixe FILES
  • On y trouve rm, cp, mv, mkdir, touch, chmod, chown, cat et certaines commandes PowerShell
  • Les commandes absentes de cette liste sont supposées ne pas accéder à des fichiers ; les chemins qu’on leur passe ne sont donc pas vérifiés

Combiner redirections et commandes autorisées

• Si l’on choisit Always pour echo "hello world!", les écritures vers des fichiers ou périphériques via echo sont ensuite autorisées
  • Cela inclut des commandes redirigeant vers des chemins GPIO comme /sys/class/gpio
• Dans l’AST de echo foo > bar.txt, redirection n’est pas un enfant de command mais un nœud frère
  • Or le contrôle des chemins ne vise que les enfants de command, donc la destination de redirection n’est pas vérifiée
  • echo lui-même n’est pas non plus dans la liste FILES, donc la validation du chemin n’est jamais lancée

Auto-upgrade et exemples d’exécution de code distant

• OpenCode propose plusieurs chemins d’auto-upgrade et, avec la distribution installée via curl, exécuter opencode upgrade télécharge la réponse de https://opencode.ai/install puis l’exécute sur l’entrée standard de Bash
• Le risque n’est pas très différent de celui accepté au moment d’utiliser l’installateur curl, mais cela reste un exemple d’exécution directe de script distant en production
• Lors de CVE-2026-22812, OpenCode exposait sur son serveur HTTP par défaut les fonctions suivantes
  • des en-têtes CORS totalement permissifs
  • une API POST exécutant des commandes shell arbitraires
  • une API GET lisant des fichiers arbitraires
• Un site web visité par l’utilisateur pouvait envoyer des requêtes vers le port par défaut connu et obtenir un accès système au niveau des permissions de l’utilisateur
• L’équipe de développement a répondu en désactivant le serveur par défaut et en expliquant qu’une exception CORS était nécessaire pour permettre à opencode.ai d’exécuter du code distant sur la machine, sans poursuivre le traitement du sujet ; l’issue a ensuite été fermée par le stale bot
• Une autre issue signalait qu’une commande d’authentification récupérait et exécutait du contenu depuis une URL arbitraire fournie par l’utilisateur ; elle aussi a été close par le stale bot

Pourquoi Docker ne peut pas suffire

• Il n’est pas souhaitable de rendre l’installation des dépendances de développement sur une nouvelle machine assez complexe pour devoir s’en remettre à Docker
• Docker lui-même peut aussi créer des problèmes de sécurité
  • il crée un service puissant exécuté en root
  • il ouvre volontairement un passage dans le pare-feu ufw
• Si toutes les données à protéger sont dans le conteneur et que le shell local interne reste connecté à Internet, le périmètre de protection devient flou
• Si l’objectif est d’empêcher la suppression récursive du système de fichiers racine, des mécanismes plus directs du système d’exploitation comme Landlock, Seatbelt, Restricted Tokens peuvent être utilisés
• La sécurité des agents de codage ne doit pas être déléguée à un conteneur séparé ; elle doit être la priorité absolue du harnais d’exécution
  • Pour bloquer Git, il faut interdire l’exécutable git lui-même, pas filtrer une chaîne de commande
  • Le répertoire .git doit être en lecture seule
  • Au lieu d’assainir textuellement des commandes Bash, il faut utiliser une isolation native au système d’exploitation

Expérience d’usage avec un LLM local

• Des modèles locaux comme Qwen3.6-27B peuvent eux aussi nuire à la stabilité et à la cohérence conceptuelle d’une base de code, comme les frontier models, mais avec trois différences
  • ils relèvent moins de cette vallée dérangeante où quelque chose semble intelligent tout en agissant stupidement, et leurs limites étant plus nettes, il est plus facile d’ajuster l’interaction
  • leur nombre de poids est trop faible pour reproduire tel quel les données d’entraînement, ce qui change l’évaluation du risque de contamination des sorties
  • ils n’imposent ni soutien ni dépendance vis-à-vis d’un fournisseur cloud
• De bons résultats ont été obtenus sur des tâches de recherche pilotées par l’entrée, où l’on fournit code, symptômes et cause supposée, puis où l’on demande après lecture du code les chemins d’appel et des citations du code
  • Le fait de cadrer le problème comme une recherche réduit la tendance du modèle à inventer des faits
• La génération de code ruine de façon répétée la planification architecturale
  • Elle choisit des raccourcis comme déplacer un état mutable au milieu de la conception alors que plusieurs composants étaient censés le partager
  • Le problème dépasse le fait de ne pas avoir écrit le code soi-même : il nuit à la capacité même de le comprendre
• Extraire directement des réponses depuis le savoir contenu dans les poids d’un modèle provoque des hallucinations, même avec des modèles de milliers de milliards de paramètres
• Pour que les LLM deviennent des outils ordinaires, il faut appliquer une véritable ingénierie système au logiciel qui les entoure afin de supprimer les vides de sécurité, et ce travail doit être fait par des humains

[GN⁺]

Avis sur Hacker News

• Un meilleur titre pour cet article serait sans doute quelque chose comme « petits désagréments qui, corrigés, amélioreraient OpenCode »
  Relire AGENTS.md à chaque fois ou subir des ratés de cache de prompt à cause d’un changement de date, c’est supportable
  Le fait que la compression et l’élagage ne fonctionnent pas correctement, je l’ai aussi vu dans Codex et Claude, et le prompt système par défaut sert aussi à assurer la cohérence, donc si ça ne plaît pas il suffit de le changer

  • Le codebase a maintenant énormément gonflé à cause de fonctionnalités ajoutées en mode vibe coding, et présente exactement les mêmes problèmes que Claude Code
    La stabilité, les performances et l’utilisation mémoire se sont toutes dégradées, et même si j’aimais OpenCode avant, je ne peux pas dire que c’est un logiciel bien conçu
    Je l’ai désormais totalement remplacé par Pi, et il existe aussi pas mal de nouvelles alternatives qui ont tiré des leçons d’OpenCode avec une conception plus sobre là où il faut
  • Je travaille sur OpenCode
    On ne fait plus d’élagage des appels d’outils maintenant, mais avec une fenêtre de contexte limitée, il faut résumer l’état d’avancement pour poursuivre longtemps une même tâche, donc la compression reste pour l’instant un mal nécessaire
    La V2, actuellement en bêta, introduit une nouvelle approche qui garde à jour les instructions système changeantes comme AGENTS.md, les technologies disponibles, etc., tout en évitant autant que possible les ratés de cache
    https://x.com/kitlangton/status/2075749116760457346/video/1
  • Ces points sont classés dans la catégorie « Annoying Things », donc il faut aussi lire les « Alarming Things »
  • Ce dont on vient de parler correspond aux points de la section « Annoying Things » de l’article
    Il y a une section distincte « Alarming Things », avec notamment une sous-section intitulée « It’s Fucking Full of RCEs », et plusieurs vulnérabilités d’exécution de code à distance en plus de celles découlant des problèmes exposés dans la section précédente
  • Donc c’est pour ça qu’OpenCode supprimait aléatoirement les commentaires dans mon code

• C’est un bon récapitulatif des risques des CLI agentiques, mais un titre centré uniquement sur OpenCode est étrange pour deux raisons
  D’abord, il ne propose pas d’alternative claire. Beaucoup de problèmes sont fondamentaux, au point qu’il faudrait peut-être presque tout repenser et réécrire depuis zéro, donc de simples correctifs pour OpenCode ne suffiraient sans doute pas, mais il n’y a aucune proposition constructive, au point que le texte ressemble en pratique à un appel à « cesser d’utiliser les LLM »
  Ensuite, les principaux problèmes des « Alarming Things » ne sont pas propres à OpenCode : ils s’appliquent aussi au CLI de Claude et probablement aux agents d’autres fournisseurs de modèles de pointe
  Cela reste néanmoins très précieux comme document appelant à créer de meilleurs outils dès le départ, donc je vais le garder en favori et le partager largement, mais le titre et l’angle me semblent encore plus mal choisis que le corps du texte n’est excellent

  • Je me demande comment on peut penser qu’il est possible d’autoriser l’accès au shell tout en bloquant en toute sécurité l’exécution de commandes arbitraires
    En particulier, se plaindre que echo git | bash s’exécute encore me paraît absurde

• La phrase « Si vous ne connaissez pas OpenCode, imaginez une botte piétinant éternellement un visage humain. La botte est en TypeScript, et le visage est tout ce que nous avons appris sur la sécurité et les logiciels système depuis l’invention des ordinateurs électroniques dans les années 1940 » est une candidate au prix Bulwer-Lytton dans la catégorie métaphore forcée

  • Cette métaphore vient de la phrase de 1984 de George Orwell : « Si vous voulez une image du futur, imaginez une botte piétinant éternellement un visage humain »

• Le style de l’article est excessivement colérique et mordant
  Je suis globalement d’accord avec plusieurs points, mais à partir du moment où OpenCode est décrit comme « une turbo-merde de voiture de clown dont la posture de sécurité est au niveau de “papa, je vais me pencher” » et où l’on demande à tout le monde d’arrêter de l’utiliser, je n’ai plus envie de lire
  Ce logiciel a aussi été créé par des gens ordinaires, et je ne sais pas depuis quand il est devenu normal de s’en prendre à l’open source de cette manière ; ça me fait penser à ce que je ressentirais si un logiciel que j’avais créé recevait ce genre de jugement

  • Je partage ce ressenti, mais cette culture existe au moins depuis les années 1990
    Déjà à l’époque sur comp.lang.lisp, certains prenaient plaisir à rabaisser ceux qui écrivaient du code ne répondant pas aux standards de la tour d’ivoire ; certains sont partis, d’autres ont pris cela comme une médaille en croyant à tort que cette rudesse était nécessaire pour progresser
    Ancienne discussion HN connexe : https://news.ycombinator.com/item?id=587045
  • Aujourd’hui, dire de quelque chose que c’est « codé en vibe coding » sert souvent de permis pour déverser exagérations et insultes en partant du principe que personne n’est visé personnellement
    Les gens qui emploient cette rhétorique semblent ne pas comprendre à quel point elle nuit aux développeurs pris dans les éclats et à eux-mêmes en normalisant ce comportement
  • Le passage « Quiconque connaît bien la structure interne d’OpenCode — en supposant que l’équipe de développement d’OpenCode n’en fasse pas partie — aurait pu contester l’exemple python3 ci-dessus » m’a fait rire
  • Même si vous avez contribué à OpenCode, si vous avez le sens de l’humour, vous en aurez ri, donc pas besoin de tout prendre trop au sérieux
  • Ce n’est toujours pas une façon normale de s’exprimer, mais ce n’est pas nouveau non plus ; ce type de langage existe depuis longtemps

• J’utilise Claude Code à cause de la stack technique de mes clients, et j’utilisais OpenCode dans une version donnée pour mes projets personnels ; OpenCode était bien meilleur, donc cet article me rend triste
  Tous les phénomènes étranges que j’avais vus jusqu’ici sans y prêter attention correspondent parfaitement à ce qui est décrit, et l’article en explique même la cause. En laissant de côté l’exagération et les passages avec lesquels je ne suis pas d’accord sur le plan émotionnel, l’essentiel est juste, donc je vais devoir chercher un autre outil d’exécution
  J’aimerais avoir des recommandations pour savoir si l’architecture de Pi est réellement meilleure, ou s’il existe de meilleures alternatives

• Indépendamment de ses défauts, après avoir utilisé plusieurs outils, c’est avec OpenCode que j’ai été le plus productif
  La plupart des points de l’article relèvent de petits désagréments ou de différences d’opinion, et en particulier il comprend fondamentalement mal l’objectif du filtrage des commandes. Ce n’est pas un dispositif de sécurité, c’est un mécanisme destiné à orienter le comportement du modèle
  Je n’ai pas l’impression que l’auteur a vraiment construit quoi que ce soit avec OpenCode ; s’il l’a utilisé, il ne parle absolument pas de la chose la plus importante : la qualité du résultat final

  • Moi aussi, j’ai trouvé qu’OpenCode avait le bon équilibre : il ne gêne pas, tout en évitant de casser l’ordinateur
    Surtout, on peut utiliser facilement le mode plan pour terminer rapidement le travail

• Depuis le passage d’OpenCode à Pi, les performances des appels d’outils se sont nettement améliorées et il semble y avoir moins de bugs
  OpenCode semble aussi avoir disparu de https://openrouter.ai/apps/category/coding

  • L’équipe d’OpenCode a demandé à être retirée du classement OpenRouter : https://github.com/anomalyco/opencode/issues/11926#issuecomm...
  • Ce n’est pas tant qu’OpenCode soit mauvais, c’est surtout que Pi est bon. On pourrait dire la même chose en comparant Claude et Pi
  • L’un des avantages d’OpenCode est son intégration LSP, et je me demande comment Pi gère cela
  • J’ai récemment essayé OpenCode et Pi, et en venant de Claude Code, j’ai été surpris de voir que les deux autorisent les modifications par défaut sans fenêtre de confirmation
    De mémoire, l’un permet d’activer la confirmation dans les réglages et l’autre nécessite un plugin
  • J’ai complètement supprimé OpenCode après l’avoir vu télécharger des paquets npm en arrière-plan sans demander à l’utilisateur
    Ce comportement augmente encore le risque d’attaque de la chaîne d’approvisionnement

• Qu’une application desktop TUI qui ne fait qu’afficher du texte soit plus lourde qu’une application native, et même que la plupart des applications desktop basées sur un navigateur, est absurde, et gaspille RAM, CPU, énergie et batterie
  Je développe en C++ Qt6 mon propre outil d’exécution IA faisant aussi office d’application de chat, et malgré la présence de sous-agents, diff de code, émulateur de terminal, éditeur simple, aperçu Markdown, arrière-plan translucide, thèmes utilisateur, permissions, MCP, intégration Git, système de docking et onglets de projet, il reste plus léger que les autres outils
  Je ne l’ai pas encore publié, car je suis encore en train d’éliminer quelques bugs et de simplifier puis peaufiner l’UI : https://zeteo.krysoph.com/preview.html

• Je comprends maintenant qu’OpenCode supprimait les commentaires à cause du prompt système par défaut : “Use ABSOLUTELY NO COMMENTS”, et cela m’agace énormément
  Cela dit, au-delà d’un simple désagrément, le risque de sécurité s’applique aussi aux autres outils d’exécution. Ces outils ont accès à d’énormes volumes de données, sont mis à jour presque quotidiennement, et vu leur nature de vibe coding, il est probable que personne n’audite vraiment les innombrables dépendances npm qu’ils embarquent
  Un seul incident du type left-pad pourrait suffire à provoquer une catastrophe pour toute la chaîne d’approvisionnement

• Mettre la date dans le prompt système pour invalider le cache à minuit est une décision raisonnable, et la plupart des autres outils d’exécution utilisent aussi cette méthode
  Ce serait irresponsable d’y mettre la date et l’heure complètes, mais OpenCode ne le fait pas

  • Quand j’ai dû attendre 10 minutes pour recharger le cache KV du GPU local en l’utilisant à minuit, cela ne m’a pas semblé très raisonnable
    Il suffirait de n’évaluer la date qu’une seule fois par session, ou une seule fois à chaque exécution du binaire opencode, afin d’éviter qu’une session longue reste bloquée sur une date passée