Claude Code 2.1.160 gör vissa filer till godkännandepunkter

Det mest användbara i Claude Code 2.1.160 är inte ett nytt stort agentläge. Det är en broms. Claude Code frågar nu innan den skriver i shell-startfiler som .zshenv, .zlogin och .bash_login, i ~/.config/git/, och innan acceptEdits skriver i bygg- och verktygskonfigurationer som kan ge kodkörning, till exempel .npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml och .devcontainer/.

Källa: Claude Code changelog 2.1.160 och npm-registret för @anthropic-ai/claude-code

Vissa filer är dörrar, inte dokument

En shell-startfil är en fil som kan köras när terminalen startar. En byggkonfiguration kan påverka vad som händer när någon installerar paket, kör tester, öppnar en devcontainer eller startar ett pre-commit-flöde. Det är därför de här filerna förtjänar en annan sorts granskning än en vanlig komponentfil.

För små team är signalen ganska konkret: om en AI-agent får hjälpa till i kodbaser, dokument, MCP-servrar eller lokala verktyg behöver ni veta vilka filer som bara beskriver arbete och vilka filer som kan starta arbete.

Vad som ändrades i Claude Code

Claude Code 2.1.160 innehåller flera praktiska korrigeringar för bakgrundssessioner, Windows/WSL och agentvyn. Den största arbetsflödespoängen är ändå skyddet runt filer med sidoeffekter:

• Claude Code lägger in en prompt innan den skriver i vissa shell-startfiler och ~/.config/git/.
• acceptEdits frågar innan den skriver i byggverktygsfiler som kan ge kodkörning.
• Bakgrundssessioner som återupptas ska inte längre tappa historik och köra om den ursprungliga prompten.
• Startordet för dynamiska workflows byts från workflow till ultracode, så ordet "workflow" i vanlig text ska inte längre råka starta den typen av körning.

Det här är inte bara en Claude Code-detalj. Det är en bra minnesregel för all agentisk automation: automatiskt godkännande passar bäst för låg risk. Filer som påverkar körmiljö, behörigheter, installation eller kommandon ska ha en egen grind.

En enkel rutin att införa den här veckan

Gör en liten skyddslista innan ni låter AI göra fler ändringar automatiskt:

• Lägg shell-startfiler, Git-konfiguration, pakethanterarinställningar, pre-commit, devcontainer och CI-filer i en skyddad kategori.
• Bestäm vem som får godkänna ändringar i den kategorin.
• Kräv att agenten förklarar vilken körning eller behörighet som påverkas innan diffen accepteras.
• Lägg hemligheter i miljövariabler eller en hemlighetshanterare. Använd avgränsade API-nycklar när verktyg behöver åtkomst.
• Spara en kort ändringsrad: vilken fil, varför den ändrades, vem som godkände och hur den testades.

Det är den typen av rutin vi bygger i Tool Forge: AI får verkliga verktyg, men bara med tydliga gränser, loggar och mänsklig granskning där det spelar roll.

Testa den här prompten i veckan

Gör först din egen lista över skyddade filer. Be sedan Claude Code läsa projektet innan den ändrar något:

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.

Poängen är inte att stoppa agenten. Poängen är att låta den göra nyttigt arbete utan att råka flytta säkerhetsgrinden till fel sida av ändringen.