Claude Code 2.1.120 for shared repos

The situation

Claude Code 2.1.120 is a changelog release, but the useful part is how it changes team habits in shared repositories. The update touches Windows shell behavior, non-interactive review, skills, subprocess attribution, terminal ergonomics, MCP stability, and a few permission and telemetry edge cases.

That maps directly to team conventions: what belongs in CLAUDE.md, what should be a skill, what should be a hook, and what needs review before anyone trusts agent-authored work. If your team already uses Claude Code in a repo with shared memory and connector access, this release is a good time to tighten the operating model instead of treating it as a routine upgrade.

The official docs already frame Claude Code around persistent instructions, memory, hooks, MCP, and reviewable workflows. This release adds a few practical nudges to that model: less setup friction on Windows, better non-interactive review from CI, and fewer surprises when tools, permissions, or terminal state get in the way.

For teams working through team conventions, the main question is not “what’s new?” It is “what should we standardize now that these behaviors are more reliable?”

Walkthrough

Start with the repo memory you already control. Claude Code’s memory docs separate durable instructions in CLAUDE.md from learned notes in auto memory. That matters here because 2.1.120 improves the surrounding workflow, but it does not replace explicit repository rules. Keep CLAUDE.md short, scoped, and reviewable.

---
description: Shared repo conventions for Claude Code
---

# CLAUDE.md

- Prefer small, reviewable diffs.
- Check existing patterns before adding new abstractions.
- Ask before changing deployment or auth flows.
- Use the repo’s test command before proposing a fix.

Move repeatable checks into skills or hooks, not chat prompts. The changelog adds ${CLAUDE_EFFORT} for skills, which is a reminder that skills should be reusable operating instructions, not one-off notes. If a team keeps repeating the same review checklist, encode it as a skill description or a hook boundary instead of relying on memory.

Use the new non-interactive claude ultrareview [target] path when you need review findings in CI or scripts. The changelog says it prints findings to stdout, supports --json, and exits 0 on completion or 1 on failure. That makes it a better fit for automation than a terminal-only review session. The practical habit is simple: treat it as a machine-readable review step, then keep the human review focused on judgment calls.

Tighten MCP boundaries after the Esc fix. 2.1.120 fixes a regression where pressing Esc during a stdio MCP tool call could close the whole server connection. That is a stability fix, but it also points to a governance habit: every connector should have a permission note, a scope review, and a fallback plan if the tool disconnects mid-task. Claude’s MCP docs already emphasize installation scopes and dynamic tool updates; teams should add least-privilege review to that setup.

Update Windows guidance if you support native Windows users. Git for Windows is no longer required; when it is absent, Claude Code uses PowerShell as the shell tool. That reduces setup friction, but it also means your repo instructions should not assume Bash-only behavior. If your team documents shell commands in CLAUDE.md, keep them portable or call out the shell explicitly.

Revisit review ergonomics in the terminal. This release fixes /rewind and other overlays after claude --resume, scrollback duplication in non-fullscreen mode, and long selection menus clipping in fullscreen mode. Those are small fixes, but they matter because review quality drops fast when the interface gets in the way. If your team depends on interactive review, test the exact flows you use most: resume, rewind, scroll, and dismiss dialogs.

A practical starter checklist:

• Keep CLAUDE.md focused on repo rules, not task prompts.
• Put recurring review criteria into a skill or checklist.
• Use claude ultrareview in CI only for machine-readable checks.
• Review every MCP connector for scope, failure mode, and permission boundaries.
• Verify Windows shell assumptions in repo docs.
• Test resume, rewind, and scroll behavior before rolling the update out broadly.

A small review artifact helps make this concrete:

## Claude-authored PR review
- Does the diff match existing repo patterns?
- Are tests or validation steps included?
- Did any MCP connector expand access beyond the task?
- Is the change safe to run on Windows and POSIX shells?
- Are permission prompts or telemetry settings behaving as expected?

Methodology note: this is a Review step, not a feature tour. The useful move is to turn changelog items into a repo check that someone can actually run before merging.

Tradeoffs and limits

The biggest limit in this release is that it improves reliability more than policy. The telemetry fix, for example, addresses a suppression bug for API and enterprise users, but it does not remove the need to decide what your team considers acceptable data flow. Likewise, the new auto-mode denial message linking to configuration docs helps users recover faster, but it does not replace a written permission policy.

claude ultrareview is also not a substitute for human review. It can surface findings non-interactively, but it cannot decide whether a change fits architecture, product intent, or release risk. Use it as a gate or signal, not as the final approver.

Skills and hooks can become clutter if teams over-encode every exception. If a rule changes weekly, keep it in a review checklist or temporary note rather than hard-coding it into a permanent skill. The same applies to MCP: broader connector access can speed work, but every new integration increases the surface area for permission drift and failure handling.

Finally, Windows shell fallback is helpful, but it can hide portability problems if your repo docs were written only for Bash. Teams should test the commands they expect Claude to run, not assume the shell layer will normalize everything.

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
• https://docs.anthropic.com/en/docs/claude-code/skills
• https://docs.anthropic.com/en/docs/claude-code/commands

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.