Claude Code 2.1.161 protects MCP secrets and shell startup files

AI 요약

• What happened: Anthropic shipped Claude Code 2.1.160 and 2.1.161 on June 2, 2026.
  • 2.1.160 adds approval prompts before writes to shell startup files and execution-sensitive build config; 2.1.161 redacts secrets from claude mcp command output.
• Why it matters: The security boundary for coding agents is moving into local configuration, MCP connections, and terminal logs, not only generated code.
• Builder impact: Teams using acceptEdits, MCP servers, or headless Claude Code runs should review prompts, redacted CLI output, and OpenTelemetry labels.
  • These changes reduce accidental execution-path changes and secret exposure, but they do not replace vaulting, secret scanning, workspace trust, or CI isolation.

Anthropic's anthropics/claude-code repository published two releases on June 2, 2026. According to the GitHub release notes, v2.1.160 landed at 02:10 and v2.1.161 followed at 21:58. The changes are small on the surface: approval prompts, MCP output redaction, and OpenTelemetry labels. The operational message is larger. Claude Code is drawing sharper lines around places where a local coding agent can change execution behavior or expose credentials without looking like it changed application code.

v2.1.160 starts with shell startup files. Claude Code now prompts before writing to .zshenv, .zlogin, .bash_login, and ~/.config/git/. The release note describes these files as paths that can lead to unintended command execution. That is a different risk class from editing a component, a test, or a README. A repository diff can be reviewed in context. A shell startup file can run commands the next time a terminal session starts. A Git config can change behavior the next time a developer fetches, commits, signs, aliases, or runs a hook-adjacent workflow.

The same release adds a more direct guardrail for users of acceptEdits. Claude Code now prompts before writing build-tool configuration files that can grant code execution, even when the user has turned on automatic edit acceptance. Anthropic names .npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, and .devcontainer/ as examples. The distinction is precise: editing a file and changing an execution path are not the same operation, even if both appear as ordinary text changes in an editor.

That distinction becomes more important as AI coding tools shift from autocomplete into agent workflows. Claude Code can read and edit files, run shell commands, work with MCP servers, keep background sessions alive, and delegate long tasks. Developers turn on acceptEdits because answering every small diff prompt slows the loop. But .npmrc, .pre-commit-config.yaml, and .devcontainer/ can affect install scripts, hooks, build behavior, container startup, and workspace execution. A request that starts as "fix this component" can become an execution-policy change if the agent modifies one of those files.

Claude Code's permission mode documentation already separates these operating modes. The docs say acceptEdits automatically approves file edits inside the working directory and common filesystem commands such as mkdir, touch, rm, mv, cp, and sed. The same documentation also keeps protected-path writes outside automatic approval unless the user chooses a stronger bypass mode. v2.1.160 makes that protected-path idea more visible in day-to-day work by adding prompts around files that can alter future command execution.

v2.1.161 moves to MCP. The release note says claude mcp list/get/add no longer exposes secrets in terminal output. ${VAR} references are no longer expanded, credential headers are redacted, and URL secrets are redacted. That fix matters because MCP configuration often contains endpoints, headers, tokens, internal URLs, development credentials, and service-specific connection details. A CLI that expands and prints those values makes debugging easier, but it also leaves secrets in terminal scrollback, logs, screen recordings, support snippets, and copied issue comments.

MCP turns a coding agent's connection list into an attack surface. Without MCP, the agent's access is mostly limited to the local workspace, command permissions, and configured remote services. With MCP, the same agent may see ticket systems, database schemas, cloud consoles, browser automation, internal APIs, documentation search, design files, secret scanners, and observability tools. The security question is no longer only whether generated code is correct. It is also which tools and credentials the agent can enumerate, call, or reveal through ordinary inspection commands.

Redaction does not make MCP configuration safe by itself. It closes one leak path. Teams still need to decide where credentials live, how MCP server access is scoped, which repositories can use which server definitions, where logs are retained, and how shared configuration moves between developers. Keeping real secrets out of repository files remains the safer default. Vault-backed environment variables and short-lived credentials are still separate controls. Claude Code not expanding ${VAR} in mcp command output does not prove that the variable is injected safely or rotated correctly.

v2.1.161 also adds observability detail. OTEL_RESOURCE_ATTRIBUTES values are now included as labels on metric datapoints, which lets usage metrics be split by custom dimensions such as team, repository, environment, or workflow. In a coding-agent deployment, that is not only a cost-reporting feature. Long-running sessions, workflow agents, MCP-heavy tasks, and background operations all create operational questions: which repository is generating the most usage, which team adopted a new workflow, and whether a release changed failure rates or tool-call patterns.

Observability is not enforcement. A team label will not stop a risky command, and a repository label will not redact a leaked secret. But operations teams need measurement before they can tune policy. If Claude Code usage increases inside a security-sensitive repository, a platform team may want stricter permission modes, containerized execution, narrower MCP servers, or a separate review path. OpenTelemetry labels give that discussion a lower-level data source than anecdotes from developers who happen to notice prompts.

v2.1.160 did not only add friction. It also reduced a read-before-edit annoyance: single-file grep, egrep, and fgrep commands can now satisfy the read-before-edit check. In practice, that means a user or agent that already inspected a specific file with grep may not need a separate read step before editing. That detail matters because a permission system that only adds prompts encourages users to reach for stronger automatic modes. A better system asks fewer questions where the risk is low and more specific questions where the edit changes execution behavior.

DevelopersIO's June 2 write-up of Claude Code v2.1.160 also highlighted the shell startup, Git config, and build-tool config approval prompts. That matches the release-note ordering. Anthropic placed the permission changes first, ahead of convenience tweaks. The product judgment is that prompt fatigue remains a problem, but some files should cross an explicit approval boundary even in automatic edit flows.

The change fits the broader Claude Code permission debate. The official documentation separates default, acceptEdits, plan, auto, dontAsk, and bypassPermissions. auto allows more work through background safety checks, while bypassPermissions is documented for isolated containers or VMs. Developers want fewer interruptions during long tasks. Security teams want evidence that command execution, file writes, and external tool access are not bundled into one opaque "the agent handled it" event. v2.1.160 is a file-type-specific compromise inside that tension.

Research is asking similar questions. The April 2026 arXiv paper Measuring the Permission Gate: A Stress-Test Evaluation of Claude Code's Auto Mode treats auto mode as a permission gate and evaluates how the classifier handles risky tool calls. Another April 2026 analysis, Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems, describes Claude Code as a system made from permission controls, MCP, plugins, skills, hooks, delegation, and session storage. The June 2 releases adjust exactly those surrounding surfaces rather than the core language model.

Teams using Claude Code should check three things after these releases. First, if acceptEdits or auto is part of the normal workflow, test how new prompts behave in CI, remote development, and headless automation. A prompt that is harmless in an interactive terminal can stop an unattended run. Second, if internal documentation includes examples of claude mcp list, claude mcp get, or claude mcp add, update screenshots and runbooks so redacted output is expected. Third, if OpenTelemetry is already configured, decide on a stable naming scheme for OTEL_RESOURCE_ATTRIBUTES before dashboards become inconsistent.

Security teams should avoid over-reading the release as a complete secret-protection feature. Terminal redaction helps, but .mcp.json, environment files, shell history, CI logs, issue attachments, support bundles, and screen recordings are separate exposure paths. MCP credentials should be scoped to the minimum useful permissions, rotated like other service credentials, and kept outside source-controlled config where possible. A redacted CLI output is a guardrail around display, not a credential lifecycle system.

Platform teams may also need clearer policy language. "AI coding tools may edit files automatically" is too broad for an agent that can touch .tsx, .npmrc, .devcontainer/, MCP headers, and shell startup files. A more accurate policy separates ordinary source edits, execution-path changes, credential-bearing configuration, external tool calls, and protected local paths. File extension alone is a weak policy boundary. The question is what the file can cause the machine or the agent to do next.

There is still a user-experience tradeoff. More prompts can make developers choose stronger bypass modes, especially during long migrations or repetitive chores. Claude Code recognizing single-file grep as a read-before-edit signal points in the right direction because it removes friction from a low-risk action. The quality of a permission system depends less on how severe the warning sounds and more on whether the question appears at the exact point where risk changes.

These releases are not a benchmark announcement, a model launch, or a new named agent feature. They are lower-level product changes in the operating surface of AI coding. That surface now includes shell startup files, build configuration, MCP secrets, terminal output, telemetry labels, and background sessions. As coding agents become part of everyday development environments, these small controls may matter as much as the model picker.

Claude Code 2.1.160 and 2.1.161 leave teams with practical questions. Which file types should automatic edit approval cover? Which configuration files require a human approval step because they can alter execution? Where do MCP secrets live, and what is safe to print? Which team, repository, and environment labels should appear in usage metrics? AI coding-tool operations are starting to look less like a prompt guide and more like a local permission table, credential policy, and observability plan.