DEV Community

RAXXO Studios
RAXXO Studios

Posted on • Originally published at raxxo.shop

Claude Code 2.1.118 Adds Vim Mode, /theme, And Hook MCP

  • Vim visual mode lands in Claude Code 2.1.118 with v and V selection, plus full operator support over highlighted ranges.

  • /usage replaces /cost and /stats with one unified command, per-model breakdowns, and cache-hit numbers for subscription users.

  • Custom themes via /theme let you ship your own JSON color file and pick it interactively without forking the binary.

  • Hooks can now invoke MCP tools directly, turning Claude Code into an ambient automation layer that fires server actions on every edit.

  • DISABLE_UPDATES and Windows-side managed settings reaching WSL give locked-down enterprise teams the controls they have been asking for.

Claude Code 2.1.118 dropped on April 23, and it is the most "power user" release I have seen since hooks shipped. Vim visual mode, custom themes, /usage replacing /cost, and the sleeper feature: hooks that can fire MCP tool calls. Here is what changed in my setup the day it landed.

Vim Visual Mode Is Finally Here

If you run Claude Code with vim mode on (and you should), the gap was always visual selection. You could move with hjkl, delete with d, yank with y, but you could not see what you were operating on. 2.1.118 closes that gap.

Press v from normal mode and you enter character-wise visual mode. Press V and you get visual-line mode (whole-line selection). The input area now shows the highlighted range, and every operator works the way you expect. Select three lines with V then hit d and they are gone. Select a word with viw then hit c and you are typing the replacement. y yanks. > shifts. The whole muscle memory transfers.

I tested this against the kind of prompts I write fifty times a day. Pasting a long instruction, realizing the second paragraph needs to move first, used to mean either retyping or fighting the cursor. Now it is Vjd then P. Two seconds. The keystrokes I have been doing in vim for fifteen years just work.

The implementation detail I appreciate: the visual feedback is in the input area itself, not a popup or a status line. It uses the same color scheme as the editor, so highlighted ranges read at a glance. No new mental model to learn.

One small thing worth knowing. Visual mode respects line wrapping in the input, so a V on a wrapped line still selects the logical line, not just the visual row. That matched my expectations from real vim and saved me from a "wait, what did that just delete" moment on the first run.

If you have not turned vim mode on, this is the release that earns the switch. Settings, then editor mode, set to vim, restart the session. The first hour is awkward. The second hour is faster than you were before.

/usage Replaces /cost And /stats

The old /cost command told you how much a session cost. The /stats command told you token counts. Useful, but you were running two commands and stitching the picture together yourself. 2.1.118 merges them into /usage.

One command, one screen. Per-model breakdown so you can see where the Opus calls went versus the Sonnet calls. Token totals split by input, output, cache reads, and cache writes. For Pro and Max subscribers, the cache-hit ratio is now front and center, which matters because cache hits are effectively free and a low ratio means your prompts are flapping around between calls.

The cache-hit display landed in the April 4 release. 2.1.118 is the cleanup pass that finalizes the merger and retires the old commands. /cost and /stats are gone. Type either one and you bounce to /usage.

Why I care: I run /usage at the end of every working session and it tells me whether my hook setup is doing its job. If the cache-hit ratio drops below 70 percent on a long session, something is invalidating the prefix every turn, usually a hook that injects a timestamp or a freshly read file. The number gives me a tight feedback loop instead of guessing.

For teams paying by token, /usage is also the cleanest way to spot a runaway agent. Per-model breakdown means you can see if a sub-agent kept calling Opus when Sonnet would have been fine. That conversation is much easier with a number on the table.

Hooks Can Now Call MCP Tools (The Sleeper Feature)

This is the change that rewrites how I think about Claude Code. Until 2.1.118, hooks could only run shell commands. You could trigger a script after Edit, after Write, before Bash, but the script lived in shell-land. To talk to a real service you had to write a wrapper that called the service yourself.

Now hooks can invoke MCP tool calls directly. After every Edit, fire your lint MCP server. Before every Bash command, hit a policy MCP server that approves or rejects it. After every Write to the blog content folder, kick off a syndication MCP tool. The hook config points at the MCP server and the tool name, and the harness handles the call.

For me this collapses three layers into one. I had a setup where the hook called a shell script, the shell script called curl, and curl hit my own MCP-shaped service. Half the bugs lived in the seams. The new pattern lets the hook fire the MCP tool with a typed payload, no shell glue.

The compound effect: hooks-with-MCP turns Claude Code into an ambient automation layer. Every file you touch can trigger an action against any MCP server you have configured. Lint, format, generate types, push to a queue, log to an audit table, ping a teammate. The harness is doing the work; you are just declaring what should happen and when.

I covered the basic hooks pattern in an earlier piece on /blogs/lab about the nine hooks that audit every file I write. That setup used shell scripts because that was all hooks could do at the time. 2.1.118 is the upgrade path. I am rewriting two of those nine to call MCP tools instead, and the diff is shorter and less brittle.

If you ship hook packs as a product, this changes the surface area you can sell. Hook packs that include MCP servers are now a coherent unit, which is exactly the bet /pages/claude-blueprint is built on.

Enterprise Controls: DISABLE_UPDATES And WSL Inheritance

Two changes in 2.1.118 are aimed squarely at locked-down corporate environments, and they tell you something about who Anthropic is selling Claude Code to now.

First, the DISABLE_UPDATES environment variable. Set it and Claude Code will not check for, fetch, or apply any updates. No background pings, no "version X is available" prompts, no auto-upgrades on next launch. For regulated teams that need to pin a known-good version through a quarterly review cycle, this is the toggle they have been waiting for. Compliance teams can audit one binary, sign off once, and move on.

Second, WSL Claude Code on Windows now inherits Windows-side managed settings. If your IT department pushes a managed-settings policy via Windows (the same way they manage browser policies and group policy objects), the Linux Claude Code running inside WSL will read it. Permitted MCP servers, allowed hooks, telemetry endpoints, all the things admins want to centralize: one policy file, two operating systems, no duplication.

These are not features I personally use day to day. I am one designer with a laptop. But they tell me Claude Code is being treated as a real piece of enterprise software, not just a hobbyist tool. That is good for the rest of us because it means the binary is being hardened, the install paths are getting documented, and the support matrix is widening. The releases will keep coming.

The other tell: the release notes call these out by name instead of burying them. Claude Code is being positioned as something a CIO can sign off on. Vim mode and custom themes are the consumer surface. DISABLE_UPDATES and WSL settings inheritance are the enterprise foundation.

Bottom Line

2.1.118 is a small version bump with a big personality change. Vim visual mode and /theme are the surface gloss. /usage is the long-overdue cleanup. The hook-to-MCP bridge is the structural shift, and it is the one I am building around this week.

If you author hooks, rewrite the brittle ones to call MCP tools. If you sell hook packs, your product just got more valuable because the integration story is cleaner. If you run Claude Code in a regulated environment, DISABLE_UPDATES and WSL settings inheritance are the two flags worth flipping today.

I package my own hooks and skills in the Claude Blueprint, and 2.1.118 is exactly the kind of upgrade that makes that pack do more without changing the price. Hooks that fire MCP tools, themes that match your brand, /usage that tells you whether your prefix caching is working: it all stacks. Update Claude Code, then go look at what your hooks could now do that they could not do last week. That is where the time savings live.

Top comments (0)