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, Anthropic's coding agent, 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.

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.

Common questions

• How should teams handle claude_code_stop_hook_block_cap and other 2.1.143 hook changes?

  Treat any 2.1.143 hook change as a convention update, not a one-off setting tweak. Hooks win over informal chat agreements, and each hook documents a rollback path in CLAUDE.md. Pinning that precedence in the file means a version bump never silently changes who is allowed to approve risky bash, which is the whole point of writing it down.

• What do Claude Code 2.1.143 team conventions actually cover?

  They cover four rules: a red-folder ritual for paths that never auto-approve, data-class tags on MCP connectors, a weekly retro note, and a skill index in skills/README.md. Each one exists because the expensive bug is permission drift nobody signed, not the quality of the tool. The conventions move those decisions out of chat and into files reviewers can read.

• What is the red-folder ritual in Claude Code?

  The red-folder ritual is a list of repository paths that always require a separate reviewer and are never auto-approved. It exists because approvals turn reflexive over time and risky bash slips through. Keeping the list in CLAUDE.md rather than in chat gives sensitive edits deliberate human eyes every time, no matter who is on call.

• What belongs in a Claude Code PR before review?

  The PR body should list scopes plus a verification transcript, with command output pasted or linked instead of described. Add three more receipts: MCP connectors list their owners, forked agent work names parent and child responsibilities, and red-folder paths show explicit acknowledgement. A reviewer can then check the work without replaying the session.

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.

Further reading

• Model Context Protocol specification
• Anthropic Claude Code product page
• anthropics/skills on GitHub
• Claude Code getting started
• Claude Code skills