Danger des permissions par défaut de OpenCode sur un projet d'infrastructure as code

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 🤗.

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 🤔.