What Happens When a Gate Fails
Gate failures are a normal part of building. How Claude handles one depends on where it fails: on your machine during the build, or on GitHub after the pull request opens.
Failures during the build
Section titled “Failures during the build”Claude fixes failures found during the build without involving you. It reads the failure details, fixes the code, and runs the check again.
Type errors, lint violations, formatting problems and tests that broke after a code change are all handled this way. The same applies to problems found by the code review at the end of each epic.
Claude makes up to three attempts at each failure. If the third attempt still fails, Claude stops and asks you.
Failures on the pull request
Section titled “Failures on the pull request”After Claude opens the pull request, it waits for the GitHub checks. If one fails, Claude doesn’t try to fix it on its own. The same checks have already passed on your machine, so a failure here usually comes from the environment or configuration rather than the code.
Claude asks what you’d like to do:
| Option | What happens |
|---|---|
| Re-run the failing checks | Claude re-runs them and waits again. Use this for a one-off problem, such as a network timeout. |
| Diagnose locally | Claude shows you the failing output so you can investigate it together. |
| Force merge anyway | Claude moves on to the merge question and records a warning in the epic’s journal. |
When Claude asks for your help
Section titled “When Claude asks for your help”Claude brings a failure to you when:
- Three fix attempts haven’t resolved it
- The failure reveals a conflict in your requirements, such as a security rule that clashes with a feature you asked for
- The fix needs a product decision, not only a technical one
- A serious dependency vulnerability has no fix available yet
Claude explains the problem and the options, then waits for your direction.
Gates are never bypassed silently
Section titled “Gates are never bypassed silently”Claude reports gate results as they are. It never treats a failure as “expected” or “acceptable”, and it never hides an error with a suppression comment such as // eslint-disable or // @ts-ignore.
The only ways past a failing gate are decisions you make, such as a force merge or a dependency exception. Both leave a record your team can review.