Claude Code 2.1.126 team conventions

The situation

Claude Code 2.1.126 changes how shared repos should handle state, permissions, and review boundaries. The changelog covers model selection, project cleanup, login recovery, shell detection, hooks telemetry, and security fixes that matter when Claude is used in real repositories.

For teams using Claude Code team conventions, the main question is what the repo should teach Claude and what the tool should enforce on its own. That sits in CLAUDE.md, hooks, MCP, and review expectations.

This matters most for engineering teams that want Claude to behave consistently across a shared codebase. If you run a monorepo, work in a regulated environment, or rely on strict file ownership, this release is worth a workflow check.

What changed

Start with the repo memory layer. Claude Code docs still treat CLAUDE.md as the place for durable instructions, while auto memory captures learnings and preferences. Keep the file short and specific: architecture rules, test commands, review expectations, and paths that should not be edited casually.

# CLAUDE.md

- Prefer small, reviewable changes.
- Run the project test command before asking for review.
- Do not edit generated files unless the task explicitly says so.
- Ask before changing deployment or auth config.
- Keep repo-specific conventions here; keep task prompts short.

The changelog adds claude project purge [path] to delete Claude Code state for a project, including transcripts, tasks, file history, and config entries. Use it when a repo has stale state or before onboarding a new team member. Treat it as maintenance, not routine cleanup. Use --dry-run first, and reserve --all for cases where you really intend to remove everything.

If your team uses --dangerously-skip-permissions for automation, revisit the boundary. This release expands what it can bypass, including writes to .claude/, .git/, .vscode/, shell config files, and other previously protected paths. That means your review process has to assume Claude can touch more of the repo than before. Narrow the task scope and review diffs more closely.

claude auth login now accepts an OAuth code pasted into the terminal when the browser callback cannot reach localhost. That helps with WSL2, SSH, and containers. It does not change the security model, but it does reduce onboarding friction in constrained environments.

The new claude_code.skill_activated OpenTelemetry event now fires for user-typed slash commands and includes an invocation_trigger value such as user-slash, claude-proactive, or nested-skill. If you use hooks for lifecycle checks, this gives you a cleaner signal for how teams invoke Claude. A useful habit here is to separate user-initiated actions from agent-initiated ones in logs and review notes.

The changelog also says host-managed deployments no longer auto-disable analytics on Bedrock, Vertex, or Foundry. It fixes a managed-settings bug where allowManagedDomainsOnly and allowManagedReadPathsOnly could be ignored if a higher-priority source lacked a sandbox block. Those are policy changes, so they should trigger a review, not just a version bump.

A small hook boundary makes that visible:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "command": "./scripts/check-repo-policy.sh"
      }
    ]
  }
}

The model picker now lists models from the gateway’s /v1/models endpoint when ANTHROPIC_BASE_URL points at an Anthropic-compatible gateway. Teams using a proxy or managed gateway should check that the visible model list matches policy, not just availability. The picker now reflects the gateway inventory, so the allowed-model list should be intentional.

What teams should try

Make one review habit explicit this week: if Claude changes repo memory, permissions, or deployment-adjacent files, the reviewer should check the diff against the team’s written conventions before checking the code itself.

A practical starter checklist:

• Confirm CLAUDE.md is concise and scoped to durable repo rules.
• Decide whether claude project purge belongs in your support runbook.
• Review any use of --dangerously-skip-permissions.
• Verify hook logging for slash commands and skill activation.
• Re-check managed settings and sandbox assumptions after the security fixes.
• Test login from your least convenient environment: WSL2, SSH, or container.

What the workflow implies

The release is useful, but flexibility is not the same as safety. The broader permission bypass can normalize risky workflows if the team does not keep a tight review loop. The project purge command is also easy to misuse if people treat Claude state as disposable without understanding what transcripts and file history are being removed.

The model-picker change is helpful, but it can hide policy drift if your gateway exposes more models than the team intended to allow. The login fallback helps remote environments, but it does not remove the need for secure device and session handling.

The main limit is organizational: Claude Code works best when the repo has a clear memory file, a small set of hooks, and a review process that knows which files are authoritative. Without that, each release adds more surface area to manage.

A useful methodology note: in the Review step, treat agent-authored changes to memory, hooks, and permissions as policy changes, not just code changes. That keeps the review focused on the repo contract.

Further reading

• Claude Code overview
• How Claude remembers your project
• Hooks reference
• Connect Claude Code to tools via MCP
• Claude Code changelog
• Anthropic Skills on GitHub
• Support center
• Team conventions topic