Claude Code 2.1.160 turns some files into approval points

The most useful part of Claude Code 2.1.160 is not a new giant agent mode. It is a brake. Claude Code now asks before it writes to shell startup files such as .zshenv, .zlogin, and .bash_login, to ~/.config/git/, and before acceptEdits writes build or tool configuration files that can grant code execution, including .npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, and .devcontainer/.

Source: Claude Code changelog 2.1.160 and the npm registry entry for @anthropic-ai/claude-code

Some files are doors, not documents

A shell startup file can run when a terminal starts. A build configuration can change what happens when someone installs packages, runs tests, opens a devcontainer, or starts a pre-commit flow. Those files deserve a different review path than an ordinary component file.

For small teams, the signal is practical: if an AI agent may help inside repositories, documents, MCP servers, or local tools, you need to know which files merely describe work and which files can start work.

What changed in Claude Code

Claude Code 2.1.160 includes several useful fixes for background sessions, Windows/WSL, and the agent view. The bigger workflow lesson is the protection around files with side effects:

• Claude Code adds a prompt before writing to some shell startup files and ~/.config/git/.
• acceptEdits asks before writing build-tool files that can grant code execution.
• Resumed background sessions should no longer lose history and re-run the original prompt.
• The trigger keyword for dynamic workflows changes from workflow to ultracode, so the word "workflow" in normal text should no longer accidentally start that kind of run.

This is not just a Claude Code detail. It is a good rule for agentic automation in general: automatic approval is best for low-risk work. Files that affect runtime, permissions, installation, or commands need their own gate.

A small routine to add this week

Create a short protected-file list before you let AI make more automatic changes:

• Put shell startup files, Git configuration, package manager settings, pre-commit, devcontainer, and CI files in a protected category.
• Decide who can approve changes in that category.
• Require the agent to explain which runtime behavior or permission changes before you accept the diff.
• Keep secrets in environment variables or a secret manager. Use scoped API keys when tools need access.
• Save a short change line: which file changed, why, who approved it, and how it was tested.

That is the kind of routine we build in Tool Forge: AI gets real tools, but with clear boundaries, logs, and human review where it matters.

Try this prompt this week

Make your own protected-file list first. Then ask Claude Code to inspect the project before it changes anything:

Inspect this repository's setup files before making changes.
List files that can affect install, shell startup, tests, pre-commit, containers, CI, or tool permissions.
Classify which files are safe for routine edits and which need human approval.
For protected files, propose the diff and explain the runtime effect before writing.
Do not edit protected files until I approve that specific change.

The point is not to stop the agent. The point is to let it do useful work without moving the safety gate to the wrong side of the change.