Codex exec в Claude Code: ревью кода с нулевым контекстом | AiManual
AiManual Logo Ai / Manual.
05 Июл 2026 Гайд

Codex exec: превращаем Claude Code в независимого ревьюера кода

Научитесь использовать команду exec в Codex для создания независимых AI-ревьюеров. Полный гайд с примерами для Claude Code. Версия 2026.

Почему ваш AI-ревьюер похож на автора, проверяющего свою же домашку

Вы замечали? Когда просите Claude Code проверить код, который он только что написал, он почти всегда отвечает: "Код выглядит отлично. Можно улучшить разве что нейминг." А потом этот же код падает в прод с NullPointerException. Дело не в том, что Claude плохой. Дело в контексте. Он помнит, как писал этот код, какие решения принимал, и невольно оправдывает собственные ошибки. Это как попросить студента проверить свою контрольную — найдет пару опечаток, но логическую дыру пропустит.

Нам нужен независимый ревьюер. Тот, кто смотрит на код свежим взглядом, без багажа предыдущих решений. В Claude Code для этого есть механизм — Codex exec. И сегодня я покажу, как выжать из него максимум. Если вы еще не знакомы с архитектурой под-агентов в Claude Code, рекомендую сначала прочитать этот разбор — там объясняется, как работают Subagents и зачем они вообще нужны.

Предупреждение: команда exec требует понимания, что вы делаете. Неправильное использование может сжечь квоту токенов за 5 минут. Читайте до конца, прежде чем экспериментировать.

Что такое Codex exec и почему это не просто "еще один промпт"

Команда exec — это способ запустить новый экземпляр Claude Code внутри текущей сессии. Представьте, что вы работаете в основном терминале, а потом говорите: "Эй, запусти-ка второго клода, дай ему только этот файл и задачу — найди баги". Второй клод стартует с пустым контекстом, без истории чата, без ваших предыдущих команд. Он видит только то, что вы ему скормили через exec.

Звучит просто, но на практике это открывает дверь к целому классу сценариев:

  • Ревью кода без предвзятости — второй экземпляр не знает, что код писал предыдущий AI или вы сами.
  • Параллельные проверки — можно запустить несколько exec для разных модулей.
  • Безопасный аудит — exec не имеет доступа к вашей истории чата, только к переданным данным.
  • Изоляция ошибок — если exec зависнет, основной сеанс не пострадает.

Но есть нюанс: exec — это не магия. Его надо правильно настроить, иначе получите бесконечный цикл из AI, проверяющего AI, проверяющего AI. Об этом чуть позже.

Готовим CLAUDE.md для работы с exec

Первое, что нужно сделать — описать алиас для ревью в файле CLAUDE.md. Без этого exec будет работать как пустая болванка без инструкций. Откройте CLAUDE.md в корне вашего проекта и добавьте туда блок:

# Code Review Agent

Вы — независимый ревьюер кода. Ваша задача — найти в коде:
- Логические ошибки
- Уязвимости (XSS, SQL injection, RCE)
- Проблемы с производительностью
- Необработанные краевые случаи

Правила:
- Никогда не говорите «код хороший». Всегда находите минимум 3 замечания.
- Если код идеален — напишите «Нужен второй ревьюер».
- Каждое замечание сопровождайте строкой кода и причиной.
- Не предлагайте исправления, только указывайте на проблемы.

Зачем такое ограничение — не предлагать исправления? Потому что иначе ревьюер начнет переписывать код, а нам нужен именно аудит. Исправления мы сделаем отдельно. Это одна из лучших практик, описанных в этой статье — разделяй процессы генерации и проверки.

Теперь сам алиас для exec. Добавьте в CLAUDE.md секцию с командами:

# Алиасы

/review [file] — запустить ревью указанного файла через exec

Но сам алиас мы пропишем не в CLAUDE.md (он не поддерживает динамические alias), а через файл .claude-commands или через настройки Claude Code. На момент версии 2.1 (июль 2026) это делается так:

# В .claude/config.yaml (или .clauderc)
aliases:
  review: "exec -m 'Ты — ревьюер из CLAUDE.md. Проверь код в файле {args}'"

Если вы используете версию Claude Code ниже 2.0, обновитесь. Команда exec появилась только в версии 2.0, а в 2.1 добавили поддержку алиасов. Проверить версию: claude --version. Подробнее о горячих клавишах и обновлениях — в этом гайде.

Сценарий 1: Запуск ревью из текущего Claude Code

Самый простой способ — когда вы уже работаете в Claude Code и хотите проверить конкретный файл.

Допустим, у вас есть файл auth.py, который написал AI. Вместо того чтобы писать "Проверь auth.py", что приведет к самопроверке, используйте exec:

/exec -f auth.py -m "Ты — независимый ревьюер. Найди все баги и уязвимости. Не давай поблажек."

Флаг -f передает содержимое файла в новый контекст. Флаг -m устанавливает системное сообщение (инструкцию). Без -f exec не будет знать, что проверять.

Важно: exec не видит CLAUDE.md автоматически. Инструкция из CLAUDE.md не передается в под-агент. Поэтому мы либо передаем ее через -m, либо используем алиас, который это делает за нас.

Через алиас, который мы настроили выше, вызов будет еще короче:

/review auth.py

После выполнения вы получите список замечаний. Обратите внимание: exec работает в отдельном процессе, результат возвращается как текст. Вы можете сохранить его в файл или сразу обработать.

Сценарий 2: Запуск ревью из другого экземпляра Codex

А теперь самое интересное. Вы можете запустить exec прямо из консоли, используя утилиту codex (команда, которая присутствует в Claude Code, но доступна и как отдельный CLI-инструмент с версии 2.1).

Зачем это нужно? Допустим, вы пишете скрипт автоматизации, который:

  • Берет все файлы из директории
  • Запускает для каждого exec-ревью
  • Агрегирует результаты

Или вы хотите встроить AI-ревью в пайплайн CI/CD. Тогда exec запускается не из интерактивного Claude Code, а из шелла или GitHub Actions.

Синтаксис:

codex exec --file auth.py -- "Ты — ревьюер. Проверь код и найди проблемы."

Обратите внимание на -- — он отделяет опции от самого промпта. Без него codex воспримет часть промпта как флаг.

Пример для всей директории:

for f in src/*.py; do
  echo "=== Reviewing $f ==="
  codex exec --file "$f" -- "Проверь файл на уязвимости. Выведи критичные сначала."
done

Этот подход экономит часы человеческого ревью. Но есть подводный камень: каждый вызов exec — это отдельный запрос к API. Если у вас 50 файлов, вы сделаете 50 запросов. Стоимость может вырасти. Рекомендую ограничивать количество параллельных exec через xargs -P 3, чтобы не превысить лимиты аккаунта.

Типичные ошибки и как их избежать

1 "Exec завис"

Если exec не отвечает больше минуты — скорее всего, AI ушел в бесконечный цикл размышлений. Причина: слишком размытая инструкция. Вместо "найди проблемы" дайте конкретные категории: "найди логические ошибки, уязвимости типа OWASP Top 10, проблемы с многопоточностью".

2 "Exec вернул пустой ответ"

Значит, файл не был передан. Проверьте, существует ли файл и есть ли права на чтение. Используйте абсолютный путь, если exec запускается из другого контекста.

3 "Exec видит больше, чем нужно"

По умолчанию exec может получить доступ к файловой системе проекта (если не ограничить права). Если вы передаете -f, он видит только этот файл. Если не передаете — он может начать исследовать директорию. Используйте флаг --sandbox (доступен с версии 2.1.3), чтобы изолировать exec от файловой системы.

💡
Совет: Для ревью кода, написанного другим AI (например, при автоматической генерации), используйте exec с флагом --no-cache. Иначе AI может вспомнить паттерны из предыдущих ревью и начать их повторять, теряя объективность.

Расширенные сценарии: каскадное ревью и аудит legacy

Однажды я запустил exec внутри exec. Звучит безумно, но работает. Сценарий такой: первый exec проверяет код на баги, второй exec проверяет отчет первого exec на полноту и адекватность. Так мы получаем каскадное ревью, где каждый следующий AI ищет ошибки предыдущего. Это полезно для критичного кода (ядро, безопасность, финансовые транзакции).

Пример для legacy-аудита: у вас есть старая кодовая база, написанная 5 лет назад без тестов. Запускаете exec для каждого файла с инструкцией "Найди потенциальные баги, устаревшие API, необработанные исключения". Результаты можно собрать в один отчет и передать команде на фикс. Подробнее про промпты для автономной работы — в этой статье.

Часто задаваемые вопросы

Можно ли использовать exec для security review?

Да, но с оговорками. Exec может видеть только переданный файл, а для security-review часто нужен контекст всего приложения (как данные текут, какие эндпоинты). Лучше передавать несколько файлов через -f file1 -f file2. Для OWASP-скрининга добавьте в промпт: "ищи XSS, SQLi, IDOR, RCE и SSRF".

Как избежать ложных срабатываний?

Добавьте в инструкцию: "Если замечание неуверенное — промаркируй его как LOW. Если уверен на 90%+ — HIGH." И настройте порог: все HIGH обязательно фиксировать, LOW — только если есть время.

Что делать, если exec потребляет слишком много токенов?

Ограничьте размер файла: --max-tokens 4000. Или используйте флаг --quick (появился в 2.1.5), который заставляет AI отвечать коротко. Также можно передавать не весь файл, а только diff (измененные строки).

Можно ли запустить exec для ревью PR целиком?

Да, через CI. Пример для GitHub Actions: передайте все измененные файлы через files=$(git diff --name-only origin/main...HEAD) и для каждого запустите codex exec --file "$file" -- .... Результаты можно запостить как комментарий к PR.

Хотите увидеть больше примеров настройки Claude Code под себя? Загляните в статью о скрытых настройках — там описаны фишки, которые многие пропускают.

И последнее. Не пытайтесь автоматизировать всё подряд. Exec — мощный инструмент, но доверять ему финальное слово по продакшен-коду пока рано. Используйте его как второй этап проверки, а третий этап оставьте за человеком. И обязательно логируйте все результаты exec — потом сможете проанализировать, какие ошибки AI пропускает, и улучшить его промпты.

Кстати, если вы еще не попробовали Claude Pro с расширенной квотой, для частых exec он окупается быстро. А если хотите сравнить с альтернативами — почитайте мой обзор Cursor, Warp и Claude Code.

Подписаться на канал