Claude Code 2.1.137 fixes Windows activation

The situation

The latest Claude Code changelog is small, but it matters operationally: the VS Code extension no longer fails to activate on Windows. For Claude Code teams, that affects the first step in the workflow. If the extension does not start, shared repo context, review habits, and team conventions never get a chance to help.

This is worth covering in a Claude Code workshop because it changes where the tool is usable, not how the model works. If your team relies on Claude Code in VS Code, Windows activation is part of onboarding, support, and day-to-day use.

The useful question is what to verify now that activation is more reliable. That points to repository memory, scoped instructions, and review expectations. If you are building Claude Code team conventions, this release is a reminder that adoption often breaks at the edges: setup, extension load order, and unclear local policy.

What changed and what to check

1. Treat the changelog as a release gate. If your team uses Claude Code in VS Code on Windows, confirm that the extension activates in a clean workspace and in one real repository. If you have an onboarding path, add this check before people depend on Claude Code for daily edits.

2. Check repository memory. Claude Code’s docs separate persistent instructions in CLAUDE.md from auto memory. Teams should know which rules are always on, which are project-scoped, and which come from corrections. A simple project fragment looks like this:

---
description: Team rules for this repository
---

# CLAUDE.md

- Follow the existing folder structure before proposing new abstractions.
- Ask before changing deployment scripts or CI settings.
- Prefer small diffs and explain any cross-file edits in the PR summary.

3. Add a review checklist for agent-authored work. The fix does not change review standards, but it will likely increase use of Claude Code from the IDE. Reviewers should check whether the assistant followed CLAUDE.md, respected local conventions, and kept the change small enough to review quickly.

4. Keep hooks deterministic. Hooks run outside the model loop and fit lifecycle checks, logging, formatting, or permission boundaries. In a Windows-first VS Code setup, decide whether a hook should block unsafe actions or only record them. Start with a narrow boundary and expand only after behavior is stable.

5. Review MCP scope before rollout. The changelog item does not change MCP itself, but extension activation is often where missing permissions or incomplete setup show up first. Check whether the connector is project-scoped, user-scoped, or local, and make sure the team knows which tools are available in each repository.

A short review checklist keeps this practical:

• Does Claude Code activate in VS Code on Windows in a fresh session?
• Is the repository’s CLAUDE.md short, specific, and current?
• Are hooks used for deterministic checks, not hidden policy?
• Are MCP connectors scoped to the minimum needed access?
• Can reviewers tell what Claude changed and why?

One useful methodology step here is Review: before broad rollout, verify that the tool starts, the instructions load, and the output is reviewable. See our methodology for how we frame that step.

Tradeoffs and limits

This fix does not remove the need for platform-specific testing. Windows activation can succeed while other parts of the workflow still fail because of shell differences, permissions, or repo-specific configuration. Claude Code’s docs note that installation and shell behavior vary by environment, so one successful launch does not prove the whole setup.

It also does not solve governance by itself. A working extension can make it easier to use Claude Code casually, which is when teams drift into inconsistent instructions. If CLAUDE.md is bloated, if hooks are used as a catch-all policy layer, or if MCP access is broader than necessary, the workflow becomes harder to trust even when the extension loads correctly.

The main limit is simple: this changelog item is about availability, not capability. Teams should read it as a prompt to tighten onboarding, not as proof that the rest of the stack is standardized.

Further reading

• Claude Code changelog: https://code.claude.com/docs/en/changelog
• Claude Code overview: https://code.claude.com/docs/en/overview
• How Claude remembers your project: https://code.claude.com/docs/en/memory
• Hooks reference: https://code.claude.com/docs/en/hooks
• Connect Claude Code to tools via MCP: https://code.claude.com/docs/en/mcp
• Claude Code documentation index: https://code.claude.com/docs/llms.txt