Codex /goal и Claude Code /goal похожи только на уровне идеи: агент продолжает работу, пока цель не выглядит достигнутой. Для практической разработки этого мало. Перед запуском нужно понять, кому принадлежит задача, чем будет доказано завершение, какой режим разрешений действует и где находится правило остановки.
Используйте Codex /goal, когда работа уже находится в Codex, область репозитория ограничена, а результат можно проверить тестом, typecheck, lint, snapshot или reviewable diff. Используйте Claude Code /goal, когда вы уже управляете задачей в Claude Code, важны локальная рабочая область и permission mode, а завершение можно оценить по видимым в сессии доказательствам. Если задача меняется по ходу, требует вкуса, затрагивает production data или не имеет abort rule, не отдавайте ее ни одному goal loop.
Быстрая доска выбора
| Route | Когда использовать | Доказательство до старта | Правило остановки |
|---|---|---|---|
Codex /goal | Задача естественно живет в Codex local, CLI или thread flow и должна дать проверяемый diff. | Test, lint, typecheck, snapshot или review diff должны показать завершение. | Pause, resume или clear, если цель изменилась, diff вышел за границы или proof command дважды не помог. |
Claude Code /goal | Работа уже идет в Claude Code, а local steering и permission mode важны. | Evaluator должен видеть достаточные tool outputs, file changes и объяснения в сессии. | Clear или заменить цель, если completion condition стала неоднозначной. |
| Guided session | Нужны архитектурные решения, вкус, уточнения, incident triage или переговоры с человеком. | После каждого открытия человек все еще должен выбрать следующий шаг. | Держать agent в plan/chat mode, а не в автоматическом loop. |
| CI / scheduler | Задача повторяется, запускается по времени или должна иметь собственные логи и retry policy. | Workflow, cron, queue или CI job имеют свой статус и escalation path. | Пусть automation владеет временем; agent меняет workflow, но не является workflow. |
Эта таблица отвечает на настоящий вопрос лучше, чем обычная таблица победителей. Goal loop полезен только тогда, когда completion можно проверить. Он слаб, если желаемый результат звучит как «улучшить», «причесать», «разобраться» или «доделать как-нибудь». В таких формулировках нет проверяемого конца, а значит агент либо остановится слишком рано, либо продолжит работу после момента, когда должен был спросить человека.
В русскоязычной выдаче много широких сравнений Claude Code и Codex: кто быстрее, кто лучше понимает репозиторий, кто больше похож на коллегу. Для /goal важнее другой слой. Здесь решает не бренд, а контракт выполнения: где работает агент, какие действия ему разрешены, что считается доказательством и кто проверяет результат.
Что на самом деле меняет /goal
В проверенной документации OpenAI Codex команда Codex /goal описана как experimental slash command, связанная с feature flag goals. Там перечислены /goal <objective>, /goal, /goal pause, /goal resume и /goal clear. Это означает, что ее нельзя описывать как вечный стабильный режим для всех поверхностей Codex без уточнения текущего источника.
Документация Claude Code описывает /goal вокруг completion condition. Claude Code продолжает несколько turn, а после каждого turn оценщик смотрит на видимые доказательства из сессии и решает, выполнено ли условие. Эта модель удобна для задач, где «готово» можно увидеть по файлам, tool outputs и пояснениям. Она не превращает сессию в независимую систему одобрений.
Общая идея проста: пользователь формулирует цель, агент продолжает движение, а затем возвращает контроль. Различие в окружении. Codex может быть app, IDE, CLI или cloud task; у каждого маршрута разные границы репозитория, sandbox и review path. Claude Code связан с session, trusted workspace, permission modes и тем, что видно evaluator. Поэтому сравнение должно начинаться не с model leaderboard, а с operational route.
Пять механик, которые нельзя смешивать
| Вопрос | Codex /goal | Claude Code /goal | Практический вывод |
|---|---|---|---|
| Enablement | В проверенном источнике experimental и требует goals feature flag. | Нужны поддерживаемая версия и trusted workspace. | Availability нужно проверять по owner docs. |
| Work surface | App, IDE, CLI и cloud route могут иметь разные границы. | Claude Code session, remote/non-interactive route и local settings различаются. | Цель не должна предполагать другой route. |
| Completion evidence | Лучше всего работают proof command или reviewable diff. | Evaluator судит по evidence, уже показанным в сессии. | Нечеткое evidence дает ложное завершение. |
| Permission boundary | Goal не расширяет sandbox и не утверждает команды. | Permission modes остаются отдельным выбором. | Loop не равен authorization. |
| Usage and billing | Долгие задачи могут расходовать больше allowance. | Subscription и API-key routing тоже отдельны. | Перед долгой задачей проверьте активный route. |
Самая частая ошибка — написать цель как поручение человеку: «почини все», «доведи до идеала», «разберись с миграцией». Агенту нужен более узкий контракт. Если задача начинается с исследования, используйте plan mode или обычную сессию. Если задача должна в итоге дать diff, сначала зафиксируйте branch, файлы, setup command, proof command и stop rule.
Контракт цели перед запуском
| Элемент | Достаточно конкретно | Слишком расплывчато |
|---|---|---|
| Конечное состояние | «Все падающие тесты в packages/billing проходят после исправления date parsing regression.» | «Почистить billing.» |
| Команда проверки | «pnpm test packages/billing -- date проходит.» | «Проверь, что работает.» |
| Границы области | «Только parser, fixtures и regression tests.» | «Меняй что нужно.» |
| Permission mode | «Изменения кода разрешены; destructive shell commands спрашивать.» | «Делай все сам.» |
| Usage check | «Остановиться после двух неудачных proof-command попыток.» | «Пробуй до победы.» |
| Abort rule | «Если ошибка ушла за пределы date parsing, остановиться и доложить.» | «Разберись сам.» |
Хорошая цель похожа на acceptance contract. Она описывает состояние, evidence, scope и момент, когда agent обязан остановиться. Например:
hljs textGoal: In Codex CLI, change only checkout discount tests and rounding helper so pnpm test packages/checkout -- discount passes. Stop if payment provider code must change.
Или:
hljs textGoal: In Claude Code, finish anchor fixes in docs/api/authentication.md; the goal is met when docs lint passes. Ask before editing any file outside docs/api/.
Обе формулировки узкие. Они дают reviewer понять, что должно было измениться и что не должно было попасть в diff. Они также защищают от ситуации, когда agent находит смежную проблему и незаметно расширяет задачу.
Что /goal не заменяет
/goal не заменяет permissions. Если Claude Code находится в режиме, где нужно спрашивать перед действиями, цель не означает автоматическое согласие. Если Codex работает в sandbox или ограниченном repo route, цель не расширяет эти границы.
/goal не заменяет tests. Completion condition может включать «tests pass», но сами tests нужно запустить, показать и выбрать правильно. Узкий зеленый тест не доказывает, что production path безопасен.
/goal не заменяет code review. Diff, созданный в goal loop, остается diff. Нужно посмотреть files changed, reasoning, proof commands и любые неожиданные edits. Если agent сделал широкий refactor вместо локальной правки, review должен это остановить.
/goal не ограничивает расходы. Хорошая цель может уменьшить wasted turns, но долгий loop может потратить больше allowance. OpenAI и Anthropic route, plan, API key, subscription allocation и cloud behavior меняются; проверяйте активный account surface.
/goal не защищает secrets и production data. Не помещайте customer records, live credentials, irreversible migrations или billing operations внутрь автоматического goal loop. Для этого нужны runbook, staging, backups и explicit approval.
Когда обычная сессия или CI лучше
Обычная guided session лучше, когда задача меняется по мере исследования. Architecture discovery, ambiguous UI polish, incident triage и migration planning требуют остановок, вопросов и решений. Goal loop может продолжить работу именно тогда, когда человек должен был переопределить цель.
CI, scheduler, queue или repository automation лучше, когда проблема во времени и повторяемости. Nightly audit, recurring docs check, deployment verification и monitoring report должны иметь собственные логи, retry, alerting и ownership. Agent может написать workflow, но workflow должен владеть loop.
Если вопрос все еще широкий — «какой coding agent выбрать в целом» — используйте /ru/posts/codex-vs-claude-code. Если нужна граница между Claude subscription и API billing, полезнее /ru/posts/claude-api-pricing-vs-subscription. Эта страница отвечает только за /goal и completion-condition delegation.
Практические паттерны
Test repair goal
hljs textGoal: Fix auth/session-expiry without changing public API behavior. Complete only when pnpm test auth/session-expiry passes and the diff touches only session expiry code and tests.
Это хороший candidate, потому что failure boundary известен, proof command узкая, а reviewer может быстро увидеть лишние изменения.
Bounded refactor goal
hljs textGoal: Rename internal legacyToken helper to sessionToken inside packages/auth only. Complete when typecheck passes and no file outside packages/auth changes.
Такой goal можно отдать Codex, если вам нужен reviewable diff, или Claude Code, если вы уже работаете в локальной сессии и permission mode выбран осознанно.
Documentation consistency goal
hljs textGoal: Update three OAuth setup pages so each has the same redirect URI warning and docs lint passes. Stop if product behavior must change.
Здесь результат ограничен, proof понятен, а abort rule не дает docs task превратиться в product change.
Bad goal: broad polish
hljs textGoal: Make the dashboard better.
Это не completion condition. Сначала проведите guided session, составьте issue list, затем разбейте работу на малые цели: empty state, keyboard focus, loading error, accessibility violation.
Bad goal: production risk
hljs textGoal: Fix the production billing migration and keep going until it works.
Такой запрос должен жить в controlled runbook. Goal loop не должен быть владельцем irreversible operational risk.
FAQ
Codex /goal и Claude Code /goal — одна и та же функция?
Нет. Обе функции используют идею completion condition, но product contracts разные. Codex /goal описан как experimental Codex slash command. Claude Code /goal описан через completion condition, evaluator evidence, one active goal per session и trusted workspace.
Что пробовать первым?
Codex /goal — для bounded Codex-native work с proof command и reviewable diff. Claude Code /goal — для work already in Claude Code, где важны local steering и permission mode. Если цель расплывчата или рискованна, сначала не используйте ни один.
/goal одобряет shell commands или edits?
Нет. Goal completion и permission approval — разные controls. Claude Code permission modes остаются важными; Codex sandbox, repo access и review settings тоже.
/goal снижает стоимость?
Не рассчитывайте на это. Хорошая цель может уменьшить лишние turns, но long-running work может потреблять больше allowance. Перед запуском проверьте активный route, plan и API-key behavior.
Что делает цель хорошей?
Measurable end state, proof command или review artifact, narrow scope, known permission mode, usage check и abort rule. Если чего-то нет, сначала попросите plan.
Когда CI или scheduler лучше?
Когда работа recurring, time-based или должна выполняться без interactive session. CI должен владеть timing, logs, retries и escalation; coding agent может улучшить этот workflow.
