Claude Code 2.1.128 team conventions

The situation

Claude Code 2.1.128 is a small release, but it touches the parts teams feel every day: MCP visibility, plugin packaging, session behavior, shell environment leakage, and a few workflow rough edges. For Claude Code teams, that matters more than a feature count. These are the seams where shared repository context, review expectations, and automation either stay predictable or drift.

If your team already uses CLAUDE.md, hooks, skills, or MCP servers, read this release as a conventions update, not just a changelog. It changes how you notice connected tools, how you package extensions, and how much hidden environment state subprocesses inherit. That is the kind of detail that affects Claude Code training, workshop exercises, and team adoption patterns.

The practical question is simple: what should a team change this week so agent-authored work stays reviewable? Usually not “turn on everything.” It is “tighten the repo artifacts, check the connector boundary, and make the defaults visible.” This release gives a few concrete prompts for that work, and it fits the broader Claude Code team conventions pattern.

Walkthrough

1. Start with the repository memory layer. Claude Code already treats CLAUDE.md as always-on context, so use this release as a reminder to keep it short, local, and durable. If your team has been stuffing one root file with every exception, split the rules by scope and keep the shared conventions in the smallest file that still works.

# CLAUDE.md

- Prefer small, reviewable changes.
- Check `AGENTS.md` in nested directories before editing.
- Ask before expanding MCP scope or adding new connectors.
- Keep generated code aligned with existing formatting and test commands.

2. Review your MCP inventory. In 2.1.128, /mcp now shows tool counts for connected servers and flags servers that connected with zero tools. That is useful because a “connected” server is not the same as a useful server. Teams should treat zero-tool connections as a setup smell: either the server is misconfigured, or the integration is not actually contributing value.

3. Revisit plugin packaging. --plugin-dir now accepts .zip archives as well as directories. That makes distribution easier, but it also raises the bar for review. A zip is still code and config, just packaged differently. If your team installs private plugins, add a check that the archive contents are inspected before rollout, and that the plugin still maps cleanly to the same skills, hooks, and MCP servers you would expect from an unpacked directory.

4. Check shell and subprocess boundaries. This release stops Bash, hooks, MCP, and LSP subprocesses from inheriting OTEL_* variables. That is a good default for isolation, especially when the CLI itself is instrumented. It also means teams should not assume observability settings automatically flow into every tool call. If you depend on telemetry in child processes, verify the child process configuration explicitly instead of inheriting it by accident.

5. Update your team’s review checklist for branch creation and worktrees. EnterWorktree now creates the new branch from local HEAD, not origin/, which avoids dropping unpushed commits. That is the kind of fix that should become a habit check: when a workflow creates a branch or worktree, confirm the source is the local state you intend to preserve.

6. Use the release to sharpen one methodology habit: Review. Before you trust agent-authored changes, verify the connector boundary, the memory file scope, and the branch source. That is a small review step, but it prevents the most expensive class of mistakes: silent drift in shared conventions.

A practical MCP permission note for teams:

MCP review note
- Confirm the server name is not reserved.
- Confirm the server exposes non-zero tools.
- Confirm the scope is local/project/user as intended.
- Confirm the connector is needed for the current repo.
- Confirm the team knows how to disable it if behavior changes.

7. Keep one lightweight adoption checklist in the repo so new contributors can follow the same path. This release also improves error hints in auto mode when the classifier cannot evaluate an action, which is a reminder that teams should document the fallback path: retry, compact, or run with --debug. That belongs in the same place you keep your review rules, not in a chat transcript.

Tradeoffs and limits

This release does not remove the need for governance; it makes the boundaries easier to see. A visible tool count is helpful, but it does not prove the tool is safe. A .zip plugin is convenient, but it can hide complexity unless your team reviews the contents. A reserved MCP server name prevents one class of collision, but it also means existing setups may need cleanup.

The OTEL_* change is especially worth testing in real workflows. Isolation is usually good, but teams that rely on inherited telemetry or shell-side tracing should confirm their observability still works in Bash, hooks, and MCP subprocesses. Likewise, the worktree fix is safer than the old behavior, but any branch-creation workflow should still be verified against your repo policy before it becomes standard practice.

Finally, do not confuse product updates with process maturity. Claude Code memory, skills, hooks, and MCP are only useful when the team can review them. If the repo does not clearly say where instructions live, who can add connectors, and how to validate generated changes, the tooling will still feel inconsistent.

Further reading

• Claude Code changelog: https://docs.anthropic.com/en/docs/claude-code/changelog
• Claude Code overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Claude Code memory and CLAUDE.md: https://docs.anthropic.com/en/docs/claude-code/memory
• Claude Code hooks reference: https://docs.anthropic.com/en/docs/claude-code/hooks
• Claude Code MCP guide: https://docs.anthropic.com/en/docs/claude-code/mcp
• Our methodology: /methodology

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.