Claude Code 2.1.136: Team convention fixes

The situation

Counter-thesis: the most useful Claude Code release notes are often the ones that protect team workflow from drifting.

The wrong path: I believed changelogs were mostly feature lists. I tried to fix team problems with one more integration, one more prompt, one more rule. Here is what happened: sessions lost context, connectors disappeared after a reset, and review habits depended on luck.

Diagnosis: this is configuration drift, with a few race-condition failures mixed in. The official docs already point to the shape of the answer: Claude Code treats CLAUDE.md, auto memory, hooks, and MCP as separate surfaces, not one shared memory blob.

The actual thesis: Claude Code team conventions work when the boundary is explicit, and 2.1.136 is mostly a boundary release.

The changelog fixes several leaks at once: MCP servers disappearing after /clear, OAuth refresh tokens being lost when multiple servers refresh at the same time, a rare login loop during concurrent credential writes, plan mode allowing writes when it should not, and plugin hooks failing when cache cleanup removed a version still in use. Those are not separate stories. They are signs that shared repo context needs durable edges.

Walkthrough

MCP servers that vanish after /clear — if you have shipped Claude Code into a real repo, you have probably seen a session reset erase something that should have survived. The failure mode is not “MCP is unreliable”; it is that the connector boundary was too implicit. The fix is the Connector Persistence Check: keep .mcp.json, plugin-provided servers, and connector review in the same change set, then verify they survive a session clear in the surfaces you actually use. That is the kind of habit covered in a Claude Code workshop or Claude Code training session, and it belongs in the team’s review checklist. See team conventions. That is tip one.

OAuth refreshes that collide — if you run several remote MCP servers, concurrent refresh can turn into daily re-authentication. The failure mode is a race, not a permission philosophy problem. The fix is the Refresh Ownership Rule: document which server owns which credential path, and test concurrent refresh under the exact multi-server shape you deploy. That is the kind of rule a Claude Code team should write down once instead of rediscovering in incident threads. That is tip two.

Plan mode that still writes — if a matching Edit(...) allow rule exists, plan mode should not become a back door for file writes. The failure mode is confusing intent with enforcement. The fix is the Plan-Mode Write Fence: write the rule once, then review it as a policy boundary, not a convenience setting.

# CLAUDE.md fragment: plan-mode fence

- Plan mode is for analysis and proposal only.
- A matching Edit(...) allow rule does not authorize writes in plan mode.
- If a task needs writes, switch modes explicitly and review the diff.
- Treat file-write permission as a separate decision from tool availability.

After that, reviewers can ask a simple question: did the agent propose, or did it mutate? That is tip three.

Hooks that die during cache cleanup — if a running session depends on a plugin hook version, cleanup can become a production outage. The failure mode is assuming hooks are just scripts instead of lifecycle infrastructure. The fix is the Hook Version Guard: pin hook behavior, test Stop and UserPromptSubmit paths, and treat cache cleanup as a compatibility event. That is a useful boundary for Claude Code enterprise setups and for Claude Code for teams. That is tip four.

Memory that is too broad to trust — if your CLAUDE.md tries to hold every rule, it stops being memory and becomes noise. The failure mode is overfitting one file to every team concern. The fix is the Scoped Memory Split: keep durable repo rules in CLAUDE.md, move local exceptions into nested files or scoped rules, and use the docs’ distinction between persistent instructions and auto memory. That is the core of Claude Code memory hygiene, and it makes Claude Code conventions easier to teach. That is tip five.

Synthesis: the rule I repeat in Slack is simple: if the boundary is not written down, the agent will invent one. In Claude Code teams, the thesis holds because the boundary is the product.

One practical review habit follows from this release: before you trust an agent-authored change, check whether the repo has a visible boundary for memory, connectors, hooks, and write permissions. If not, the bug is often the missing convention.

Tradeoffs and limits

This release does not remove the need for human review. It reduces a few failure classes, but teams still need to verify connector scope, permission boundaries, and whether a hook or memory rule is actually the right abstraction.

The other limit is that MCP stability is only as good as the server and auth topology you choose. If your team runs many remote servers, you still need to test concurrency, recovery, and re-auth flows in your own environment.

A small methodology note: in the Review step, I would treat 2.1.136 as a prompt to re-check the boundary artifacts, not just the code diff. See our methodology.

Further reading

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

Where to go next

If your team uses Claude Code in a shared repo, start with a short review checklist and map it to your workshop or training flow. Use team conventions as the shared reference, then tighten CLAUDE.md, MCP scope, plan-mode rules, and hook versioning in one pass.