Skip to main content
  1. Articles/

Claude Code v2.1.118: Vim Mode, Custom Themes, and Hooks That Talk to MCP

·1231 words·6 mins·

Three features dropped in Claude Code v2.1.118 that deserve more attention than a changelog entry:

  1. Vim visual mode — real selection, operators, and visual feedback
  2. Custom themes — a full JSON-based theming system, not just color presets
  3. MCP tool hooks — hooks can now call MCP tools directly, not just shell commands

None of these are headline features. All three reflect something important about where Claude Code is going: a terminal tool that increasingly adapts to how you work, not the other way around.

Vim Visual Mode: Finally Complete
#

Vim mode in Claude Code has been around for a while. What it was missing was visual mode — the ability to select text with v (character-wise) or V (line-wise), apply operators (d, y, c, >, <), and get clear visual feedback on the selection.

That’s now in v2.1.118.

For developers who think in vim motions, visual mode is not a nice-to-have. It’s the difference between a vim implementation that feels like vim and one that feels like “vim-ish.” You cannot effectively use vim without visual mode for selections. d3j works. v3jd works differently and is sometimes what you need. V5> for block-indenting — that’s a workflow, not a trick.

The /vim command is gone; toggle vim mode through /config → Editor mode. The consolidation makes sense — config is the right home for persistent editor preferences.

What this means for Claude Code’s positioning: there is a non-trivial segment of senior developers who will not use a terminal tool that cannot replicate their editor keybindings with sufficient fidelity. Vim visual mode removes a real adoption barrier for that segment. It also signals that Anthropic is investing in the editing experience within Claude Code’s terminal, not just in agent capabilities — which is the right call for a tool that asks you to spend hours per day in it.

Custom Themes: The Terminal Is Yours Now
#

The theming system in v2.1.118 is more substantial than “dark mode vs light mode.”

You create a theme via /theme, which gives you a named theme that persists across sessions. The theme is stored as a JSON file in ~/.claude/themes/. You can hand-edit the JSON for fine-grained control of every color in the interface. If you have a Claude Code plugin, you can ship themes in a themes/ subdirectory alongside the plugin — users install the plugin, get the theme.

This is the kind of extensibility that makes a terminal tool feel native to a developer’s environment instead of feeling like a tool that tolerates customization. A developer who has spent years tuning their Alacritty colors and their shell prompt will have opinions about how Claude Code’s UI looks. Now those opinions can be expressed.

There’s also a practical upside for enterprise deployments: organizations that want a unified look for internal tooling — consistent with their other developer tools, or with accessibility requirements — can ship a shared theme as part of a plugin bundle.

MCP Tool Hooks: The Integration Bridge
#

This is the most consequential change in v2.1.118, even though it gets the least attention.

Previously, Claude Code hooks — the automation scripts that fire on specific events (pre-tool call, post-tool call, session start, session stop) — could run shell commands. They could call scripts, write to files, post to webhooks. They could not natively invoke MCP tools.

Now they can. Add type: "mcp_tool" to a hook definition, specify the server and tool name, and the hook invokes an MCP tool directly when the event fires.

The implications are significant. MCP tools are the integration layer that connects Claude Code to external systems: databases, APIs, observability platforms, incident management systems, code review tools, CI/CD pipelines. Previously, hooking Claude Code behavior into those systems required a shell script that itself called an MCP server or an external API. That works, but it’s fragile — you’re running a script that manages another process’s lifecycle.

Direct MCP tool invocation in hooks means:

Pre-tool call hooks can query context from MCP servers. Before Claude runs a bash command, a hook can query your observability MCP server for current system state. If a metric is in a critical threshold, the hook can abort the tool call and surface that context to Claude — without any manual instrumentation.

Post-tool call hooks can write to MCP-connected systems. Every file Claude edits can trigger a hook that writes to your audit log via your logging MCP server. Every commit can trigger a post-hook that creates a linked ticket in your project management system via its MCP connector.

Session-level hooks can initialize and tear down MCP-connected state. Session start hooks can establish context in your MCP servers — user identity, project, compliance flags. Session stop hooks can clean up or summarize.

This turns Claude Code’s hook system into a proper event-driven integration framework, not just a way to run shell scripts at lifecycle points.

The MCP Startup Improvement
#

v2.1.118 also speeds up MCP startup when multiple stdio servers are configured. Previously, Claude Code would initialize all configured MCP servers sequentially at startup, which meant a proportional startup penalty for each server in your config.

The new behavior: resources/templates/list is deferred to first use (the @-mention that triggers resource loading). Non-essential initialization is pushed to when it’s actually needed. This matters in the real world, where a Claude Code config might have 10–20 MCP servers configured — a security scanner, a database connector, a GitHub MCP server, an observability tool, a few domain-specific internal servers.

Faster startup sounds trivial. It’s not when it’s the difference between opening Claude Code and seeing a ready terminal in one second versus waiting five seconds for server initialization. Agentic workflows often involve opening Claude Code sessions frequently — in different project directories, in CI contexts, in agent orchestration chains. Every second of startup time compounds.

The OS CA Certificate Change
#

A quieter but operationally significant change: Claude Code now trusts the OS CA certificate store by default. Enterprise TLS proxies work without extra configuration.

This has been a friction point for teams that route developer tools through a corporate TLS proxy. Claude Code would reject the proxy’s certificate because its certificate store didn’t include the corporate CA. The fix required manual configuration that many developers didn’t know how to do and security teams didn’t want to document.

Now it just works. For enterprise deployments, this removes a class of support tickets.

What These Updates Signal
#

Taken individually, none of these features change what Claude Code fundamentally is. Together, they reveal a consistent product direction: make the tool maximally comfortable for senior engineers who have strong preferences about their environment, and make the integration surface maximally open for teams building production agentic workflows.

The vim completion, the theming system, and the CA store change are all about developer comfort and adoption. The MCP hook integration and startup improvements are about production deployability at scale.

The underlying architecture thesis remains unchanged: Claude Code is a terminal-native agentic tool, not an IDE extension. Every feature in v2.1.118 deepens both the comfort of living in that terminal and the power of the integrations it can orchestrate from it.


Sources

Related