claude_code_stop_hook_block_cap in Claude Code 2.1.143
If a run stops and the changelog mentions claude_code_stop_hook_block_cap, treat it as a convention to write down, not a setting to silently flip. A team convention is a rule that lives in a file your reviewers read, like CLAUDE.md, a hook, or a permission list, so the same behavior holds whether you are on Claude Code 2.1.143 or the next patch. Claude Code is most trustworthy when those rules are explicit. The durable fix is the convention, and each hook should document its own rollback path.
Most people who hit this are chasing a version number: 2.1.143 release notes, what changed, who approved it. The better question is which rule governed the agent when it stopped, because that rule is the thing you can fix once and keep.
Pin the hook change as a convention, not a tweak
A hook is a small script Claude Code runs at a defined moment, like before a bash command or when a session stops. When a hook starts blocking runs, the temptation is to loosen it until the queue moves again. Resist that. Loosening a hook in the moment quietly changes who is allowed to approve risky work, and nobody signed off on the change.
Instead, make CLAUDE.md the place where precedence lives. Hooks win over a verbal agreement in chat, and that fact belongs in the file so a version bump never rewrites it for you.
# CLAUDE.md: precedence and rollback
- Hooks win over informal chat agreements. Document each hook's rollback path here.
- Skills defer to this file on security-sensitive folders.
- Bash approvals never bypass the red-folder list maintained below.
When claude_code_stop_hook_block_cap shows up, you add one line about what the cap protects and how to roll it back. The next person reads the decision instead of guessing at it.
Four conventions that outlast version bumps
These four rules cover the places agent work tends to drift. Each one moves a decision out of chat and into a file.
| Problem | Convention | What it fixes |
|---|---|---|
| Approvals become reflexive | Red-folder ritual | Risky paths get a separate reviewer, never an auto-approve |
| Context leaves the laptop | Data-class tags | MCP connectors carry data class and retention notes |
| Knowledge lives only in transcripts | Weekly retro note | One .md line per decision agents relied on |
| Skills proliferate quietly | Skill index | A skills/README.md mapping each skill to its trigger |
The red-folder ritual is the one most teams need first. List the paths that always require a human reviewer, keep that list in CLAUDE.md, and never auto-approve them. The permissions docs cover the mechanics of how approvals and allow lists work.
The weekly retro note is the cheapest insurance. A single header like 2.1.143: hook cap decisions answers next quarter's archaeology in one line, so a new teammate inherits your reasoning instead of a rumor.
Make the PR carry its own receipts
A review is only as good as what the PR shows. Ask for proof, not narration: paste the command output, name the scopes, say who acknowledged the risky paths. This maps to the Review step in our methodology, where evidence beats a description from memory.
Here is a checklist you can paste into a PR template:
- Verification command output is pasted or linked, not summarized.
- MCP connectors used (if any) list their owners.
- Red-folder paths show explicit human acknowledgement.
- Forked or background agent work names parent and child responsibilities.
- The PR body lists which
CLAUDE.md,SKILL.md, or hook governed the run.
None of this replaces architecture judgement. Agents speed up execution; ownership of the change stays with you.
Start with one rule
Pick the red-folder ritual, write the path list into your CLAUDE.md today, and let the rest follow. The full convention cluster lives at Claude Code team conventions when you want the next one.