rtk

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

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.

Le 13 avril 2026, j'ai découvert le projet snip :

snip - Reduce LLM token Usage by 60-90%

source

Quelques semaines plus tard, le 29 avril, Alexandre m'a fait découvrir rtk, une alternative à snip.

rtk est un projet Rust dont le développement a commencé le 18 janvier 2026. snip, quant à lui, est un projet Golang initié par un français basé à la Réunion le 15 février 2026, directement inspiré de rtk.

Voici comment le projet snip compare les deux projets :

Design Philosophy

snip chose a fundamentally different approach to LLM token reduction: filters are data, not code. The binary is the engine, filters are YAML data files, and the two evolve independently.

	rtk (Rust)	snip (Go)
Filter authoring	Write Rust, recompile, wait for release	Write YAML, drop in a folder, done
Filter format	Compiled into the binary	Declarative YAML, engine and filters evolve independently
Custom filters	Fork the repo, add Rust code	Create a .yaml file in ~/.config/snip/filters/
Concurrency	2 OS threads	Goroutines (lightweight, no thread pool)
SQLite	Requires CGO + C compiler	Pure Go driver, static binary, no dependencies
Cross-compilation	Per-target C toolchain	GOOS=linux GOARCH=arm64 go build
Pipeline actions	Built-in strategies	19 composable actions (keep, remove, regex, JSON, state machine...)
Contributing	Rust knowledge required	YAML knowledge sufficient

Both tools solve the same problem: reducing AI token costs from verbose CLI output. snip's bet is that extensibility wins. When anyone can write a filter in 5 minutes without touching Go or Rust, the filter ecosystem grows faster.

source

Voici à quoi ressemble un filtre dans rtk : https://github.com/rtk-ai/rtk/blob/master/src/filters/jj.toml.

Et voici l'équivalent pour snip : https://github.com/edouard-claude/snip/blob/master/filters/jj.yaml.

Je trouve la possibilité d'ajouter de nouvelles commandes à snip simplement en créant un fichier YAML intéressante, mais pour le moment je ne sais pas si j'en aurai besoin.

D'autre part, rtk est supporté par Mise : https://mise-versions.jdx.dev/tools/rtk.

Par conséquent, j'ai décidé de tester la configuration de rtk avec OpenCode. Voici le commit d'intégration à sklein-devbox : https://github.com/stephane-klein/sklein-devbox-chezmoi/commit/0fa4917ee2f31605f8d124223ec650961bf057b6.

Voici comment j'ai initialisé le plugin OpenCode pour rtk :

$ rtk init -g --opencode

OpenCode plugin installed (global).

  OpenCode: /home/sklein/.config/opencode/plugins/rtk.ts
  Restart OpenCode. Test with: git status


--- Telemetry ---
RTK collects anonymous usage metrics once per day to improve filters.

  What:    command names (not arguments), token savings, OS, version
  Why:     prioritize filter development for the most-used commands
  Who:     RTK AI Labs, contact@rtk-ai.app
  Rights:  disable anytime with `rtk telemetry disable`,
           request erasure with `rtk telemetry forget`
  Details: https://github.com/rtk-ai/rtk/blob/main/docs/TELEMETRY.md

Enable anonymous telemetry? [y/N] y
  Telemetry enabled. Disable anytime: rtk telemetry disable

Et voici un exemple d'utilisation :

$ opencode run "Quels sont les derniers changements de ce projet ?"

> build · minimax-m2.5

$ rtk git log --oneline -10
0fffe04 Remove mode -x dot_config/tmux/scripts/executable_current-path.sh
832f03b Add peeble/ to Chezignore  #   <m-r>      Reset Message
0fa4917 Setup rtk to reduces OpenCode LLM token consumption
983b77d s6-overlay migration to Pebble (#25)
1f7cbcd Start Mise eval before atuin to fix a bug
c8e6194 Remove gopass and GPG agent management since both services start automatically on first use
71e64e1 Enable Mise environment activation so Neovim can access Mise-managed tools
679f53f Purge empty mise installs/ dirs to force reinstall of incomplete tools
4c32db8 Extract init process into standalone script
8258ab9 Add infomation messages in init scripts

...

Je constate que la commande rtk git log est correctement utilisée par OpenCode.

Voici ce que m'affiche la commande rtk gain :

Pour le moment ceci n'est pas représentatif, car je viens de l'installer et j'ai lancé uniquement des tests fictifs.

Je compte publier une note de bilan d'ici quelques semaines pour analyser si c'est vraiment impactant ou non.