Claude Code 2.1.140: team conventions

The situation

Counter-thesis: the most useful Claude Code release notes are the ones that make team conventions hold up.

I believed the hard part was prompt quality. I tried to force consistency through chat alone, and here is what happened: the same repo rule got re-explained, hooks misfired, and review expectations drifted because the operating model lived in people’s heads instead of files.

Diagnosis: this is configuration drift, the old pattern where the system looks governed but behavior depends on memory. Claude Code’s docs point to the fix in plain terms: persistent instructions belong in CLAUDE.md, deterministic boundaries belong in hooks, and external tools belong behind MCP. The 2026-05-12 release matters because it removes several small failures that make those conventions brittle.

Thesis: Claude Code team conventions work when the repo, the hook boundary, and the review path are explicit, scoped, and boring.

Walkthrough

1) The silent failure that looks like a timeout — if you shipped AI code you have hit this: a command appears to hang, and everyone blames the model. In this release, /goal no longer hangs silently when disableAllHooks or allowManagedHooksOnly is set; it now shows a clear message instead of an indicator that never resolves. The fix is Boundary Visibility: if a hook policy blocks progress, surface the policy, not a spinner. After that, teams stop retrying the wrong layer and start checking the hook boundary first. That is tip one.

2) The repo rule that changes but never lands — if you use symlinked settings, you have probably seen spurious change events and wondered why Claude keeps reacting to the wrong file. The changelog says hot-reload misattributed symlinked settings changes and triggered false ConfigChange hooks. The fix is Single Source Memory: keep shared settings and repo-local settings unambiguous, and prefer scoped files over clever indirection. In practice, that means your CLAUDE.md and related memory files should be the obvious place for durable rules, not a maze of links. That is tip two.

3) The background service that dies at the worst moment — if you run claude --bg, a dropped connection or an enterprise security delay can look like random instability. This release fixes background service startup on enterprise endpoint security machines by allowing more time, and it fixes claude --bg failing with “connection dropped mid-request” when the service was about to idle-exit. The fix is Lifecycle Discipline: treat background agents and services as lifecycle systems, not instant commands. Fewer false failures means fewer manual restarts and fewer “works on my machine” debates. That is tip three.

4) The hook that fires too often to be useful — if you rely on hooks for governance, redundant wakeups are not a small bug; they are a trust problem. The release fixes /loop scheduling extra wakeups for background tasks that already notify on completion, and it fixes a Windows event-loop stall when a missing executable caused synchronous where.exe respawns on every check. The fix is Signal over Polling: use hooks and notifications as the primary signal, and reserve polling for fallback. Here is the practical shape I would put in a team convention file:

# CLAUDE.md fragment

## Team conventions
- Keep durable repo rules in this file or a scoped nested memory file.
- Use hooks for deterministic checks only: permissions, formatting, validation, and logging.
- If a hook blocks progress, it must explain why in one sentence.
- Reviewers should verify that background tasks complete by notification, not by repeated polling.

After that change, the team spends less time chasing phantom loops and more time reviewing actual diffs. That is tip four.

5) The integration that fails only for one team — if you use MCP, plugins, or managed settings, the failure mode is usually not “broken,” it is “almost working.” This release fixes remote managed settings not retrying on 401, fixes extraKnownMarketplaces auto-update policy persistence, and adds a warning when a plugin’s default component folder is silently ignored because plugin.json sets the matching key. The fix is Explicit Precedence: when one file overrides another, the tool should tell you. That matters because Claude Code teams need reviewable setup, not hidden precedence. That is tip five.

Synthesis: if a team convention matters, make it visible in a file, enforceable at a boundary, and reviewable in a diff.

Tradeoffs and limits

These fixes do not make Claude Code magical; they make it legible. CLAUDE.md is still context, not hard enforcement, and hooks can still be misconfigured if teams treat them as decoration instead of infrastructure. MCP and plugins also widen the review surface, so least privilege and explicit ownership matter more, not less.

One practical methodology note: in the Review step, check whether each convention has a file, a boundary, and a reviewer. If it does not, it is not yet a convention. See our methodology and the team-conventions cluster at /topics/team-conventions.

Further reading

• https://code.claude.com/docs/en/changelog
• https://code.claude.com/docs/en/memory
• https://code.claude.com/docs/en/hooks
• https://code.claude.com/docs/en/mcp
• https://code.claude.com/docs/en/overview
• /topics/team-conventions

Where to go next

If you are standardizing Claude Code for a team, start with /topics/team-conventions. Then tighten CLAUDE.md, add one hook boundary, and make one review checklist part of the workshop flow.