Claude Code у non-interactive mode

Non-interactive mode — Claude як bounded step

Non-interactive mode призначений для одноразового запуску із shell-скрипта, локального automation або CI. Замість довгої сесії маємо явний вхід, одну вузьку мету й результат, який можна зберегти та перевірити.

Такий запуск добре підходить для summarization, класифікації логу, підготовки чернетки release notes або короткого аналізу diff. Він не перетворює Claude на безумовного approver: merge, release і production-deploy залишаються рішеннями людини та політик репозиторію.

claude --help

# Приклад: передати Claude вузький diff і зберегти результат
claude -p "Склади короткий опис змін для code review" \
  --allowed-tools "Bash(git diff:*)" \
  > tmp/summary.md

Контракт входу та виходу

Структурований вихід полегшує подальшу обробку, але валідний JSON не робить висновок правильним автоматично. Перевіряйте його проти первинного diff або логу.

Вузьке делегування замість повного доступу

• не передавайте весь репозиторій, якщо достатньо diff або логу;
• не давайте scripted-запуску широке редагування без окремої потреби;
• не передавайте secrets у prompt, stdin або збережені артефакти;
• не дозволяйте створення комітів, push чи destructive commands у першій версії.

1. Визначте, який саме файл або команда є входом.
2. Опишіть, що Claude має повернути і чого не має робити.
3. Надайте лише мінімальні tools та permissions.
4. Запишіть результат у тимчасовий або окремий evidence-файл.
5. Зробіть людський review перед будь-якою зовнішньою дією.

Приклад аналізу логу

Промпт має назвати формат і заборонити редагування. Якщо pipeline потребує машинного розбору, додайте окрему JSON-schema validation і обробляйте невалідний output як failure, а не як порожній успіх.

cat build.log | claude -p \
  "Поверни JSON: категорія, причина, докази, перевірка, наступна дія" \
  > tmp/failure.json

# Далі файл перевіряє script або людина,
# а не автоматичний merge-крок.

Коли обрати інтерактивну сесію