Claude Code 2.1.121: MCP guardrails

The situation

Claude Code 2.1.121 is a small release, but a few changes matter in shared repositories. The main one is an alwaysLoad option for MCP server config. When it is enabled, tools from that server are available right away instead of waiting for search-based discovery. That changes how teams think about connector scope, startup behavior, and what should be visible by default in a repo.

The rest of the release points the same way. There are fixes for transient MCP startup errors, a broader PostToolUse hook output path, better skill discovery in long lists, and a few quality-of-life changes around fullscreen terminal use and SDK sessions. For teams using Claude Code as part of a repo convention, these are signals about what to document in CLAUDE.md, what to review in .mcp.json, and what to test before trusting agent-authored work.

If your team already uses team conventions, this release is a reminder that the useful unit is the repo setup, not the model alone. Memory, tools, hooks, and review rules are what make Claude Code predictable in a shared codebase.

What changed

1. Start with the MCP boundary. The new alwaysLoad option makes a server’s tools immediately available instead of waiting for search-based discovery. That is useful for high-frequency connectors, but it also raises the bar for permission review. Treat it as a default-visibility decision, not a convenience toggle.

2. Update the repo instruction layer so the team knows which connectors are expected. A compact CLAUDE.md fragment is usually enough:

# CLAUDE.md

- Prefer repo-local context over chat history.
- Use the GitHub MCP server only for review and issue lookup.
- Do not expand connector scope without a code review.
- If a tool is always loaded, document why it must be available in every session.
- Check hooks and permissions before trusting generated changes.

3. Review .mcp.json with the same discipline you would apply to a dependency file. The question is not only “does this work?” but “should this be always visible?” If a server is used for a narrow task, deferral may be safer. If it is part of the team’s daily workflow, alwaysLoad can reduce friction and make sessions more consistent.

4. Use the new hook behavior to keep output reviewable. PostToolUse hooks can now replace tool output for all tools via hookSpecificOutput.updatedToolOutput, not just MCP tools. That matters when you want to normalize noisy output, redact sensitive fields, or attach a concise summary before the next model step. Keep the boundary simple: hooks should enforce deterministic output, not add hidden logic.

5. Make skills easier to find before you add more of them. The new type-to-filter search in /skills is a small UX change, but it points to a practical habit: keep skill descriptions specific enough that people can find the right one quickly. A weak description becomes a discoverability problem once a repo has more than a handful of skills.

---
name: review-diff
description: Summarize Claude-generated diffs, flag risky files, and list follow-up checks for reviewers.
---

Use this skill when reviewing changes that touch shared repo conventions, MCP config, hooks, or permissions.

6. Add one review checkpoint for the release’s operational changes. A lightweight checklist is enough:

• Does the MCP server need alwaysLoad, or can it stay deferred?
• Are the connector’s permissions documented in the repo?
• Do hooks rewrite output in a way reviewers can still audit?
• Are skills named and described so /skills search is usable?
• If startup errors occur, does the server recover automatically or fail closed?

7. Test the workflow in the same environment your team uses. The release notes mention transient MCP startup retries, fullscreen scroll behavior, and terminal clipboard setup. Those details affect whether people can read output, copy results, and recover from a flaky connector without restarting the whole session. In a shared repo, that is part of reliability.

A useful methodology habit here is Review: before adopting a new connector or hook pattern, verify the repo artifact, the permission boundary, and the expected reviewer check. That keeps the change visible instead of letting it disappear into “Claude just works.” See our methodology.

Tradeoffs and limits

alwaysLoad is useful when a connector is central to the team’s work, but it can also increase blast radius. If a server exposes too many tools, always loading it makes those tools easier to reach than they should be. For sensitive systems, keep the scope narrow and prefer explicit documentation over convenience.

Hook output replacement is powerful, but it can hide context if teams use it too aggressively. If a hook rewrites tool output, reviewers still need a way to inspect the original result when something looks off. The safer pattern is to summarize or normalize, not to erase.

Skill search improves usability, but it does not fix poor skill design. If descriptions are vague, the search box only helps people scroll faster through bad metadata. The same applies to CLAUDE.md: concise instructions work better than long policy dumps.

MCP retries reduce friction, but they do not remove the need for observability. A connector that reconnects automatically can still be misconfigured, over-permissioned, or pointed at the wrong upstream. Teams should keep a habit of checking startup logs, permission scopes, and the exact repo files that define the integration.

Further reading

• Claude Code overview
• How Claude remembers your project
• Hooks reference
• Connect Claude Code to tools via MCP
• Claude Code changelog
• Claude Code team conventions