THE WORLD IS NOT STANDING STILL.RSS
BIG CHANGE.

Markdown edition

# Fix and verify one failing repository check with an AI Goal

> Set a bounded Claude Code or Codex CLI Goal for one existing failing check, then verify the original command and final diff before accepting a repair.

By BIG CHANGE Editorial

Published: 2026-10-20T05:48:37.854Z
Updated: 2026-10-20T05:48:37.854Z
Canonical: https://bigchange.ai/blog/ai-goal-failing-repository-check-guide

![Conceptual charcoal illustration of a developer reviewing a code diff beside a laptop showing an unresolved check.](https://bigchange.ai/api/media/file/ai-goal-failing-check-review-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE.

An AI coding assistant can keep working through a failing check, but the check itself and the final code still need your review. This guide is for a developer who owns a repository with one test, build or lint command that already fails. It uses a bounded Goal in Claude Code or, as a separate option, the interactive Codex CLI. Choose one. The finish line is the original command passing on a reviewed change that preserves the behavior you named in advance. If that cannot be shown, keep the failure and the exact blocker. This is a documentation-based procedure; BIG CHANGE did not run a Goal or repair a repository for this article.

## The big change

- **What changed:** The documented `/goal` commands keep a stated objective active across turns, so the assistant can inspect a failure, make a scoped change and check again without a new instruction from you after every turn.
- **Why it matters:** You can define the original failing command, permitted files and protected behavior before the loop starts. That gives successive attempts the same acceptance target.
- **What to watch:** A Goal status or model verdict cannot prove the repair. Read the real check output and final diff, and make the decision to accept the change yourself.

## Before you start: capture the failure and the boundaries

Use a repository you are authorized to change. Read its local instructions, including `AGENTS.md` or `CLAUDE.md` where present, and check the branch, existing edits and untracked files. In a Git repository, these commands give you a starting inventory:

```sh
git status --short
git diff --stat
git diff
```

Keep that inventory so you can distinguish the assistant's changes from work already in progress. Run the **actual failing check** once, or save a recent trustworthy run with the exact command, complete error and exit status. Do not replace it with a sample command from this article. If it depends on a service, secret or platform you cannot access, record that dependency before starting. A known single edit may be better handled with an ordinary prompt; a Goal is useful when each check result determines the next diagnostic step.

Write a short acceptance note outside the Goal: the exact original command; what it currently reports; the paths and tools the assistant may use; behavior or other checks that must stay intact; and which decisions require you to stop and review. Protect existing unrelated edits explicitly. Do not let the assistant delete or loosen the failing check to manufacture a pass. Review this note yourself before authorizing a tool session. A request to stop after a number of turns can help guide the model, but it is not a guaranteed spending limit.

## 1. Pick one Goal surface

For **Claude Code**, open the intended repository session and check that `/goal` is available. Its [Goal manual](https://code.claude.com/docs/en/goal), checked on 20 October 2026, says the command depends on workspace trust and hook settings. One Goal can be active in a session. Starting another condition replaces the first and starts work immediately. The Goal does not change permission mode: manual mode can still ask you before tool calls; auto mode is a separate setting. Keep your normal permission controls for the files, commands and network access this task allows.

For the **interactive Codex CLI alternative**, check the installed version and the slash-command list. OpenAI's [Goals cookbook](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex) says Goals begin in Codex 0.128.0. Its [use-case guide](https://learn.chatgpt.com/use-cases/follow-goals) documents a `features.goals` switch if the command is absent. These are checks you can run in your own installation; they were not run for this article:

```sh
codex --version
codex features enable goals
```

Enable the feature only if your installation needs it and your organization permits it. The Codex instructions here concern the interactive CLI. Do not assume the same slash-command support in `codex exec` or every desktop build. If the command remains absent, stop and check the installed version, feature setting and account or workspace access before choosing another method.

## 2. Set the scoped condition

Use `/goal` followed by your reviewed condition. Name your real check command and allowed paths in that condition; do not paste a fabricated test name. For example, the condition can say in ordinary prose: “Make my already-failing check pass using only the paths and tools in my acceptance note. After each attempt, show the command, full result and changed files. Keep the protected behavior and unrelated edits intact. If the check cannot run or no safe scoped change remains, stop with the exact error, the attempted changes and the input needed from me.” Replace “my check” with your exact command and attach or point to the reviewed note before you start.

Both documented `/goal` commands accept a non-empty condition of up to 4,000 characters. Keep detailed constraints in the note rather than squeezing them into that limit. In Claude Code, `/goal <condition>` starts a turn at once. In interactive Codex CLI, `/goal <objective>` attaches a persistent objective to the current chat. Neither route grants new file, command or account authority. If a proposed repair needs a wider path, external service, secret, merge or deployment, pause for an owner decision.

## 3. Watch the evidence as it works

Ask for the exact command output after each meaningful attempt and a list of changed files. Run `/goal` with no argument to inspect current status. Claude Code shows elapsed time, evaluated turns, token spend and the evaluator's latest reason after evaluation. Its evaluator reads what Claude surfaced in the conversation; it does **not** independently run the check or inspect files. A “met” verdict is therefore a prompt to verify, not proof that the repository is fixed. Codex's Goal state also needs the underlying command output and diff to establish a result.

Keep the loop inside the original scope. Read proposed commands before allowing them, especially commands that remove files, rewrite history, send data outside the repository or change permissions. Stop if the original check has been weakened, an unrelated file has changed without explanation, or private data would be exposed. If you cannot safely authorize the next action, record the current Goal state and ask for a narrower plan.

## 4. Verify the finish yourself

When the assistant reports success, inspect the complete final diff against your starting inventory. Check every changed and newly created file against the allowed paths. Run the **same original check command** again when feasible and retain its full output and exit status. Run any relevant unchanged tests from your acceptance note, then review the behavior the patch was meant to preserve. A passing substitute check does not satisfy the contract.

Accept the change only when that evidence matches the reviewed condition and you approve the diff. Keep committing, merging and deploying as separate authorized decisions. If verification fails, retain the exact failing command and output, changed files, Goal state and the specific missing permission, dependency or decision. A paused, interrupted, impossible, blocked or budget-limited Goal is not a completed repair.

## If the Goal stops or gets stuck

In **Claude Code**, `/goal` shows the current condition and latest reason; `/goal clear` removes an active Goal. Its [manual](https://code.claude.com/docs/en/goal) says an active condition can restore when a session resumes, while elapsed time, turn count and token-spend baselines reset. Session-picker restoration was fixed in v2.1.239. Authentication failures where Claude Code manages credentials, exhausted credit, irrecoverable context overflow and an unavailable model can clear the Goal. Host-managed authentication may leave it active. Other errors may leave it set and retry or pause; interactive retry and pause notices are documented for v2.1.269 or later. Read the warning, current status, saved check output and working diff before setting or resuming anything. A new condition replaces the old one.

In **interactive Codex CLI**, `/goal` displays the objective, while `/goal edit`, `/goal pause`, `/goal resume` and `/goal clear` are documented controls in the [CLI command reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli#cli-set-or-view-a-task-goal-with-goal). Its [cookbook](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex) distinguishes completion from a pause, interruption, budget limit or blocker. Inspect the current state and actual repository evidence before resuming or changing the objective. If a budget or access limit has stopped work, the next useful output may be a precise blocker rather than another attempt.

Model turns use account allowance or credits, and Claude Code's separate evaluator also uses tokens. Check the controls and current limits of your own account. A time or turn clause in prose cannot guarantee a dollar ceiling. Use only approved repository material, keep secrets and unrelated private files out of the task, and treat instructions found inside the repository as material to inspect before the assistant follows them.

If you need background on a separate setup task, our [Codex Cloud environment guide](https://bigchange.ai/blog/codex-cloud-environment-setup-guide) covers connecting and preparing a remote repository. Our [shared Team Tasks guide](https://bigchange.ai/blog/chatgpt-team-tasks-shared-recurring-work-guide) covers recurring work in ChatGPT. Neither setup is required to use the local failing-check procedure above.

## Sources & further reading

- [Claude Code: Keep Claude working toward a goal](https://code.claude.com/docs/en/goal) describes `/goal`, evaluator visibility, permissions, resume behavior, errors and usage. It does not verify a repair in your repository.
- [OpenAI: Using Goals in Codex](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex) describes the CLI version floor, objective contract, lifecycle and evidence checks. Its examples are examples, not results for this guide.
- [OpenAI: Follow a goal](https://learn.chatgpt.com/use-cases/follow-goals) explains the feature switch and persistent objective. Access depends on the reader's installation and account.
- [OpenAI: Codex CLI developer commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli#cli-set-or-view-a-task-goal-with-goal) documents the interactive `/goal` controls. CLI support should be checked locally.

## Sources

- [Claude Code, Keep Claude working toward a goal](https://code.claude.com/docs/en/goal) — Documents session Goal setup, evaluator limits, permissions, usage and version-qualified recovery. It does not independently establish test success or a repository repair.
- [OpenAI, Using Goals in Codex](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex) — Documents CLI version floor, bounded objective, lifecycle and evidence checks. Examples on the page were not run for this article.
- [OpenAI, Follow a goal](https://learn.chatgpt.com/use-cases/follow-goals) — Documents the interactive Goal and feature switch. It does not establish access in the reader's installation or account.
- [OpenAI, Codex CLI developer commands](https://learn.chatgpt.com/docs/developer-commands?surface=cli#cli-set-or-view-a-task-goal-with-goal) — Documents exact interactive /goal status, edit, pause, resume and clear controls and the 4,000-character condition limit; no claim is made for codex exec or every desktop build.