← Блог

Как я включил Claude Code в режим без вопросов

Сережа Рис · 8 April 2026

claude-codeвайбкодингбезопасностьsetup

Одна строка в ~/.zshrc — и Claude Code больше не спрашивает разрешение на каждое действие. Флаг --dangerously-skip-permissions выглядит страшно, но внутри своего окружения это нормальный рабочий режим, в котором я живу каждый день. Ниже — правила, по которым я его включаю, и границы, за которые не выхожу.

Что я сделал в этой сессии

Попросил агента добавить третий алиас на ту же команду. До этого было два — lfg и дап (это “let’s fucking go” и “давай, поехали” в русской раскладке, чтобы не переключать язык). Теперь есть ещё cc — короткий, на автомате, из любого состояния руки. Все три указывают на одно и то же: claude --dangerously-skip-permissions.

Написал Claude Code на Opus 4.6:

Добавь плз алиас cc в клод код и сделай статью про алиасы-bypass permissions. Что я одобряю. Помни про приватность — но в целом это the way, важно было сказать.

Агент дописал строку в ~/.zshrc рядом с существующими. Руками я ничего не трогал — по принципу “работает — отлично, не работает — пишу пофикси”.

Что вообще делает этот флаг

По умолчанию Claude Code спрашивает approve на каждую операцию, которая может что-то поменять: bash-команду, запись в файл, git, установку пакетов. Всплывает маленькая панель, ты нажимаешь “yes”, и только после этого агент двигается дальше. --dangerously-skip-permissions отключает эти prompt’ы — агент пишет, запускает, коммитит без прерываний.

Именно поэтому флаг называется со словом “dangerously”. Это не PR-трюк, это честно. Anthropic говорит: снимаешь защиту — значит, сам берёшь риск. Правильно. Я и беру.

Почему approve-режим не работает на потоке

У меня около 88 промптов в день на Max-плане, 5-6 часов активной работы с Claude Code. Если на каждую bash-команду агент будет ждать моего клика — я превращусь в кликера yes-yes-yes вместо того, чтобы думать над задачей. Approve-режим хорош в первый день знакомства с инструментом, дальше он рвёт flow в клочья.

Вайбкодинг держится на делегировании. Approve на каждый шаг — противоположность делегированию: ты не можешь одновременно доверить агенту задачу и контролировать каждое его движение. Либо одно, либо другое.

APPROVE-РЕЖИМ                     BYPASS-РЕЖИМ
─────────────                     ────────────

  промпт                            промпт
    │                                 │
    ▼                                 ▼
  план                              план
    │                                 │
    ▼                                 ▼
  шаг 1 ──► approve? ──► wait       шаг 1
    │                                 │
    ▼                                 ▼
  шаг 2 ──► approve? ──► wait       шаг 2
    │                                 │
    ▼                                 ▼
  шаг 3 ──► approve? ──► wait       шаг 3
    │                                 │
    ▼                                 ▼
  результат                         результат
    │                                 │
    ▼                                 ▼
  "я думал над задачей?"            следующий промпт

Слева — иллюзия контроля. На каждом шаге ты вроде бы решаешь, а на самом деле подтверждаешь то, что понял секунду назад. Справа — настоящее делегирование: ты думаешь над задачей, агент думает над шагами.

Что именно я “одобрил” этим алиасом

Я не дал bypass “на всё подряд”. Я дал его в контексте, который контролирую:

Это не храбрость. Это понимание размера взрыва.

Приватность — где я bypass не включаю

Теперь про границы. Не в режиме “бойся”, а в режиме “знай, где начинается чужое”.

Секреты в env. Агент видит всё, что видит твой shell. У меня GEMINI_API_KEY торчит в ~/.zshrc как env var — агент прочитает, если попросить. Это ок ровно потому, что ключ не привязан ни к какому аккаунту с платёжкой и его легко отозвать в консоли Google AI Studio. Всё, что стоит денег или открывает доступ к юзерам, — в dev-shell не хранится. Если у тебя там stripe-ключ или prod-токен, bypass тебе не подходит, пока это не уберёшь.

Рандомные репо. Не клонируй чужой проект и не запускай внутри cc сразу после git clone. В CLAUDE.md могут быть prompt injections — это уже встречается в дикой природе, не теория. В post-install скриптах package.json может быть что угодно. Для работы с чужим кодом — отдельная учётка macOS или VM с отдельным gh аккаунтом. Я, честно, редко такое делаю: чужой код почти не трогаю.

Не для продакшен-серверов. Отдельный пункт с личным шрамом. Был у меня Clawdbot на VPS — агент-ассистент на публичном сервере в bypass-режиме. На второй день из-за дыры в setup’е уехали API-ключи. Вывод простой: bypass + белый IP + долгоживущая сессия — это не дом, это витрина. На своём ноуте — да. На сервере в интернете — нет.

Дома учишься быстрее

Approve-режим — это как учиться плавать в спасжилете. Красиво, безопасно, и ты никогда не почувствуешь воду. С bypass ты гораздо быстрее понимаешь, где агент действительно может навредить, а где просто шумит.

На approve-режиме ты боишься всего одинаково: и ls, и rm -rf. Каждый клик выглядит одинаково важным, поэтому ты не учишься отличать опасное от безобидного. На bypass отличие становится видимым сразу, потому что у тебя есть настоящий feedback loop, а не абстрактный “yes/no” на всё подряд.

Страх permission-prompt выполняет педагогическую роль ровно один день. Дальше он мешает учиться.

Guardrails вместо approve

Клики yes-yes-yes я заменил другими guardrails — они работают сами, пока я думаю над задачей:

Это и есть настоящий контроль: не кликнуть yes на каждый чих, а построить контекст, в котором агенту просто некуда свернуть плохо.

Итог

cc — не разрешение “ломай всё”. Это договор: я контролирую контекст, агент работает без прерываний.

Одна строка в ~/.zshrc. Это не про безрассудство, это про то, чтобы перестать мешать агенту делать то, что ты ему поручил.

Читайте также

Об авторе

Подписаться на обновления — @sereja_tech