CLAUDE.md офіційно вважається контекстом для моделі, а не жорсткою конфігурацією — заборони на кшталт «не пуш у main» чи «не читай .env» можуть ігноруватися. Автор побудував окремий шар хуків і довів тести до 67 (почав з 21, дірки з'являлися щоразу, коли скрипт перевіряла інша модель): прості обходи типу bash -lc 'rm -rf build' чи sudo -u root rm -rf build наївний хук пропускає.

Чому текстове правило в CLAUDE.md не стопить команду

Офіційна документація Claude Code прямо каже: CLAUDE.md — це контекст для моделі, а не примусова конфігурація. Написане там «не пушити в main» чи «не читати .env» модель враховує як побажання, а не як заборону, яку неможливо обійти. Автор матеріалу зробив із цього практичний висновок: замість того щоб шліфувати формулювання в CLAUDE.md, потрібен окремий шар, який зупиняє команду до її виконання незалежно від того, що вирішила модель.

Це проблема механізму, а не поведінки конкретної моделі. Тому й рішення механічне: хуки, які перевіряють форму команди перед запуском і відмовляють, якщо вона підпадає під заборонений патерн.

Як тести довели хук до 67 випадків

Перша версія хука мала 21 тест. Автор давав скрипт на перевірку іншій моделі-агенту — і щоразу з'являлися нові дірки: способи написати ту саму небезпечну команду, які наївний фільтр пропускає. Приклади: bash -lc 'rm -rf build' замість прямого rm -rf build, або sudo -u root rm -rf build. Формально це не хитрощі, а звичайні способи записати ту саму команду — просто хук їх спершу не розпізнавав.

Кожен тест позначений одним зі статусів — «відмовити / дозволити / неможливо визначити» — і раундом, у якому його додали. Такий журнал показує, які дірки закрито нещодавно, а не просто дає набір з 67 правил без історії. На Claude Code 2.1.283 у режимі bypassPermissions, який пропускає всі підтвердження дозволів, хук усе одно зупиняв rm -rf до виконання і відмовляв читати .env.

Сортувальний аркуш: не все з CLAUDE.md варто тягнути в хук

Окрема практична частина — розподіл правил CLAUDE.md на чотири категорії: залишити як прохання, відмовляти налаштуванням дозволів, зупиняти скриптом-хуком або блокувати структурно (наприклад, захистом гілки на рівні репозиторію, а не на рівні агента). Хуки — дорогий і крихкий інструмент: писати й тестувати варто ті кілька рядків, порушення яких коштує дорого, а не переписувати весь файл правил у код.

До цього ж належить журнал, у якому фіксується, що саме зупинено скриптом, а що залишається неприкритим — щоб не покладатися на здогад про те, що «начебто це теж стопиться».

Де хук пропускає — і що варто перевірити самому

Автор нарахував і задокументував сім форм команд, які цей набір хуків не зупиняє. Серед них — запис через змінні та дії, що виконуються зсередини скриптів, написаних самим Claude, наприклад видалення файлів із Python-коду, який агент сам згенерував і запустив. Хук перевіряє форму текстової команди, тому те, що відбувається на рівень нижче, усередині виконуваного скрипта, вже поза його зоною видимості.

Ще один нюанс: довгі завдання виконує не батьківський процес, а дочірній суб-агент, якого запускає батько. Офіційна документація стверджує, що хуки з конфігураційних файлів працюють і в суб-агентах, але не пояснює, як це перевірити на власних налаштуваннях. Типова помилка — покластися на цю фразу і не протестувати сценарій із суб-агентом окремо, руками, на своєму settings.json.

Перш ніж довіряти набору хуків, варто прогнати саме ці дві перевірки: спробувати обхід через змінну чи власноруч написаний скрипт і повторити небезпечну команду в сценарії з суб-агентом, а не лише в прямому виклику від батьківського процесу.