Claude Code tettet et stille hull i sandkassen: denyRead med skråstrek på slutten kunne omgås

Endringsloggen til Claude Code fører feilen opp under versjon 2.1.224, som ble sluppet 7. august: deny-oppføringer for filsystemet i sandkassen, skrevet på formen denyRead: "~/.aws/", lot seg omgå uten at noe stoppet eller varslet. Regelen så riktig ut i innstillingene, men skråstreken på slutten gjorde at den ikke traff.

To andre rettelser i samme versjon handler om det samme: grenser du ikke kan se. Detaljer om sandkassebrudd nådde aldri frem i resultatet fra Bash-verktøyet, så modellen fikk aldri vite hvilken fil eller nettverkstilgang som ble nektet, og fortsatte å prøve. Prosjektstier på over 200 tegn kunne dessuten løses opp til et annet prosjekts sesjonskatalog under et felles forkortet prefiks, slik at listing, omdøping, forking, sletting og /resume krysset prosjektgrensen.

Samme versjon la inn maskering av legitimasjon i sandkassen: extract og onExtractNoMatch for strukturerte miljøverdier, decode: "jwt" med maskClaims for JWT-er, og awsPairs/sigv4 som signerer AWS-forespørsler på nytt. Valgene krever network.tlsTerminate, og de leses kun fra bruker-, administrerte eller --settings-innstillinger. En prosjektfil i repoet kan altså ikke skru dem av. I tillegg falt taket på 200 underagenter per økt bort.

Sandkassen er en av få grensene som står mellom en kodeagent og hemmelighetene på maskinen din, og den brukes mest av dem som kjører agenten med tillatelser slått av. En regel som feiler stille er verre enn ingen regel, fordi du slutter å følge med. Anthropic har sluppet to versjoner etter dette, 2.1.225 og 2.1.226, begge 8. august.

Hva bør du gjøre?

1. Oppgrader til minst 2.1.226 og bekreft med claude --version.
2. Gå gjennom denyRead- og denyWrite-oppføringene dine og test at en sti med skråstrek på slutten faktisk blir nektet.
3. Legg maskeringen der den faktisk leses, i bruker- eller administrerte innstillinger, ikke i prosjektets egen settings-fil.