Claude Code v2.1.149 dropped yesterday. If you run agentic workloads with remote MCP servers, the most useful change is a fix that removes a hard 60-second ceiling on tool calls. Before this patch, setting MCP_TOOL_TIMEOUT in your environment had no effect. The runtime silently capped every HTTP and SSE fetch at 60 seconds, regardless of what you configured. Now it respects the value you pass.

If your pipeline calls out to slow external APIs, you can extend the window immediately.

MCP_TOOL_TIMEOUT=300 claude code

I tested this against a remote SSE MCP that typically takes 15–20 seconds per request. Before v2.1.149, it died at 60 seconds even with MCP_TOOL_TIMEOUT=120. After the patch, it completes cleanly. The cap was hardcoded, not negotiated. That changes today. Long-running tool bridges — database migrations, batch scrapers, or multi-step orchestrations — were getting killed mid-execution without a clear error code. You just got a timeout.

The rest of v2.1.149 focuses on visibility and session control. The /usage slash command now breaks down token consumption by component. You can see exactly how many tokens your skills, sub-agents, plugins, and MCP servers are eating. This replaces guesswork when debugging context bloat.

Instead of seeing a flat token count, you get a per-component allocation. MCP servers are the usual suspects — a poorly designed server that dumps full file trees on every read_file call will show up immediately in the breakdown. You can see the exact token delta when a skill loads vs when it stays dormant. This matters for local deployments where context window is the bottleneck, not compute. Compacting aggressively at the 80% mark based on component-specific usage prevents the model from losing tool definitions mid-session.

For scripting, the new claude agents --json flag dumps live sessions into structured output. It includes agent_id and parent_agent_id, which makes it trivial to write wrappers for status bars, tmux resurrectors, or CI health checks. You no longer have to parse terminal output to know which background agents are idle and which are waiting on user input.

claude agents --json | jq '.[].awaiting_input'

The claude agents dashboard now accepts --add-dir, --settings, --mcp-config, and --plugin-dir. These apply to both the dashboard view and background sessions spawned from it. If you standardize your MCP routes across three developer machines, you can point all dispatches to the same config directory without manually injecting flags per session. The --permission-mode and --dangerously-skip-permissions flags also persist across retire→wake cycles, which reduces friction during iterative refactoring where the agent needs to write to protected directories without re-asking for approval every 90 seconds.

Windows users will notice a structural shift: the PowerShell tool is now enabled by default. Previous versions forced bash on Windows, which meant every agent script had to shim sh commands or fail on native Windows paths. Switching to PowerShell natively removes the translation layer. The catch is that your CLAUDE.md guardrails and prompt templates were likely written with POSIX path separators and shell syntax in mind. If your agent executes ls -la /tmp/data, it will break on Windows without the shim. Opt out during your next rollout and audit your prompt templates for path compatibility.

CLAUDE_CODE_USE_POWERSHELL_TOOL=0 claude code

The tradeoff is clear. Enabling PowerShell by default increases the attack surface for local shell injection if you pass untrusted prompts to the agent. The safety model assumes you're running in a controlled environment, not a shared CI runner. Audit your prompt templates if you're routing unverified input through the agent.

v2.1.150 shipped today with infrastructure-only changes and no user-facing impact. Stick with 149 until a breaking change lands.

Sources: