Claude Code v2.1.85 — 6 New Environment Variables: MCP Server Config and a 7 MB Diet#

Published on March 27, 2026

Part of the Claude Code Version Tracker series. | Official Env Vars | Official Changelog

Claude Code v2.1.85 adds 6 new environment variables and removes the CLAUDE_CODE_SUBAGENT_MODELU typo from v2.1.84. The headline is MCP server configuration — letting one helper process serve multiple servers — but the binary tells an equally interesting story: a 7.15 MB reduction driven by replacing a WebAssembly layout engine with pure TypeScript.

What Changed#

v2.1.84v2.1.85
Environment variables197202 (+5 net)
Binary size194.17 MB187.03 MB (-7.15 MB)

Model IDs (16), feature gates (41), dynamic configs (29), and slash commands (22) are unchanged from v2.1.84.

New Environment Variables#

VariableLikely Purpose
CLAUDE_CODE_MCP_SERVER_NAMEIdentifies which MCP server a helper process is acting on behalf of. When you add MCP servers to Claude Code (via claude mcp add or your .claude.json config), each server normally gets its own spawned process. The changelog describes a new pattern where "one helper can serve multiple servers" — this variable tells the helper which server configuration to load, so a single process can route requests to the right MCP server instead of spawning a separate process for each one. If you run 5 MCP servers, that's 5 fewer processes competing for resources.
CLAUDE_CODE_MCP_SERVER_URLProvides the MCP server endpoint URL to a helper process. Together with CLAUDE_CODE_MCP_SERVER_NAME, this forms the configuration pair for the multiplexed helper pattern. Practical scenario: your MCP servers run as containers with dynamically assigned URLs (different in dev vs. staging vs. prod). Instead of hardcoding addresses in each server config, the helper receives the URL at runtime.
CLAUDE_CODE_COMMIT_LOGLikely controls whether or where Claude Code logs commit operations. This could enable audit trails for automated commits made by agents and sub-agents — particularly relevant for enterprise teams that need to track which agentic sessions created which commits, or for debugging workflows where automated PRs appear with unexpected content.
CLAUDE_CODE_PWSH_PARSE_TIMEOUT_MSSets the timeout for PowerShell command parsing on Windows. The PowerShell tool shipped as a preview in v2.1.84 with CLAUDE_CODE_USE_POWERSHELL_TOOL — this variable adds a safety valve for parse operations that hang or take unexpectedly long. Complex PowerShell scripts with heavy module imports can stall during parsing; this timeout prevents those from blocking the entire session.
CLAUDE_LOCAL_OAUTH_API_BASEOverrides the base URL for local OAuth API operations. This extends the auth customization story started by CLAUDE_AI_ORIGIN in v2.1.84, giving operators finer control over where OAuth token exchanges happen — separate from the main AI endpoint. Useful for air-gapped or on-premise deployments where the OAuth server runs on a different host than the inference API.
CLAUDE_LOCAL_OAUTH_APPS_BASEOverrides the base URL for the local OAuth applications registry. Together with CLAUDE_LOCAL_OAUTH_API_BASE, this completes a two-part override for the OAuth flow: one for token operations, one for app registration and discovery. Enterprise deployments with custom identity providers can now point both halves of the OAuth flow at their own infrastructure without patching the binary.

Removed Environment Variables#

VariableNotes
CLAUDE_CODE_SUBAGENT_MODELUThe trailing-U variant flagged as a likely typo in v2.1.84 has been removed. CLAUDE_CODE_SUBAGENT_MODEL (without the U) remains. Clean housekeeping.

Key Changes in This Release#

Performance: There's Flexbox Inside Your Terminal#

Editor's note: Yes, you read that right. The terminal UI you've been staring at every day? It's running CSS flexbox layout. Inside your terminal. Mind = blown.

Yoga is Facebook's cross-platform flexbox layout engine — the same engine that powers layout in React Native. Claude Code uses Ink, a React-based framework for building terminal UIs, and Ink uses Yoga to calculate flexbox layouts for terminal components: where text wraps, how columns align, how the output panel resizes as your terminal changes dimensions. Every time Claude Code renders output, flexbox is computing the layout — just like a browser would for a web page, except the viewport is your terminal window.

Until v2.1.85, Ink's Yoga dependency was a WebAssembly binary compiled from C++ and embedded in the JS bundle. Every time Claude Code rendered a frame — every new line of output, every scroll event, every terminal resize — it crossed the WASM-to-JS bridge to compute layout. Those bridge crossings aren't free: each one involves serialization overhead, and WASM can't be JIT-optimized the way native JavaScript can.

What users see: The changelog notes "better scroll performance with large transcripts" and "reduced UI stutter during compaction on large sessions." If you've ever noticed Claude Code getting sluggish after a long session with thousands of lines of output — especially during /compact — the WASM layout bridge was likely a contributing factor. The pure TypeScript replacement eliminates the bridge entirely. Layout calculations now run as regular JS that Bun's JIT compiler can inline and optimize.

The 7 MB binary shrink is a side effect of the real goal. When a WebAssembly module is embedded directly in a JavaScript bundle (rather than loaded as a separate .wasm file), it's typically base64-encoded into a string literal. Base64 encoding alone adds ~33% overhead to the binary size (Guido Zuidhof, "Embedding WebAssembly in JavaScript"). On top of that, the WASM module ships with synchronous instantiation wrappers, memory management glue code, and sometimes both WASM and asm.js fallback variants. The yoga-layout npm package weighs ~1.5 MB on its own, but once base64-encoded, bundled with glue code, and combined with tree-shaking limitations (bundlers can't analyze WASM internals), the effective contribution to a JS bundle balloons to several megabytes. Nick Fitzgerald's "Recommendations when publishing a Wasm library" documents this "base64 tax" and why library authors should let consumers load WASM separately — but Claude Code bundles everything into a single executable, so the tax was unavoidable until the WASM dependency was eliminated entirely.

This is notable because the trend from v2.1.69 through v2.1.84 was consistent growth (from ~170 MB to ~194 MB). Replacing WASM with pure TypeScript suggests the team is actively profiling bundle composition and making targeted cuts — new features are being added while simultaneously removing embedded binary blobs that inflate the bundle.

Conditional Hooks#

Hooks now support an if field using the same syntax as permission rules. Previously, every hook fired unconditionally — if you had a PreToolUse hook, it ran on every tool call regardless of context. The if field lets you scope hooks to specific conditions without spawning a process just to check whether the hook should execute. The changelog notes this "reduces process spawning overhead," which matters for high-frequency hooks on machines running many concurrent sessions.

Scheduled Task Timestamps#

Transcript output now includes timestamp markers when scheduled tasks execute. For teams using Claude Code's scheduling/cron features, this provides audit trail data — when exactly did a scheduled agent run, and how does that correlate with the changes it made? A small addition that addresses a real observability gap for automated workflows.

Bug Fixes#

Notable fixes include /compact failing with context-exceeded errors on large sessions, --worktree exiting prematurely in non-git repos, MCP step-up authorization failing when a refresh token exists, and memory leaks in remote sessions and edge connections. The plugin system also gets a fix for enable/disable operations when install locations differ from expectations.

What These Tell Us#

MCP is graduating from "connect to a server" to "manage a fleet." The MCP_SERVER_NAME and MCP_SERVER_URL env vars enable a multiplexed helper architecture — one process, many servers. To understand why this matters, consider how MCP servers work today in Claude Code. When you configure servers in your .claude.json:

{
  "mcpServers": {
    "github": { "type": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] },
    "postgres": { "type": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"] },
    "slack": { "type": "stdio", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"] }
  }
}

Each server spawns its own process — three servers, three processes, three sets of npx overhead. For teams running 5-10 MCP servers (database, GitHub, Slack, custom internal tools, documentation, etc.), this adds up in memory and startup time.

The new env vars suggest a helper pattern where a single process acts as a router:

{
  "mcpServers": {
    "unified-helper": {
      "type": "stdio",
      "command": "my-mcp-helper",
      "env": {
        "CLAUDE_CODE_MCP_SERVER_NAME": "github",
        "CLAUDE_CODE_MCP_SERVER_URL": "http://localhost:8080/github"
      }
    }
  }
}

The mcp-proxy project already implements this pattern — bridging stdio and HTTP transports so a single proxy can front multiple MCP servers running as HTTP services. Combined with the 2KB description cap from v2.1.84 (which prevents OpenAPI-generated servers from consuming entire context windows) and the deduplication logic for local vs. cloud-configured servers, Claude Code is building toward a production-grade MCP management layer where operators define servers once and the infrastructure handles routing, deduplication, and resource sharing.

For teams already running MCP servers in containers or Kubernetes, this is a natural fit: run your MCP servers as HTTP services behind a load balancer, point a single helper at the routing layer, and let MCP_SERVER_NAME + MCP_SERVER_URL handle the dispatch. The MCP Streamable HTTP transport (which replaced the deprecated SSE transport in the March 2025 MCP spec) was designed exactly for this topology.

OAuth customization is building toward "bring your own identity provider." Looking at the trajectory across recent releases:

  • v2.1.84: CLAUDE_AI_ORIGIN — override the main auth endpoint
  • v2.1.85: CLAUDE_LOCAL_OAUTH_API_BASE — override token exchange endpoint
  • v2.1.85: CLAUDE_LOCAL_OAUTH_APPS_BASE — override app registry endpoint

Three auth-related env vars across two releases, each targeting a different component of the OAuth flow. The pattern suggests Anthropic is decomposing Claude Code's auth stack into independently configurable pieces — the same pattern enterprise identity platforms (Okta, Auth0, Azure Entra ID) use when integrating with custom backends.

Where this is likely heading: full support for corporate SSO flows where Claude Code authenticates through an organization's existing identity provider rather than Anthropic's servers. The pieces are falling into place — you can already override the AI inference endpoint (CLAUDE_CODE_API_BASE_URL), the auth origin (CLAUDE_AI_ORIGIN), the token service (CLAUDE_LOCAL_OAUTH_API_BASE), and the app registry (CLAUDE_LOCAL_OAUTH_APPS_BASE). What's missing is Dynamic Client Registration (DCR) configuration and SAML/OIDC bridge settings. If those appear in the next few releases, it would complete the picture: Claude Code as a fully enterprise-federated tool that never touches Anthropic's auth servers, with the entire auth flow running through the organization's own infrastructure. Microsoft's recent guide to building Claude-ready MCP servers with Azure API Management and Entra ID already demonstrates the demand for this pattern from the other direction.

This analysis is conducted for independent security research and interoperability purposes under fair use principles. All trademarks belong to their respective owners. The information presented here documents publicly observable behavior of installed software and is not intended to circumvent any technological protection measures, infringe on intellectual property rights, or encourage unauthorized use. Use these findings at your own discretion.

Related: Context Window Management Guide | Claude Code Productivity Tips | The Agentic Engineering Playbook

Let's Connect

BlueskyLinkedInThreads
← Back to all posts