Skjulte innstillinger i Claude Code – hva kildekoden avslører

Claude Code-dokumentasjonen forteller deg ikke halvparten. Noen leste nylig gjennom hele kildekoden til Claude Code versjon 2.1.87 og fant en hel serie konfigurasjonsalternativer, hook-felt og agent-parametere som ikke finnes noe sted i de offisielle Anthropic-sidene. Mye av dette er faktisk i bruk, bare udokumentert.

Jeg har gått gjennom funnene og samlet det som faktisk er nyttig å vite i hverdagen – enten du er hobbyist eller bruker Claude Code profesjonelt. Noen av disse tingene endrer ganske mye av hvordan verktøyet oppfører seg.

Her er hva kildekoden avslørte.

Hva er egentlig hooks i Claude Code?

Hooks er skript som kjører automatisk på bestemte tidspunkter under en Claude Code-sesjon – før et verktøy brukes, etter at et verktøy er ferdig, eller ved sesjonstart. De lar deg programmere inn logikk som bestemmer hva Claude får lov til å gjøre, eller injisere ekstra kontekst i samtalen.

Det som ikke er dokumentert godt nok, er hvilke felt hookene faktisk støtter. En PreToolUse-hook kan for eksempel returnere JSON med feltet updatedInput – noe som lar deg skrive om verktøyparametere før Claude sender dem. Det er kraftig. Du kan for eksempel tvinge all filskriving til en bestemt mappe, uavhengig av hva Claude prøver å gjøre.

Andre støttede felt i PreToolUse:

• permissionDecision: "allow" eller "deny" – bestem utfallet programmatisk uten at brukeren spørres
• permissionDecisionReason: En tekst som forklarer beslutningen i UI-et
• additionalContext: Injiser tekst rett inn i samtalehistorikken

For SessionStart-hooks finnes det et felt kalt watchPaths som setter opp automatisk filmonitorering. Og initialUserMessage lar deg prepende innhold til den første meldingen i en sesjon – nyttig for å sette kontekst automatisk uten å legge det i CLAUDE.md.

Tre hook-felt som mangler helt fra dokumentasjonen

Dette er det mest interessante funnet: kildekoden inneholder tre hook-konfigurasjonsparametere som ikke er nevnt noe sted i Anthropic-dokumentasjonen.

once: true gjør at hooken kjører nøyaktig én gang og deretter fjerner seg selv. Perfekt for førstegangskjøring – setup-logikk som bare skal trigge første gang du åpner et prosjekt.

async: true kjører hooken i bakgrunnen uten å blokkere Claude. Nyttig for logging eller varsling der du ikke trenger å vente på resultatet.

asyncRewake: true er det meste sofistikerte alternativet. Den kjører async som normalt, men hvis exit-koden er 2, blokkerer den likevel. Med andre ord: la den kjøre i bakgrunnen, men si ifra hvis noe går galt.

Du setter disse feltene direkte i hook-konfigurasjonen i .claude/settings.json. Det er ikke mye, men det gir deg langt mer kontroll enn hva dokumentasjonen skulle tilsi. Jeg har tidligere skrevet om auto-mode og hvordan Claude Code håndterer tillatelser – disse hook-feltene bygger videre på akkurat den logikken.

Skjulte felt i skills og agenter

Skill-filer (SKILL.md) støtter mer enn det Anthropic dokumenterer. Frontmatter-seksjonen kan inneholde:

• model: haiku eller model: opus – overstyr hvilken modell som brukes for akkurat denne skillen
• effort: low / medium / high / max – kontroller resonnementsdybde
• hooks: scope hooks til å bare gjelde under skill-kjøring
• agent: deleger skill-en til en egendefinert agent
• disable-model-invocation: true: krever eksplisitt /skill-name-kall, ingenting automatisk
• shell: bash: spesifiser hvilken shell som brukes

For agenter (.claude/agents/*.md) finnes det lignende udokumenterte frontmatter-felt. color lar deg sette UI-farge (red, orange, yellow, green, blue, purple, pink, gray). omitClaudeMd: true skiper hele CLAUDE.md-instruksjonsstrukturen for agenten – nyttig hvis du vil ha en agent som ikke er farget av prosjektkonteksten.

requiredMcpServers blokkerer agenten hvis en MCP-avhengighet ikke er tilgjengelig – noe som er langt bedre enn at agenten prøver å kjøre og feiler halvveis gjennom. Og context: fork lar deg kjøre agenten som en bakgrunns-subagent med delt prompt cache.

Det er litt mye på én gang, men summen av det er at du kan bygge ganske sofistikerte arbeidsflyter. Jeg har sett Claude.md-konfigurasjon kutte output med 63 prosent – disse agentfeltene gir deg enda finere kontroll.

Auto-mode og miljøbeskrivelser

Auto-mode (eller YOLO-modus som den kalles internt) kan konfigureres via settings.json med et autoMode-objekt. Den dokumenterte delen handler om allow– og deny-lister. Det udokumenterte er environment-arrayen.

environment tar imot fritekst-setninger på engelsk som beskriver kjøremiljøet ditt:

"environment": [
  "Local dev machine with no production database",
  "All Docker containers use isolated networks"
]

Dette er ikke bare metadata – disse setningene mater inn i klassifikatoren som bestemmer om en handling er trygg, tvetydig eller blokkert. Med andre ord: jo bedre du beskriver miljøet ditt, jo smartere blir automatiske tillatelsesavgjørelser. Det er akkurat dette som gjør auto-mode praktisk i stedet for farlig.

Læringsløkke – automatisk hukommelse

To innstillinger i settings.json aktiverer automatisk læringsatferd:

autoMemoryEnabled: true gjør at Claude Code automatisk trekker ut varige minner fra sesjoner. Ting den anser som nyttig å huske, skrives til minnefiler uten at du trenger å si noe.

autoDreamEnabled: true er mer eksotisk: den konsoliderer minner hver 24. time etter at 5 eller flere sesjoner har akkumulert. Tenk på det som en nattlig oppryddsrutine.

Begge disse er udokumenterte. Det er verdt å vite de eksisterer, særlig autoMemoryEnabled – den kan begynne å skrive til minnefiler uten at du skjønner hvorfor.

MAGIC DOC – automatisk vedlikehold av dokumentasjon

Dette er det rareste funnet. Hvis en markdown-overskrift matcher mønsteret # MAGIC DOC: Navn på dokument, setter Claude Code opp automatisk vedlikehold av det dokumentet. En valgfri kursiv linje under overskriften begrenser hva den automatiske oppdateringsagenten fokuserer på:

# MAGIC DOC: API Endpoint Reference
_Bare dokumenter publiserte REST-endepunkter_

(innhold vedlikeholdes automatisk av Claude Code)

Praktisk bruk: API-referanser, avhengighetsoversikter, konfigurasjonslogg – alt som endres jevnlig og som er tidkrevende å holde oppdatert manuelt.

Full mønster-syntaks for tillatelsesregler

Dokumentasjonen viser enkle eksempler på allow– og deny-regler. Kildekoden viser at syntaksen er mer komplett enn det:

• Bash(npm *): wildcard-matching inni kommandoen
• Read(*.ts): filtrer på filtype
• Read(src/**/*.ts): rekursiv mappefiltrering
• mcp__slack__post_message: MCP-verktøy med dobbel understrek

Hvis du har brukt planleggingsmodus og output-stiler tidligere, er dette det naturlige neste steget – du kan nå være mye mer presis på hva Claude faktisk har lov til.

Hva betyr dette i praksis?

De fleste av disse innstillingene er ikke noe du aktiverer og glemmer. De er byggesteiner for å lage et arbeidsoppsett som faktisk passer til det du driver med.

Startpunktet er enkelt: legg til environment-feltet i autoMode-konfigurasjonen og beskriv dev-maskinen din med noen setninger. Det alene forbedrer tillatelseslogikken merkbart. Neste skritt er å prøve once: true på en hook du vil kjøre ved prosjektoppstart – det er den typen ting som ellers krever ekstern skripting.

Det er litt oppsiktsvekkende at dette ikke er dokumentert. Anthropic er vanligvis gode på dokumentasjon. Muligheten er at disse funksjonene er i aktiv utvikling og dokumentasjon kommer, eller at de simpelthen har havnet i blindsonen. Uansett: nå vet du det finnes.

Verdt å merke seg: funnene gjelder versjon 2.1.87 (les hele analysen her). Udokumenterte felt kan forsvinne mellom versjoner uten varsel, særlig alt som er merket EXPERIMENTAL i kildekoden. Claude Code er likevel langt foran konkurrentene på denne typen konfigurasjonsdybde.