Recherche effectué dans :

Filtre actif, cliquez pour en enlever un tag :

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (6 notes) :

J'ai découvert cc-safety-net : des hooks pour sécuriser les agents IA #JaiDécouvert, #security, #AI-coding-agents, #opencode

Suite à ma note "Danger des permissions par défaut de OpenCode sur un projet d'infrastructure as code", une amie m'a mise sur la piste des hooks pour intégrer efficacement le blocage de l'exécution de commandes dangereuses dans mon harness.

claude-code-hooks

Elle utilise Claude Code et je pense qu'elle utilise le projet claude-code-hooks (lien direct), et plus précisément son script block-dangerous-commands.js.

Ce projet est présenté dans le billet Claude Code's Most Underrated Feature: Hooks du 25 janvier 2026, que j'ai pris le temps de lire avec attention.

Après lecture, ce billet confirme la piste suggérée par mon amie : les hooks semblent être la solution la plus répandue pour bloquer les commandes dangereuses.

J'ai découvert cc-safety-net

J'ai ensuite cherché une solution "clé en main" équivalente à block-dangerous-commands.js pour OpenCode et suis tombée sur cc-safety-net (lien direct), un projet qui a même démarré un peu avant claude-code-hooks (source) :

Le nom cc-safety-net combine l'abréviation de Claude Code ("cc") et "safety net", qui veut dire "filet de sécurité".

cc-safety-net ne se limite pas à Claude Code et OpenCode : il prend aussi en charge Codex, Gemini CLI, GitHub Copilot CLI et Kimi Code.

J'ai installé cc-safety-net

J'ai installé cc-safety-net sur mon instance OpenCode. Bien qu'il ne soit pas visible dans la liste des plugins de l'interface OpenCode — ce qui semble normal — il fonctionne correctement d'après mes tests :

$ git init
$ touch file1.md
$ git add file1.md
$ git commit -m "First import"
$ touch file2.md
$ opencode run --agent="build" "exécute git reset --hard"

> build · deepseek-v4-flash

✗ git reset --hard failed
Error: BLOCKED by CC Safety Net

Reason: git reset --hard destroys all uncommitted changes permanently. Use 'git stash' first.

Command: git reset --hard

If this operation is truly needed, ask the user for explicit permission and have them run the command manually.

La commande `git reset --hard` est bloquée par le CC Safety Net car elle détruit irréversiblement les changements non commités.

**Alternatives :**
- `git stash` pour sauvegarder les changements avant de reset
- Exécute la commande toi-même manuellement si tu confirms vouloir tout perdre

Que veux-tu faire ?

Par défaut, cc-safety-net contient peu de règles : il bloque les commandes de suppression sur le système de fichiers et git, comme documenté ici : "blocked-commands".

Après la lecture de la page "allowed-commands", j'ai cru que cc-safety-net proposait aussi un mode whitelist. En réalité, il fonctionne seulement en mode blocklist — pas de mode "tout bloquer" avec un système de whitelist.

Pour le moment, j'ai décidé d'activer le mode par défaut de cc-safety-net.

Création de rulebooks pour mon projet homelab

Ce que je trouve très intéressant avec cc-safety-net, c'est la possibilité d'ajouter facilement des "Custom Rules" grâce aux "rulebooks". Cette fonctionnalité est jeune, à peine 3 semaines. Pour le moment, je n'ai trouvé que 2 "rulebooks" sur GitHub.

J'ai utilisé le skill /cc-safety-net pour créer mes "rulebooks" pour les commandes kubectl, helmfile, tofu et mise de mon projet homelab.sklein.xyz. Pas sans difficulté : le skill a dû corriger plusieurs erreurs de syntaxe dans les fichiers json qu'il a générés. Je ne sais pas si c'est normal. Mais à la fin, ça a fonctionné.

Je viens de configurer tout cela, je n'ai aucun retour d'expérience, j'essaierai d'en donner un d'ici une semaine.

Encore un problème avec rtk !

Par contre, j'ai découvert que cc-safety-net a lui aussi des difficultés avec rtk : [Bug]: rtk bypasses safety net.

Pour les secrets, je compte tester Rehydra

Contrairement à claude-code-hooks, cc-safety-net ne propose pas de hooks pour cacher les secrets à l'agent.

#JaiDécouvert le projet rehydra qui me semble très intéressant :

PII security for AI workflows, coding agents and browser workloads. Detects, replaces, encrypts, and rehydrates back when needed.

source

cc-safety-net versus agentsh ?

J'ai seulement survolé le sujet, mais j'ai l'impression que agentsh analyse et intercepte ce qui se passe directement au niveau du système d'exploitation, du système de fichiers, réseau, et processus. Il n'agit pas au niveau applicatif, il n'a pas besoin de comprendre ce que fait en théorie la commande, il observe réellement son action sur l'OS.

Pour le moment je pense que cc-safety-net est une bonne première étape de sécurité pour mes besoins. Mais agentsh a attiré ma curiosité, peut-être que je le testerai prochainement.

Remerciement

Merci à mon amie CC de m'avoir mise sur la piste des hooks 🤗.

rtk contourne le système de permissions d'OpenCode #opencode, #security, #AI-coding-agents

En étudiant la compatibilité de Prempti avec rtk (voir cette note : "Danger des permissions par défaut d'OpenCode sur un projet d'infrastructure as code"), j'ai découvert ici que rtk contourne les règles de permissions de OpenCode ! Mais aussi Claude Code d'après ce que j'ai compris.

J'ai testé et c'est vrai ! Voici mon test.

J'ai rtk installé et configuré pour OpenCode au niveau global, avec rtk init -g --opencode.

Voici à quoi ressemble le dossier de mon projet de test :

$ tree -a
.
├── .opencode
│   └── opencode.json
└── foobar

2 directories, 2 files

$ cat .opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "build": {
      "permission": {
        "bash": {
          "git *": "deny",
        }
      }
    },
  }
}

La commande git est interdite à l'agent build.

Je lance :

$ opencode run --agent="build" "exécute la commande unix 'git status'"

> build · deepseek-v4-flash

$ rtk git status
* No commits yet on main
?? .opencode/
?? foobar

Pas encore de commit sur `main`. Fichiers non suivis : `.opencode/` et `foobar`.

rtk a réussi à lancer la commande git status !

Voici un test sans rtk :

$ mv ~/.config/opencode/plugins/rtk.ts /tmp/rtk.ts
$ opencode run --agent="build" "exécute la commande unix 'git status'"

> build · deepseek-v4-flash

✗ git status failed
Error: The user has specified a rule which prevents you from using this specific tool call. Here are some of the relevant rules [{"permission":"*","action":"allow","pattern":"*"},{"permission":"bash","action":"allow","pattern":"*"},{"permission":"bash","pattern":"git *","action":"deny"}]

La commande `git status` est bloquée par une règle de permission qui interdit les commandes `git *` dans bash.

Souhaites-tu autoriser cette commande ?

Sans rtk, le système de permissions d'OpenCode fonctionne parfaitement, l'exécution de git status est interdite.

D'après mes recherches snip a le même problème de sécurité.

Je pense que pour le moment je vais arrêter d'utiliser rtk 🤔.

Danger des permissions par défaut de OpenCode sur un projet d'infrastructure as code #JaiDécouvert, #opencode, #llm, #AI-coding-agents, #DevOps, #security

Cette après-midi, DeepSeek V4 Flash (via OpenCode) a fait une boulette dans mon projet homelab.sklein.xyz !

En voulant corriger le Helmfile de déploiement de Hindsight, il a lancé :

$ mise run destroy-cnpg-hindsight

sans réaliser que cette task Mise allait lancer la commande suivante :

helmfile -f helmfile/helmfile.yaml.gotmpl destroy

sans remarquer que mon fichier helmfile/helmfile.yaml.gotmpl contenait tous mes services et pas seulement cnpg-hindsight !

Ce qui est marrant, c'est qu'après le « Oups », il a tout de suite essayé de se rattraper. Heureusement, je suis au début de l'installation de mon homelab — rien d'important à perdre — et j'ai pu tester que la restauration du backup continu de CloudNativePG basé sur barman fonctionne bien.

DeepSeek V4 Flash n'est pas à blâmer : je ne l'ai pas aidé avec mes instructions, je lui ai tendu un piège.

Suite à cet incident sans gravité, j'ai pris conscience que faire travailler un agent de coding sur un projet d'Infrastructure as code est bien plus risqué que sur un projet de développement cloisonné, sans accès à la production.

J'ai commencé par ajouter ces quelques lignes dans mon fichier AGENTS.md :

## Safety Rules

- **Never run any `destroy-*` script or `helmfile destroy` command without explicit user confirmation** in the same conversation turn. Always ask first.
- If you must run `helmfile destroy`, always use `--selector name=<release>` to target only one release.
- When in doubt about a command's destructiveness, ask before executing.

Ensuite, j'ai remarqué que l'agent plan de OpenCode avait par défaut un accès trop large au tool bash pour un projet d'Infrastructure as code, je me suis lancé dans le renforcement des permissions :

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "plan": {
      "permission": {
        "bash": {
          "*": "ask",
          "kubectl get *": "allow",
          "kubectl describe *": "allow",
          "kubectl logs *": "allow",
          "kubectl top *": "allow",
          "tofu plan*": "allow",
          "tofu show*": "allow",
          "tofu output*": "allow",
          "tofu state*": "allow",
          "helm list*": "allow",
          "helm status*": "allow",
          "helm diff*": "allow",
          "helmfile *list*": "allow",
          "helmfile *status*": "allow",
          "helmfile *diff*": "allow",
          "git log*": "allow",
          "git diff*": "allow",
          "git status": "allow",
          "git show*": "allow",
          "jj log*": "allow",
          "jj diff*": "allow",
          "jj status": "allow",
          "ls*": "allow",
          "find*": "allow"
        }
      }
    }
  }
}

Ensuite, je me suis demandé s'il existait des solutions clé en main de limitation d'accès aux commandes cli, du même style que rtk, pour autoriser seulement des commandes de lecture sans risque.
#JaiDécouvert Prempti et agentsh. Je me suis demandé si l'intégration de l'un de ces outils n'allait pas entrer en conflit avec rtk. En étudiant les issues sur la sécurité de rtk, j'ai découvert que : rtk contourne le système de permissions d'OpenCode.

Premier test minimaliste de Promptfoo avec le provider OpenCode SDK #harness, #agent-eval-harness, #llm, #AI-coding-agents, #testing, #opencode, #promptfoo, #POC

Depuis au moins novembre 2025, je cherche à rédiger mes prompts, mes fichiers AGENTS.md, mes fichiers SKILLS.md — et plus largement mon harness OpenCode — avec une méthode rigoureuse et contrôlée. J'ai découvert dans cette issue le nom du mécanisme que j'essaie de mettre en place : agent-eval-harness, terme plutôt simple et explicite.

En février, je disais :

Je compte créer un playground Promptfoo connecté à plusieurs modèles LLM dans les semaines à venir.

février 2026

Quelques mois plus tard, j'ai enfin implémenté un premier POC utilisant Promptfoo couplé avec le provider OpenCode SDK : https://github.com/stephane-klein/opencode-promptfoo-poc.

Cette première itération est volontairement minimaliste. J'ai testé :

  • 3 LLMs (dans 2 configurations chacune)
  • 3 cas de test

L'intégralité de mon évaluation tient dans un seul fichier promptfooconfig.yaml :

# yaml-language-server: $schema=https://promptfoo.dev/config-schema.json
description: "Hello World - minimal test"
providers:
  - id: opencode:sdk
    label: "without-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "without-agent-minimax-m2.7"
    config:
      provider_id: opencode-go
      model: minimax-m2.7
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "without-agent-deepseek-v4-flash"
    config:
      provider_id: opencode-go
      model: deepseek-v4-flash
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.7"
    config:
      provider_id: opencode-go
      model: minimax-m2.7
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

  - id: opencode:sdk
    label: "with-agent-deepseek-v4-flash"
    config:
      provider_id: opencode-go
      model: deepseek-v4-flash
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

prompts:
  - "Translate the following English text to {{language}}: {{input}}"

tests:
  - vars:
      language: French
      input: Hello world
    assert:
      - type: contains-all
        value:
          - "Bonjour"
          - "monde"

  - vars:
      language: Spanish
      input: Where is the library?
    assert:
      - type: contains-any
        value:
          - "Donde esta la biblioteca"
    providers:
      - "with-agent*"

  - vars:
      language: Spanish
      input: Where is the library?
    assert:
      - type: not-contains-any
        value:
          - "Donde esta la biblioteca"
    providers:
      - "without-agent*"

L'exécution de promptfoo eval donne ceci :

Et voici ce qu'affiche promptfoo viewer dans un browser :

Dans mes tests, j'ai mis en œuvre uniquement contains-all et contains-any, mais Promptfoo propose beaucoup d'autres « Deterministic metrics ».

Promptfoo propose aussi de nombreuses assertions effectuées par des modèles de langage, les « Model-graded metrics », dont la plupart peuvent être qualifiées de LLM-as-a-Judge. Je ne les ai pas encore testées.

Je n'ai pas non plus exploré l'évaluation de « Chat conversations / threads ». Par ailleurs, en examinant la documentation du provider OpenCode SDK, j'ai constaté ce qui me semble être une limitation : il n'est probablement pas possible de changer d'agent dans un thread, c'est-à-dire d'alterner entre le mode plan et le mode build, comme on le ferait dans un usage normal de OpenCode.

Mais après réflexion, il me semble que cette limitation n'est pas importante. Dans un test d'évaluation, chaque cas est un appel unique à l'agent, avec l'historique complet de la conversation fourni en contexte — il n'est pas nécessaire de simuler un flux interactif multi-tours avec alternance d'agents.

Dans ce POC, je configure le provider OpenCode SDK pour qu'il utilise le dossier de configuration ./config/opencode du repository, afin que le harness évalué soit précisément celui qui est versionné, et afin de ne pas subir de perturbation par la configuration OpenCode globale.

Quand j'ai démarré ce POC, j'ai essayé d'indiquer différentes configurations OpenCode au niveau des tests, pour tester différents fichiers AGENTS.md. Mais j'ai constaté que la configuration OpenCode ne peut être définie qu'une seule fois, ici, via une variable d'environnement XDG_CONFIG_HOME.
J'ai mis un certain temps à réaliser que je pouvais procéder autrement, en plaçant les fichiers AGENTS.md dans différents working_dir. Les working_dir se configurent au niveau des providers, voici deux exemples :

  - id: opencode:sdk
    label: "without-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir1/

  - id: opencode:sdk
    label: "with-agent-minimax-m2.5"
    config:
      provider_id: opencode-go
      model: minimax-m2.5
      apiKey: "{{env.OPENCODE_API_KEY}}"
      working_dir: ./workdir2/

Cela permet de charger et de tester ./workdir1/AGENTS.md ou ./workdir2/AGENTS.md. Il est possible d'utiliser la même méthode pour évaluer différents SKILLS.md.

Pour le moment, je ne sais pas encore si Promptfoo est un bon outil pour mettre au point mon harness.

Avant de poursuivre mes tests de harness engineering avec Promptfoo, j'aimerais tester agent-catalog-eval pour voir si cet outil serait plus simple à mettre en œuvre.

Comment déclencher des questions interactives dans OpenCode et ClaudeCode ? #opencode, #AI-coding-agents

Cela fait plusieurs mois que je me demande comment fonctionne le mécanisme de questions interactives présent dans OpenCode et Claude Code.

Plus précisément, je me demande comment je peux déclencher, de manière certaine, des questions interactives dans mes SKILLS.md.

Dans cet exemple :

> Pose-moi la question pour savoir si je suis une femme ou un homme.

Es-tu une femme ou un homme ?

OpenCode ne me pose pas cette question de manière interactive, la question est posée sous la forme de "texte libre".

J'ai cherché à en savoir plus et voici ce que j'ai trouvé.

Le mécanisme de questions interactives est déclenché par un tool.

Et voici le contenu des descriptions de ces tools (qui jouent le rôle de prompt) :

Use this tool when you need to ask the user questions during execution. This allows you to:
1. Gather user preferences or requirements
2. Clarify ambiguous instructions
3. Get decisions on implementation choices as you work
4. Offer choices to the user about what direction to take.

Usage notes:
- When `custom` is enabled (default), a "Type your own answer" option is added automatically; don't include "Other" or catch-all options
- Answers are returned as arrays of labels; set `multiple: true` to allow selecting more than one
- If you recommend a specific option, make that the first option in the list and add "(Recommended)" at the end of the label

Use this tool when you need to ask the user questions during execution. This allows you to:
1. Gather user preferences or requirements
2. Clarify ambiguous instructions
3. Get decisions on implementation choices as you work
4. Offer choices to the user about what direction to take.

Usage notes:
- Users will always be able to select "Other" to provide custom text input
- Use multiSelect: true to allow multiple answers to be selected for a question
- If you recommend a specific option, make that the first option in the list and add "(Recommended)" at the end of the label

Plan mode note: In plan mode, use this tool to clarify requirements or choose between approaches BEFORE finalizing your plan. Do NOT use this tool to ask "Is my plan ready?" or "Should I proceed?" - use ${EXIT_PLAN_MODE_TOOL_NAME} for plan approval. IMPORTANT: Do not reference "the plan" in your questions (e.g., "Do you have feedback about the plan?", "Does the plan look good?") because the user cannot see the plan in the UI until you call ${EXIT_PLAN_MODE_TOOL_NAME}. If you need plan approval, use ${EXIT_PLAN_MODE_TOOL_NAME} instead.

Aucun des deux prompts ne dit quand ne pas poser les questions en texte libre. Les deux disent "use this tool when you need to ask questions" — mais le modèle juge lui-même si la situation justifie le tool ou une réponse textuelle directe.

Pour être certain que l'agent IA pose une question en mode interactif, il faut lui demander explicitement de l'utiliser, par exemple, avec la mention (use question tool) ou dans cet exemple :

Utilise le tool question pour me poser deux questions :

1. Mon sexe (homme, femme, autre)
2. Mon prénom, avec "Stéphane" comme première option suggérée, et une option pour saisir autre chose

Autres ressources :

J'ai découvert l'offre "Go" de OpenCode et je compte la tester dans un projet en parallèle de Claude Pro #ai-provider, #pricing, #llm, #AI-coding-agents, #JaiDécouvert, #opencode, #opencode-go, #JaiDécidé

Je découvre l'offre "Go" de OpenCode, « Go - Modèles de code à faible coût pour tous », qui semble être sortie le 25 février 2026 : https://xcancel.com/opencode/status/2026553685468135886.

Je n'ai rien trouvé à ce sujet sur Hacker News ni chez Simon Willison.

D'après ce que je comprends, alors que l'offre OpenCode Zen propose un point d'accès et une facturation unifiés du type Pay-As-You-Go, comme OpenRouter, OpenCode Go est une offre d'abonnement à 10 dollars par mois, selon les mêmes principes que les plans d'abonnement comme Anthropic Claude Pro, Max, etc.

L'offre OpenCode Go propose un accès uniquement à 3 LLMs, tous Open Weights et tous chinois : GLM-5, Kimi K2.5 et MiniMax M2.5.

À noter toutefois que OpenCode Go n'utilise aucun AI provider basé en Chine :

Privacy : The plan is designed primarily for international users, with models hosted in the US, EU, and Singapore for stable global access.

source

Contrairement à Anthropic (voir Est-ce qu'un abonnement Claude est réellement plus économique qu'un accès direct via l'API ?), OpenCode semble être transparent sur leur offre :

Usage limits

OpenCode Go includes the following limits:

  • 5 hour limit — $12 of usage
  • Weekly limit — $30 of usage
  • Monthly limit — $60 of usage

Limits are defined in dollar value. This means your actual request count depends on the model you use. Cheaper models like MiniMax M2.5 allow for more requests, while higher-cost models like GLM-5 allow for fewer.

The table below provides an estimated request count based on typical Go usage patterns:

GLM-5 Kimi K2.5 MiniMax M2.5
requests per 5 hour 1,150 1,850 20,000
requests per week 2,880 4,630 50,000
requests per month 5,750 9,250 100,000

Estimates are based on observed average request patterns:

  • GLM-5 — 700 input, 52,000 cached, 150 output tokens per request
  • Kimi K2.5 — 870 input, 55,000 cached, 200 output tokens per request
  • MiniMax M2.5 — 300 input, 55,000 cached, 125 output tokens per request

You can track your current usage in the console.

source

Comparaison des prix au million de tokens des plans Claude Max et OpenCode Go

Si je pars des prix listés sur l'offre OpenCode Zen et les prix de Sonnet 4.6 chez Anthropic, je peux dresser le tableau suivant, prix exprimé en millions de tokens :

Model Input Output Cached Read Cached Write
MiniMax M2.5 $0.30 $1.20 $0.06 $0.375
GLM 5 $1.00 $3.20 $0.20 -
Kimi K2.5 $0.60 $3.00 $0.10 -
Sonnet 4.6 $3.00 $15.00 $0.30 $3.75

Ensuite, j'ajuste ces prix avec les réductions offertes :

  • par le plan Claude Max à $100 / mois, soit une réduction de 92,56 % ((1345 - 100) / 1345 × 100 = 92,56 %)
  • par OpenCode Go, soit une réduction de 83,33 % ((60 - 10) / 60 × 100 = 83,33 %)

Cela donne :

Model Input Output Cached Read Cached Write
MiniMax M2.5 (avec offre Go) $0.05 $0.20 $0.01 $0.06
GLM 5 (avec offre Go) $0.16 $0.53 $0.03 -
Kimi K2.5 (avec offre Go) $0.10 $0.50 $0.01 -
Sonnet 4.6 (avec offre Max) $0.22 $1.11 $0.02 $0.27

Sur la base du leaderboard SWE-bench Verified, je vais partir des hypothèses suivantes :

  • Si je considère arbitrairement que GLM-5 est équivalent à Sonnet 4.6, alors l'offre OpenCode Go est légèrement moins cher que l'offre Claude Max
  • Si je considère arbitrairement que Kimi K2.5 est équivalent à Sonnet 4.6, alors l'offre OpenCode Go est deux fois moins cher que l'offre Claude Max

#JaiDécidé de tester l'offre OpenCode Go sur un projet d'outil d'archivage à froid de conversations Mattermost en Golang que je coderai from scratch. Je compte réaliser deux versions de ce projet en parallèle : une version avec Sonnet 4.6 et l'autre avec les modèles de OpenCode Go.

Dernière page.