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:

Terminal
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, 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 says Goals begin in Codex 0.128.0. Its use-case guide 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:

Terminal
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 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. Its cookbook 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 covers connecting and preparing a remote repository. Our shared Team Tasks guide covers recurring work in ChatGPT. Neither setup is required to use the local failing-check procedure above.

Sources & further reading