claude-code 2.1.238 Adds Header Helpers

claude-code v2.1.238 is an official GitHub release for Claude Code, Anthropic's coding agent that runs in the terminal, IDE, and GitHub. It deals with a practical question: how should a coding agent fetch private plugin catalogs, survive runner shutdowns, and stay predictable during long interactive sessions? The answer is a plumbing release: plugin marketplace header helpers, readline-style prompt deletion, safer self-hosted runner exits, proxy authorization hooks, and fixes for memory and output-style drift. If you are looking at claude code mcp integrations, the important bit is that marketplace authentication now has a narrower, reviewable command boundary instead of being hidden inside a manual fetch step.

Read the release as terminal plumbing, not a new personality

The most visible user-facing change is small and welcome: keybindingFlavor can be set to readline. With that setting, Ctrl+W in the prompt deletes back to the previous whitespace, the way Bash users expect. The default stays classic, so existing muscle memory does not move unless you ask for it.

That matters because terminal agents live or die on boring input behavior. A prompt that handles text like your shell feels less like a special app and more like a tool you can keep open all afternoon.

The trap is to treat this release as a sweeping workflow change. It is not. It is a set of edges being sanded down: input behavior, plugin fetch auth, runner shutdown, proxy authorization, memory release, output-style persistence, and prompt suggestion behavior.

The fixes are the other half of the story. The release notes say long interactive sessions had unbounded memory growth because subagent tool results were not released after leaving the recent display window. They also note fixes for custom, project, and plugin output styles drifting back to the default voice mid-session, plus prompt suggestions not staying enabled when CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=true.

Treat headersHelper as a plugin fetch boundary

A headersHelper is a command that mints HTTP headers for Claude Code plugin marketplace requests. In v2.1.238, a URL marketplace or a catalog entry can use it to produce headers for catalog fetches and same-origin archive fetches.

That is the clever part of the release. Private plugin marketplaces often need short-lived credentials, but hard-coding tokens into config is a bad habit. A helper command lets the credential be generated when needed, shown to the user as a command, and scoped to the fetch path the release describes.

There is also a deliberate speed bump. The release says a catalog entry's headersHelper runs only when you install or update that plugin, after its command is shown. claude plugin install and claude plugin update ask [y/N], unless you pass -y.

That prompt is the trust boundary. Do not train yourself to smash -y on a marketplace you have not inspected. The helper can be benign, like minting a short-lived internal token, or it can be too broad, like returning a long-lived bearer token that works across unrelated services.

A small permission note is enough for a real repo:

Plugin marketplace auth note

Marketplace: internal-plugins.example.com
headersHelper purpose: mint short-lived HTTP headers for catalog and same-origin archive fetches
Allowed during: claude plugin install and claude plugin update only
Review before -y: command path, token lifetime, destination origin, logs

That is not ceremony. It is future-you leaving a breadcrumb before the command becomes normal.

Test runner shutdown like a real interrupted session

The new self-hosted runner flag is about graceful exits. claude self-hosted-runner --defer-shutdown-max-min tells the runner that, on SIGTERM, it should keep serving attached sessions, park what remains after the configured number of minutes, and then exit.

That is useful for maintenance windows, container termination, and hosted environments where the process receives SIGTERM before disappearing. The release does not make shutdown magic. It gives you a maximum deferral window, which is exactly the kind of knob operators can reason about.

There are two proxy flags too: --proxy-authorization-command and --proxy-authorization-file. These are for egress proxies that require a freshly issued Proxy-Authorization header on every connection.

The trap is to test this only with an idle runner. Use an attached session. Start a real edit, send SIGTERM, and check whether the session keeps serving until the deferral window closes. If you have been following the earlier remote-session repairs in claude-code 2.1.229 Repairs Remote Sessions, this release is another small step in the same operational direction: make remote work less fragile under normal infrastructure behavior.

Try it on one small repo before depending on it

Pick a low-risk repo with one plugin marketplace and one integration path. If your project keeps Claude Code conventions close to the code, the same habit fits here: write one short note near the repo instructions, not a giant policy. The related training topic has the broader pattern, but this release only needs a small experiment.

For a claude code mcp setup, keep the first pass narrow. Use one MCP server, one plugin catalog, and one helper command whose output you can inspect without leaking secrets. You are testing boundaries, not building a platform.

A clean command workflow looks like this:

# Check the installed Claude Code version first.
claude --version

# Install or update one plugin from the marketplace.
# Read the displayed headersHelper command before approving.
claude plugin install <plugin-name>
claude plugin update <plugin-name>

# Use -y only after the helper command, origin, and token lifetime are understood.
claude plugin update <plugin-name> -y

Then test the terminal behavior separately. Set keybindingFlavor to readline, open a prompt, type a command with several words, and press Ctrl+W. If it deletes to the previous whitespace and nothing else changed, you have a low-drama win.

For self-hosted runners, keep the test just as small. Run one attached session, send SIGTERM, and confirm three things: attached work keeps serving, old work is parked after the maximum number of minutes, and the process exits. If your proxy requires fresh authorization on every connection, test the command or file path with a short token lifetime rather than a forever credential.

Copy this v2.1.238 test note

Use this as a lightweight upgrade note in a pull request, issue, or release comment.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Common questions

• What should teams know about claude code mcp?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “claude-code 2.1.238 Adds Header Helpers.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• claude-code — source
• Model Context Protocol — specification
• Claude Code — getting started
• Claude Code docs: en skills

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.