Claude Code release notes: 2.1.193-2.1.195 make agent receipts clearer
Part of the series: Claude Code release notes

Claude Code just got two release blocks that are easy to dismiss as small technical fixes. Do not. 2.1.193 and 2.1.195 are about how an agent run leaves a trace: why auto mode said no, what goes into telemetry, whether hooks match the right tools, and whether background agents survive crashes.
For Nordic teams starting to use Claude Code in real repos, that is more useful than another big feature headline. A coding agent is an AI assistant that can read code, use tools, and sometimes run commands for you. The more it can do, the more each run needs a short agent receipt: what the agent tried, what was denied, what was logged, and what a human approved.
Source: Claude Code v2.1.193 and Claude Code v2.1.195
Claude Code release notes 2.1.193-2.1.195: less mystery in longer agent runs
2.1.193 adds autoMode.classifyAllShell, a setting that can route all Bash and PowerShell commands through the auto-mode classifier, instead of only patterns that look like arbitrary code execution. The same release also shows auto-mode denial reasons in the transcript, the denial toast, and /permissions recent denials.
Dry wording, useful effect: when Claude is not allowed to do something, the team should be able to see why. An approval gate is a point where a human or policy stops the agent before it runs, writes, sends, or publishes something. If the denial only disappears as a feeling in the terminal, nobody learns from it.
Source: Claude Code v2.1.193 release notes
The same release added claude_code.assistant_response as an OpenTelemetry log event. OpenTelemetry is an open standard for collecting logs, metrics, and traces from software. Here is the detail teams should not miss: response text is redacted unless OTEL_LOG_ASSISTANT_RESPONSES=1 is set. If that variable is unset, it follows OTEL_LOG_USER_PROMPTS, so environments that already log prompts may start receiving response content after upgrade. Set OTEL_LOG_ASSISTANT_RESPONSES=0 if you want to keep prompts-only logging.
That is a good reminder of how to integrate AI safely: decide storage, redaction, access, and review routines before logging more content. Secrets belong in env vars or secret managers, permissions should be scoped, and the agent receipt should be readable without leaking customer data.
Source: Claude Code v2.1.193 release notes
Hooks, plugins and background agents became easier to trust
2.1.195 is more of a stability release, but it includes an important control point: hook matchers with hyphenated names, such as code-reviewer and mcp__brave-search, now exact-match instead of accidentally substring-matching. To match all tools from a hyphenated MCP server, the source uses the pattern mcp__brave-search__.*.
A hook is a rule or trigger that runs something at a certain event in the agent workflow. When hooks control tests, review, blocks, or logging, almost matching the right thing is not enough. A bad match can make a checkpoint disappear or fire on the wrong tool.
Source: Claude Code v2.1.195 release notes
The same release fixes several everyday problems: external plugins enabled only through a project's .claude/settings.json should require explicit install consent on every loader path, background jobs should not disappear from claude agents or lose data when newer versions wrote them, and Remote sessions now get a provisioning checklist while the container starts. The npm registry showed 2.1.195 as the current package version during verification.
Source: Claude Code changelog and npm registry: @anthropic-ai/claude-code latest
How to test this this week
Do not start with a big policy. Pick one repo where Claude Code is already used and run a short operating check. Three things are enough:
- one shell command that should be stopped or justified
- one hook rule with an exact tool name
- one background agent that should remain visible in
claude agents
If the team uses telemetry, add a fourth check: which prompts and responses may be logged, where are they stored, and who can read them? That is the Tool Forge idea in practice: connect AI to real tools, but make permissions, secrets, approvals, and audit logs understandable before the workflow becomes normal.
Try this prompt this week
Human step: open a repo where Claude Code 2.1.195 can be used or where you can read current Claude Code settings. Collect links or files for settings, hooks, MCP config, and telemetry. Do update and version checks outside the prompt.
Read our Claude Code settings, hooks, MCP config and telemetry notes.
Compare them with 2.1.193-2.1.195: auto-mode denials, assistant_response logging, hook exact-match and background agents.
Suggest the first three small tests or changes we should make.
Mark what needs human approval before responses are logged, shell runs or hooks change.
Write the answer as a short agent receipt with open questions last.
Good output should include:
- one clear line about what may be logged and what should be redacted
- one concrete check for
autoMode.classifyAllShellor auto-mode denial reasons - one hook match the team can actually review
- one note about background agents or Remote session startup
FAQ
Is Claude Code 2.1.195 a major feature release?
No. It is mostly a stability release. The practical value is exact hook matching, plugin consent, steadier background agents and clearer Remote session startup.
Should we log Claude responses with OpenTelemetry?
Only if storage, redaction and access are decided. Release 2.1.193 says response text is redacted unless OTEL_LOG_ASSISTANT_RESPONSES=1 is set.
What should a team test first?
Test one auto-mode denial, one hook match with an exact tool name, and one background agent that should remain visible in claude agents.
The Forge newsletter
Get new articles in your inbox
Pick the topics you care about. No noise, at most one email a week.
We follow GDPR. Unsubscribe anytime.


