Claude Code 2.1.129 team conventions

The situation

Claude Code 2.1.129 is a small release, but it touches the parts teams feel first: shared repo behavior, plugin packaging, and how the tool behaves across terminals and managed installs. If your team uses CLAUDE.md, hooks, MCP connectors, or plugins, check this release before rolling forward.

The main changes are straightforward. You can fetch a plugin .zip from a URL for the current session with --plugin-url. There is also CLAUDE_CODE_FORCE_SYNC_OUTPUT=1 for terminals where auto-detection misses synchronized output, plus CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE for Homebrew and WinGet installs that should upgrade in the background and prompt for restart. These affect day-to-day Claude Code workflow, not just packaging.

For Claude Code teams standardizing conventions in a shared repository, the release also changes plugin manifest guidance, gateway model discovery, history search behavior, and a few review-facing fixes. If you are running a Claude Code workshop or onboarding engineers to Claude Code training, this is a good time to tighten the rules around memory, plugins, and review.

What changed

Start with the operational question: what should your team do differently this week? For most repos, the answer is not to rewrite everything. It is to make the extension and context boundaries explicit.

Review your CLAUDE.md files first. Claude Code treats them as persistent context, not enforced policy, so keep them short and specific. If your repo already has a root memory file, keep only the conventions a new contributor would otherwise re-explain. If you use nested project memory, keep the local file scoped to that subtree.

# CLAUDE.md

- Follow the repo's existing review checklist before opening a PR.
- Prefer small changes with one clear purpose.
- If a task touches integrations, check the MCP permission note before tool use.
- Keep instructions concise; move task-specific details into the prompt.

If your team ships private plugins, update the packaging rules. The changelog says themes and monitors should now be declared under experimental, while top-level declarations still work but will trigger claude plugin validate warnings. Treat that warning as a packaging debt item, not a cosmetic note. If you distribute plugins internally, make validation part of the release checklist.

# SKILL.md
---
name: repo-review
description: Review Claude-authored changes for repo rules, MCP scope, and release safety before merge.
---

Use this skill when a Claude-generated change touches shared repo conventions, integrations, or release-sensitive files.

If your terminals show garbled or delayed output, CLAUDE_CODE_FORCE_SYNC_OUTPUT=1 is the compatibility fix to try. The release notes call out auto-detection misses, including Emacs eat. Use it where needed and document why. Do not turn it on everywhere by default.

Check install policy too. CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE lets managed installs upgrade in the background and ask for a restart. That can reduce version drift, but it also means the tool may change during a session. If your team depends on stable review or workshop environments, pair auto-update with a restart expectation and a version check in onboarding docs.

The gateway discovery change is another boundary worth calling out. Discovery now opts in with CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1. For teams using third-party deployments, that is a reminder to keep discovery and permissions explicit instead of assuming first-party defaults.

A practical review checklist helps:

• Confirm CLAUDE.md is concise and scoped to the repo or subtree.
• Run claude plugin validate on any plugin package you ship.
• Check whether experimental declarations are in the right place.
• Decide whether CLAUDE_CODE_FORCE_SYNC_OUTPUT=1 is needed for your terminal.
• Verify whether background auto-update fits your release cadence.
• Review MCP permissions before enabling new connectors.
• Test /rename, /clear, and history search in the workflows your team actually uses.

What teams should try

Use this release to tighten team conventions, not just update the binary. The useful habit is to make repo rules easier to inspect.

A good starting point is to review /topics/team-conventions alongside your CLAUDE.md files and plugin packaging rules. If you run a Claude Code workshop, use one repo and one checklist so people can see where memory ends, where hooks start, and where MCP permissions need review.

For teams adopting Claude Code for teams or Claude Code enterprise setups, the pattern is the same: keep shared context small, validate plugin changes, and document any terminal or install flags that affect behavior. That gives you a cleaner Claude Code workflow and fewer surprises during review.

Tradeoffs and limits

The tradeoff is between convenience and control. --plugin-url makes it easy to try a plugin in one session, but provenance and review matter more. Treat URL-based plugin loading as a temporary or tightly governed path, not a default distribution channel.

Auto-update is similar. It reduces drift, but it can also introduce timing surprises if a session restarts after an upgrade prompt. If your team values stable workshop machines, pin versions for training environments and use auto-update only where the restart cost is acceptable.

The gateway discovery opt-in is safer for managed environments, but it can change model-picker expectations after upgrade. Call that out in onboarding notes so users do not assume a missing model is a broken install.

The release notes also include fixes that improve day-to-day reliability, but they do not remove the need for review discipline. Claude Code can still produce changes that look plausible and miss repo-specific constraints. The durable habit is to keep the repo rules easy to inspect.

Further reading

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

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.