Men etter en måned med reell bruk støtte jeg på et par solide problemer som det innlegget ikke dekket. Det største — en skjult særegenhet ved Claude Code som jeg ved et uhell tråkket midt oppi, da jeg la til Gmail-MCP-en og den "forsvant" fra profilen min fem minutter senere. I dag bygde jeg alt om til en ny arkitektur — XDG-kompatibel, med en symlink og en interaktiv profilvelger via gum. Dette er v2 — en evolusjon ut av reell erfaring, ikke en teoretisk forbedring.

Det som begynte å skurre

Fire ting. De tre første handler om ryddighet, synlighet og skala. Den fjerde er den ekte arkitektoniske fellen jeg ikke så med en gang. Jeg går gjennom dem i rekkefølge, fordi det er nettopp den fjerde som til slutt tvang frem ombyggingen.

1. To separate mapper i $HOME — det er rotete

~/.claude og ~/.claude-promova — to dotfolders side om side i roten av $HOME. XDG Base Directory Specification sier at configs hører hjemme i ~/.config/. Dotfile-mapper strødd rett i home er et antimønster som over tid gjør $HOME til en rotekrok. Kosmetisk, ja, men det irriterte hver gang jeg så ls -la ~.

2. Ingen visuell bekreftelse på aktiv profil

Jeg starter claude og vet ikke hvilken profil som er aktiv — før jeg kjører claude config list inne i sesjonen. Hvis jeg glemte hvilken terminal jeg startet hvor, må jeg sjekke. En bagatell, men med personal + work i parallell i to faner samler det seg opp.

3. Alias skalerer ikke

To profiler — claude og claude-promova — det er greit. Jeg legger til en tredje (en frilanskunde) — da trengs et tredje alias. En fjerde — et fjerde. Etter et halvt år ville jeg ikke huske hvilke aliaser jeg faktisk hadde opprettet.

4. Den skjulte fellen i ~/.claude.json

Og dette er den egentlige grunnen til ombyggingen. Claude Code har to forskjellige steder for konfigurasjon, og dokumentasjonen roper det ikke ut: ~/.claude/ — katalogen der projects/, sessions/, hooks/, skills/ ligger. Og separat — ~/.claude.json, en fil rett i $HOME-roten, der oauthAccount, mcpServers, projects-historikken, skillUsage og rundt 40 andre felt av ekte live state bor.

Kommandoen claude mcp add --scope user skriver akkurat til ~/.claude.json i home-roten, og ikke til ~/.claude/.claude.json eller til profilens katalog. Det visste jeg ikke. Helt til jeg en dag tråkket rett i det.

Discovery: hvorfor Gmail-MCP-en "forsvant"

I dag tidlig satt jeg opp Gmail-MCP-en i Claude Code. Standard oppsett: Google Cloud-prosjekt, OAuth-credentials, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Alt OK. Startet sesjonen på nytt — virker, jeg leser mail, svarer på meldinger. En time senere begynte vi å refaktorere aliasene til en funksjon med gum-profilvelger, og deretter flyttet vi alt over til XDG. Jeg kjørte mv ~/.claude → ~/.config/claude-profiles/personal, startet CC på nytt, valgte personal i menyen. Og i den nye sesjonen åpnet jeg /mcp:

figma            (failed)
playwright-test
claude.ai Notion

Ingen gmail. Ingen vaultforge. Bare tre servere, hvorav én til og med var failed. Og jeg hadde nettopp lagt til Gmail. Samtidig viste sesjonen i en annen terminal (work-profilen) Gmail og Vaultforge uten noe problem.

Jeg begynte å grave og fant at jeg på maskinen hadde tre ulike filer med navnet .claude.json:

Der hadde vi det. Det er nettopp det som er den arkitektoniske fellen:

1. claude mcp add --scope user skriver alltid til ~/.claude.json i home-roten, uavhengig av CLAUDE_CONFIG_DIR
2. Når CLAUDE_CONFIG_DIR er satt, leser Claude Code $CLAUDE_CONFIG_DIR/.claude.json — altså filen inne i profilen
3. Oppføringene for "user-scope MCPs" og "profilens MCPs" bor i forskjellige filer med samme navn — og det er lett å blande dem

I mitt tilfelle var ~/.claude.json (home-roten, 113 KB) den levende, aktuelle tilstanden — med gmail, vaultforge, OAuth-sesjonen, alt. Og ~/.config/claude-profiles/personal/.claude.json (29 KB) viste seg å være en gammel snapshot som av en eller annen grunn allerede tidligere lå i gamle ~/.claude/ — kanskje skrev en eldre CC-versjon dit, kanskje et plugin. jq -r 'keys[]' på begge filene viste at home-root-versjonen hadde 41 unike nøkler som ikke fantes i snapshoten.

Og de 41 nøklene er ikke søppel. Det er Claude Codes virkelige tilstand:

• skillUsage — bruksstatistikk for skills
• githubRepoPaths — repo-cache for prosjektnavigering
• cachedGrowthBookFeatures + cachedStatsigGates — feature flags (uten dem henter CC ferske ved hver oppstart)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — UI-flagg (uten dem dukker modalene opp igjen ved neste oppstart)
• lastPlanModeUse, feedbackSurveyState, installMethod — onboarding- og UX-state

Hvis du bare kjører mv ~/.claude ~/.config/claude-profiles/personal uten merge — mister du alt dette. Du ser welcome-modalene igjen, githubRepoPaths-søket kjører på nytt, alle survey-spørsmålene kommer tilbake. Som jeg nesten gjorde.

Den nye arkitekturen

Alt bor under én felles foreldrekatalog i ~/.config/, slik XDG vil ha det. Hver profil er selvstendig — den har sin fulle state inkludert sin egen .claude.json. ~/.claude blir igjen som symlink til personal-profilen for bakoverkompatibilitet.

~/.config/claude-profiles/
├── personal/
│   ├── .claude.json          ← full live state + MCP list (113 KB)
│   ├── projects/, sessions/, hooks/, skills/, ...
│   └── CLAUDE.md
└── promova/
    ├── .claude.json          ← work state + work MCPs (41 KB)
    └── projects/, sessions/, agents/, skills/, ...

~/.claude  →  symlink to ~/.config/claude-profiles/personal/

Ingen .claude.json i $HOME-roten. Hver profil er en separat, isolert katalog der alt ligger: projects/sessions-mappene og den samme filen med MCP-servere og OAuth-tokens. Én source of truth per profil.

Hvorfor symlinken peker på personal

Alt som hardkoder stien ~/.claude/ — gamle skript, plugins, IDE-utvidelser for Claude Code, statusline-configs som claude-powerline.json — fortsetter å virke uten endringer. Symlinken løses opp til personal-profilen. Hvis du ved et uhell kjører command claude (uten wrapper-funksjonen) — havner du også i personal via default-path lookup. Personal blir den "quiet default" den var før, men bor nå fysisk på XDG-plassen.

Interaktiv velger ved oppstart — funksjon + gum

I stedet for aliaser — en funksjon claude() i ~/.zshrc som viser en pilmeny via gum (Charm sin TUI-hjelper). Funksjonen fanger opp claude-kallet på shell-nivå, lar deg velge profil og kjører command claude med tilhørende CLAUDE_CONFIG_DIR. command er viktig — det går utenom wrapper-funksjonen og kaller den ekte binærfilen.

# brew install gum

# Claude Code: profile picker on launch
claude() {
  local profile
  profile=$(gum choose \
    --header "Claude profile:" \
    --cursor "▸ " \
    --selected.foreground 212 \
    --cursor.foreground 212 \
    --header.foreground 244 \
    "personal" "promova") || return
  case "$profile" in
    personal) CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/personal" command claude "$@" ;;
    promova)  CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/promova"  command claude "$@" ;;
  esac
}

Slik ser det ut ved oppstart:

Claude profile:
▸ personal
  promova

↑↓ for å navigere, Enter for å velge, Esc for å avbryte (Claude starter rett og slett ikke). Profilen er alltid synlig — umulig å gå glipp av.

Migreringsskript

For den som leser dette og vil flytte fra det gamle oppsettet. Det mest kritiske steget er det andre: det merger ~/.claude.json fra home-roten med det som allerede ligger i personal-profilen, og kombinerer mcpServers-listene. Uten det steget mister profilen både MCP-ene sine og hele live-staten.

# 1. Move existing dotfolders into a new XDG-style parent.
#    APFS mv is an inode rename — safe even if claude --resume is open in
#    another terminal, file descriptors stay alive on the same inode.
mkdir -p ~/.config/claude-profiles
mv ~/.claude          ~/.config/claude-profiles/personal
mv ~/.claude-promova  ~/.config/claude-profiles/promova   # rename as needed

# 2. CRITICAL: merge ~/.claude.json (the live state — likely 100+ KB) into
#    the personal profile, unioning mcpServers so no MCP is dropped.
jq -s '.[0] * {mcpServers: (.[0].mcpServers + .[1].mcpServers)}' \
  ~/.claude.json \
  ~/.config/claude-profiles/personal/.claude.json \
  > /tmp/personal-merged.json
mv /tmp/personal-merged.json ~/.config/claude-profiles/personal/.claude.json

# 3. Fix permissions — jq+mv inherits umask (likely 644), but this file
#    holds OAuth tokens. Tighten to 600 immediately.
chmod 600 ~/.config/claude-profiles/personal/.claude.json

# 4. Back up the orphaned home-root file (delete once verified)
mv ~/.claude.json ~/.claude.json.migrated.bak

# 5. Symlink for backward compatibility (statusline configs, IDE plugins,
#    anything that hardcodes ~/.claude/ keeps working unchanged)
ln -s ~/.config/claude-profiles/personal ~/.claude

Det tredje steget om rettigheter er viktig i seg selv. jq | mv oppretter en fil med umask 644 (world-readable). Inni er det OAuth-tokens. chmod 600 umiddelbart etter mergen er obligatorisk.

Etter migreringen — lukk og åpne alle aktive Claude-sesjoner, last shellet på nytt (source ~/.zshrc eller ny terminal), kjør claude, velg profil, sjekk via claude mcp list at alle MCP-er er på plass. Hvis alt er greit — slett ~/.claude.json.migrated.bak. Hvis noe er galt — rollback er trivielt: mv ~/.claude.json.migrated.bak ~/.claude.json og fjern symlinken.

Det du får

• Én felles foreldrekatalog i stedet for to dotfolders i $HOME — XDG-kompatibelt
• Symlinken bevarer kompatibilitet med alt som hardkoder ~/.claude/
• Hver profil er selvstendig — sin fulle state og sine MCP-er i sin egen .claude.json
• Én source of truth per profil — slutt på foreldreløs config i home-roten som stille driver fra profilens
• Sensitiv data (oauthAccount, tokens) garantert med rettigheter 600
• Visuell bekreftelse på aktiv profil ved hver oppstart — umulig å glemme hvilken profil som er aktiv
• Å legge til en tredje profil = å legge til én linje i case i funksjonen, ikke klone et nytt alias og huske navnet

Der det svikter

Jeg vil være ærlig. Dette er ikke en gratis forbedring — noen kompromisser følger med på kjøpet, og de er verdt å kjenne på forhånd.

• gum er en ekstra avhengighet (brew install gum, ~13 MB). Hvis du av prinsipp ikke vil installere det — fallback til select i zsh eller en enkel read. Funker, men ser ikke like pent ut og mangler pilnavigering.
• En Enter ved hver oppstart. For den som drar i gang claude titalls ganger om dagen — kan irritere. Alternativ under (direnv).
• Symlinken ~/.claude → personal gjør personal til default. Hvis du må ha work-profilen som default — må du peke om symlinken (ln -sf). Ikke vanskelig, men det er ikke "glem det og ingenting ryker".
• Symlinken kan teoretisk ryke hvis et eller annet verktøy atomisk overskriver ~/.claude.json via et temp+rename-mønster (write-file-atomic). I praksis gjør Claude Code det ikke selv, men hvis du installerer tredjepartsplugins — sjekk.
• Hvis du har ulike Anthropic-kontoer på profilene med ulike planer — etter bytte kan det være en sub-sekund lag mens Claude Code synker OAuth-state. I min bruk er det ikke merkbart, men det er ikke null.

Alternativer jeg vurderte

direnv — setter CLAUDE_CONFIG_DIR automatisk basert på en .envrc i roten av hvert prosjekt. Null interaksjon, null klikk. Minus: du må legge en .envrc i hver work-root, og hvis du kjører claude i en ukjent mappe — får du default-profilen (kanskje ikke den du vil ha). For den som lever i et begrenset antall work-roots og vil slippe å klikke — er direnv reelt bedre.

Symlink-basert bytting (én aktiv profil ved å peke om ~/.claude-symlinken) vurderte jeg også og forkastet umiddelbart. Du kan ikke ha to terminaler med ulike profiler åpne samtidig — den globale "gjeldende" er én. For meg er det en deal-breaker.

Konklusjon

v2 er ikke bare bedre UX oppå v1. Det er en erkjennelse av at Claude Code har en skjult arkitektonisk særegenhet (~/.claude.json som en separat fil i home-roten, skrevet av --scope user-kommandoer uavhengig av CLAUDE_CONFIG_DIR) som man må ta hensyn til hvis man vil ha ekte isolasjon mellom profiler. Den første tilnærmingen (~/.claude + ~/.claude-promova + alias) virket til 80 %, men de gjenværende 20 % viste seg som stille state-drift mellom profilene. Nå er det tatt høyde for. Hvis du så vidt begynner — start rett på v2. Hvis du allerede sitter på v1 — migreringsskriptet er over, flyttingen tar fem minutter og bryter ingenting (det er nettopp jq-mergen som redder deg fra å miste state).

To regler har gjort hallusinasjonspregede arbeidsflyter om til pålitelige pipelines for meg: én agent, én spesialisering, og alt som kan kjøres som en shell-kommando må kjøres som en shell-kommando. Dette er ikke teori. Dette er hva jeg gjør hver dag med Claude Code, og det er disse mønstrene som faktisk gjør en forskjell.

Hvorfor generalistagenter lyver

LLM-er er next-token-prediktorer. Når en prompt ber om to roller — bygg X og verifiser X — fullfører modellen den første rollen, og predikerer deretter hvordan utdataene fra den andre rollen ville sett ut, uten å faktisk utføre den. Selvverifisering er strukturelt svak: samme kontekst, samme modell, samme blinde flekker. Bestått på verifisering korrelerer med bestått på bygging — de feiler sammen.

Modellen vet ikke at den lyver. Fra dens perspektiv er jeg verifiserte alt nøye en koherent fortsettelse av å ha skrevet koden. Dette er den samme grunnen til at er du sikker?-prompts ikke fanger opp hallusinasjoner: modellen er like sikker på andre gjennomgang. Selvtillit korrelerer ikke med korrekthet — den korrelerer med hvor plausibelt neste setning høres ut.

Løsningen er ikke bedre prompts. Vær forsiktig, dobbeltsjekk, ikke hallusinér — disse instruksjonene gjør ingenting. Løsningen er strukturell: spesialiser agenten slik at den fysisk ikke kan late som, og rut kvantitativt arbeid gjennom shell-en så svaret kommer fra reell tilstand, ikke fra token-sannsynlighet.

Regel 1: én agent, én spesialisering

Del arbeidet inn i separate agenter med separate kontekster. Hver agent har ett enkelt ansvar og et begrenset verktøysett. Hele arbeidsflyten blir et stafettløp i stedet for én agent som løper runder:

• Builder-agent: tar spekken, skriver koden. Det er hele jobben dens. Den har Read, Edit, Write, Bash.
• Reviewer-agent: tar spekken pluss diff-en, sjekker akseptansekriterier. Frisk kontekst. Ingen kunnskap om hvordan koden ble skrevet, bare hva som kom ut. Den har Bash, Read, Grep, Glob — ingen skriveverktøy overhodet.
• Analytics-agent: svarer på dataspørsmål ved å konstruere og kjøre queries. Kun Bash. Kan ikke nå svaret uten å kjøre en ekte kommando.
• Orchestrator: hovedsesjonen som sender ut hver agent etter tur og aldri ber én agent gjøre en annens jobb.

Konkret eksempel: UI-implementasjon pluss en visuell sjekk mot en Figma-mockup. Builder-en skriver komponentene og committer diff-en. Orchestrator-en kaller deretter Reviewer-en med design-URL-en, diff-en og eksplisitte akseptansekriterier. Reviewer-en kjører Playwright, tar skjermbilder, differ dem mot referansen og returnerer PASS eller FAIL med de faktiske skjermbildebanene og piksel-diff-ene. Builder-en kommer aldri i nærheten av verifiseringssteget — og det er nøyaktig derfor verifiseringen er ekte.

Anti-mønsteret er mega-agenten: én enkelt prompt som sier bygg dette UI-et og pass på at det stemmer med mockupen. Jeg garanterer deg at den vil rapportere at alt stemmer. Det gjør det ikke. Narrativet om jeg verifiserte er bare den mest sannsynlige tokensekvensen etter jeg bygde det.

Regel 2: shell fremfor prompt, alltid

Alt som er kvantitativt, alt som berører reell tilstand, alt der svaret kan være galt på en måte som ser riktig ut — push det gjennom sh. Agentens jobb er å konstruere og kjøre kommandoen, deretter lese utdataene. Agenten er ikke kilden til sannhet. Shell-utdataene er.

• Telling: wc -l logs.txt er sant. Det er omtrent 47 logglinjer fra en modell er en hallusinasjon.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Ikke estimer volumet.
• Tester: pnpm test --reporter=json | jq '.numFailedTests'. Ikke oppsummer hva som feilet.
• Git-tilstand: git rev-list --count main..HEAD, git diff --stat. Ikke tell committene eller beskriv endringene.

Når du har internalisert dette, begynner du å legge merke til hvert sted der agenten var i ferd med å finne på et tall. Det ser ut til å være rundt 200 poster... — nei. Kjør SELECT count(*). De fleste testene består... — nei. Kjør testsuiten, parse JSON-en. Modellen er utmerket til å konstruere kommandoen. Den er upålitelig som kommandoen.

Feilmodi jeg faktisk har truffet på

Dette er ikke hypotetiske eksempler. Hvert av disse kostet meg reell tid før jeg endret mønsteret:

• Fantomverifisering. Agenten sa jeg sjekket alle 14 seksjoner mot mockupen. Den åpnet ikke mockupen. Den tok ikke et skjermbilde. Sjekken var et hallusinert steg i narrativet.
• Selvsikre gale tall. Spurte om monthly active users fra analysedata. Fikk et tall som var ~3× feil. Modellen interpolerte fra eksempelrader i stedet for å kjøre den faktiske spørringen.
• Oppdiktede filendringer. Agenten sa jeg oppdaterte config/feature-flags.json. Det hadde den ikke. Den hadde bare hatt til hensikt å gjøre det. git diff var tom.
• Falske testkjøringer. Alle tester består. Ingen tester ble kjørt. Agenten kalte aldri testkjøreren — den predikerte hvordan testkjørerens utdata ville ha sett ut.

Alle fire løses av de samme to reglene: del opp agenten, push til shell. Reviewer-en har ikke Write, så den kan ikke fake-redigere filer. Analytics-agenten har bare Bash, så den kan ikke returnere et tall som ikke kom fra en spørring. Strukturell umulighet slår gode intensjoner hver gang.

Slik strukturerer du dette i Claude Code

Claude Code støtter sub-agenter definert i .claude/agents/*.md. Hver agentfil deklarerer et navn, en beskrivelse, et tillatt verktøysett og en systemprompt. Orchestrator-en (din hovedsesjon) sender dem ut med Agent-verktøyet. Her er den typen definisjon jeg bruker for reviewer-en — kort, smal og fysisk ute av stand til å skrive kode:

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

Legg merke til verktøysettet: Bash, Read, Grep, Glob. Ingen Write, ingen Edit, ingen Agent. Reviewer-en kan kjøre kommandoer, lese filer, søke etter mønstre — og ingenting annet. Hvis den prøver å presentere en hallusinert diff som verifisert, gjør formen på verktøykallene det åpenbart: det var ingen ekte sjekker. Du kan auditere verktøykallene og se nøyaktig hva som ble inspisert.

Orkestreringsmønsteret: hovedsesjonen kaller Builder → venter → kjører git diff selv for å fange den faktiske endringen → kaller Reviewer med spekken og diff-en → leser Reviewer-ens kjennelse. Hovedsesjonen ber aldri én agent gjøre begge deler. Verktøybegrensninger er sterkere enn promptinstruksjoner: ikke fake verifiseringen er et ønske. Å ikke ha Write er et faktum.

Anti-mønstre å legge bak seg

Ting jeg ser i prompts som ikke gjør noe — eller verre, gir en falsk følelse av sikkerhet:

• Vær forsiktig og dobbeltsjekk arbeidet ditt. Genererer ingen ekstra atferd. Modellen produserer allerede det som ser ut som forsiktig arbeid.
• Pass på at du faktisk verifiserer. Ordet faktisk tilfører ingen semantikk modellen kan handle på. Den vil faktisk hevde å ha verifisert.
• Ikke hallusinér. En prompt engineering-meme. Hallusinasjon er ikke en bryter modellen kan skru av.
• Å stole på agenten på små tall. Små tall er der den lyver mest selvsikkert. Det finnes ingen nedre grense for ærlighet.
• Å legge til flere regler i prompten for å tvinge ærlighet. Strukturelle fikser (del opp + shell) slår promptjusteringer hver gang. Hvis en regel må håndheves, kode den inn i verktøytilgang, ikke i norsk.

Hvis strategien din for å fange opp hallusinasjoner er mer emfatisk formulering, har du ikke en strategi. Du har et håp.

Den mentale modellen

En agent er ikke en kollega. Det er en funksjon: prompt → tokens. Funksjonen er utmerket til å skrive kode og elendig til å introspektere om den gjorde det riktige. Behandle dens påstander om sitt eget arbeid som en hypotese. Diff-en, exit-koden, skjermbildet, radantallet — det er beviset. Sluttsummeringen er den mest løgnaktige overflaten i hele systemet.

Spesialisering er forsikringen din mot narrativ drift. Shell-en er din eneste ground truth. Builder skriver. Reviewer sjekker. Bash avgjør.

Konklusjon

Hvis du skal huske én ting: ikke la én enkelt agent både produsere og bedømme sitt eget resultat, og ikke la noen agent besvare et kvantitativt spørsmål uten å kjøre en kommando. Alt annet er nedstrøms av disse to reglene. Konfigurer verktøytilgang aggressivt, auditér verktøykall i stedet for oppsummeringer, og hallusinasjonspunkter krymper fra overalt til noen få konkrete steder du allerede vet å sjekke.

Problemet

Claude Code lagrer alt i ~/.claude som standard — OAuth-token, samtalehistorikk, global CLAUDE.md, prosjektminne, MCP-serverkonfigurasjoner og innstillinger. Med to kontoer trenger du to helt adskilte verdener:

• Personlig konto: eget Max/Pro-abonnement, personlig CLAUDE.md med dine preferanser, dine MCP-servere (Obsidian, personlige verktøy)
• Bedriftskonto: bedriftsplan, arbeids-CLAUDE.md med Jira/Slack-integrasjonsinstruksjoner, bedriftens MCP-servere
• Ulike OAuth-sesjoner: du kan ikke være logget inn på to kontoer i samme konfigurasjonskatalog
• Separat prosjektminne: du vil ikke at arbeidskontekst lekker inn i personlige sesjoner og vice versa

Å logge ut og inn hver gang du bytter kontekst er ikke et alternativ. Du mister sesjonstilstanden, og det er rett og slett smertefullt.

Løsningen: CLAUDE_CONFIG_DIR

Claude Code respekterer én enkelt miljøvariabel: CLAUDE_CONFIG_DIR. Sett den til hvilken som helst bane, og Claude bruker den katalogen istedenfor ~/.claude for alt — auth, historikk, innstillinger, minne. Hele oppsettet tar 60 sekunder.

Steg 1: Opprett en andre konfigurasjonskatalog

Velg et navn som passer ditt brukstilfelle:

mkdir ~/.claude-work

Ferdig. Claude fyller den med nødvendig struktur ved første oppstart.

Steg 2: Autentiser den andre kontoen

Kjør Claude én gang med den nye konfigurasjonskatalogen for å trigge OAuth-innlogging:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Nettleseren åpnes. Logg inn med bedriftskontoen. OAuth-tokenet lagres i ~/.claude-work — helt adskilt fra din personlige sesjon i ~/.claude.

Steg 3: Legg til et shell-alias

Legg dette til i shell-konfigurasjonen din så du slipper å huske variabelen:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Last inn shell på nytt:

source ~/.zshrc

Hva du får

Nå har du to helt isolerte Claude-miljøer:

• claude — starter med personlig konto, personlig CLAUDE.md, personlig minne
• claude-work — starter med bedriftskonto, arbeidsspesifikk CLAUDE.md, separat minne
• Isolert historikk: arbeidssamtaler forblir i arbeid, personlige forblir personlige
• Separate MCP-servere: din personlige Obsidian vault MCP vises ikke i arbeidssesjoner
• Uavhengige innstillinger: ulike tillatte verktøy, ulike tilgangsnivåer, ulike modellpreferanser per konto

Hvordan det fungerer under panseret

Konfigurasjonskatalogen er den eneste sannhetskilden for Claude Codes tilstand. Her er hva som lever inni hver:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

Når du kjører claude-work, leser Claude alt fra ~/.claude-work. Den vet ikke at ~/.claude eksisterer. De to instansene er helt uavhengige — du kan til og med kjøre dem samtidig i ulike terminalfaner.

Skalering til N kontoer

Mønsteret utvides til et vilkårlig antall kontoer. Frilanser med flere kunder? Legg til flere alias:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Hvert alias får sin egen konfigurasjonskatalog, sin egen OAuth-sesjon, sin egen CLAUDE.md med kundespesifikke instruksjoner.

Praktiske tips

• Navngi kataloger tydelig: ~/.claude-work, ~/.claude-clientname — du takker deg selv når det er tre eller fire
• Skriv tilpasset CLAUDE.md for hver: arbeids-CLAUDE.md kan inkludere bedriftsspesifikke instruksjoner (Jira-tickets, Slack-kanaler, deployment-prosedyrer). Den personlige forblir slank.
• Ulike MCP-servere per konto: konfigurer arbeidsverktøy (Jira MCP, Slack MCP, interne API-er) kun i arbeidskonfigurasjonen. Hold din personlige ren.
• Sjekk hvilken konto som er aktiv: kjør claude config list i en sesjon om du er usikker — viser banen til konfigurasjonskatalogen

Der denne tilnærmingen ikke strekker til

CLAUDE_CONFIG_DIR isolerer per konto, ikke per prosjekt. Inne i én enkelt profil ser Claude hver MCP-server du noen gang har registrert for den kontoen — på tvers av alle prosjektene dine. For ren personlig bruk er det som regel greit. I det øyeblikket du har flere produksjonskritiske prosjekter under én konto, særlig i overlappende domener som fakturering, adminverktøy eller infrastruktur, introduserer det en konkret risiko mellom prosjekter: en KI-assistent kan kalle et verktøy fra prosjekt A mens den jobber med prosjekt B, spesielt når begge eksponerer likt navngitte operasjoner.

Profilmønsteret svarer på spørsmålet which account am I in?. Det svarer ikke på spørsmålet which project's tools should be active right now?. For arbeid med høyere innsats, stable et nytt isolasjonslag oppå konto-delingen:

• Én profil per produksjonskritisk prosjekt, ikke bare per konto: istedenfor ~/.claude og ~/.claude-work, opprett ~/.claude-work-billing og ~/.claude-work-admin. Hver profil ser bare de MCP-serverne den faktisk trenger.
• Prosjekt-scope MCP via .mcp.json: commit en .mcp.json i prosjektroten som lister bare det prosjektets MCP-servere. Claude plukker dem opp når den startes fra den katalogen. Hold den globale konfigurasjonen minimal — bare universelle verktøy (notater, søk), ingen produksjonsendepunkter.
• Navngi MCP-servere utvetydig: unngå generiske navn som admin, billing, mcp-server. Prefiks med prosjektet: acme_billing_prod, acme_admin_stage. Et beskrivende navn tvinger fram en pause når noe er i ferd med å bli kalt fra feil kontekst.
• Gå gjennom hvert MCP-verktøyskall før godkjenning: kall som *_create_*, *_delete_*, *_charge_* fortjener et bevisst andre blikk. Hvilken hastighet du enn vinner på generell auto-godkjenning fordamper første gang et verktøy fra feil prosjekt avfyres mot produksjon.

Den generelle regelen: del opp profiler aggressivt, hold produksjonsklar MCP unna default-profilen, og behandle overlapp i verktøysnavn mellom prosjekter som en smell verdt å refaktorere.

Konklusjon

Én miljøvariabel. Ett alias. Full isolasjon mellom kontoer. Ingen logout/login-dans, ingen konfigurasjonskonflikter, ingen kontekstlekkasje. Den typen løsning som er nesten skuffende enkel — men det er nettopp det som gjør den god. Sett opp én gang og tenk aldri på det igjen.

Hva er MCP og hvorfor det ikke er så enkelt

MCP (Model Context Protocol) er en åpen protokoll fra Anthropic som lar Claude koble seg til eksterne verktøy og data. Prinsippet er enkelt: en lokal server kjører, eksponerer "verktøy" (tools), og Claude kaller dem under samtalen.

For Obsidian finnes det teoretisk mange MCP-servere. I praksis — hver har sine egne problemer.

Hovedproblemet med Obsidian-økosystemet: Obsidian er en lukket applikasjon uten offisiell MCP. Fellesskapet fylte gapet, men hver implementasjon går sin egen vei, og ingen har "offisiell velsignelse".

Forsøk 1: MarkusPfundstein/mcp-obsidian

Første verktøyet som dukker opp ved søk. 3 400 stjerner på GitHub, med i alle tutorials. Virker som et trygt valg.

Hvordan det fungerer: Python-server basert på Local REST API-pluginet i Obsidian. Serveren kommuniserer med pluginet via HTTPS, pluginet utfører operasjoner gjennom Obsidian API.

Hva som gikk galt

• Ikke oppdatert på 17 måneder
• 85 åpne issues
• Ingen move/rename — bare read, write, append, delete
• Local REST API har en dokumentert datatap-bug: POST-endpoint kan stille overskrive en fil ved append

Ikke egnet for refaktorering — vi trenger å flytte filer og bevare lenker. Vi går videre.

Forsøk 2: aaronsb/obsidian-mcp-plugin

Fant et alternativ som fungerer som et nativt Obsidian-plugin. Det betyr direkte tilgang til Obsidians interne API — backlinks, Dataview, lenkegraf. Move via det native API-et oppdaterer alle wiki-lenker automatisk, fordi Obsidian håndterer dette selv.

Installasjonsvanskeligheter

• Pluginet er ikke i Obsidians offisielle katalog (PR venter med valideringsfeil)
• Må installeres via BRAT (Beta Reviewers Auto-update Tool)
• Claude Desktop aksepterer ikke Bearer token direkte via UI — tvang aktivering av HTTPS i pluginet
• Self-signed sertifikat for localhost skaper tillitsproblemer

Gjennom alle disse omveiene fikk jeg det endelig koblet til. Grunntest — vault.move skriver om [[wikilinks]], fungerer som forventet.

Hva som gikk galt i produksjon

Da jeg begynte massrefaktorering (drag-and-drop av dusinvis av mapper i Obsidian + samtidige MCP-operasjoner), hang serveren i 4+ minutter. Hvorfor: pluginet kjører inne i Obsidian. Når Obsidian omindekserer tusenvis av filer etter en massiv strukturendring, blokkeres pluginet med det.

Konklusjon: avhengigheten av en åpen Obsidian-instans og dens indeks er fatal for masseoperasjoner.

Forsøk 3: @bitbonsai/mcpvault

Logisk — vi trenger en server som ikke er avhengig av Obsidian. Jobber direkte med filer på disk. @bitbonsai/mcpvault — anbefalt i mange anmeldelser. Direkte filsystemtilgang, enkel oppsett (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 verktøy. Obsidian trenger ikke engang å være åpent.

Før installasjon sjekket jeg én kritisk ting — om wiki-lenker oppdateres ved move. Fant en brukeranmeldelse:

Filesystem-tilkoblingen vet ikke at den er i Obsidian — den ser en mappe med <code>.md</code>-filer og det er alt. Vet ikke at filnavn bærer semantisk vekt, at hver <code>[[wikilink]]</code> vil gå i stykker i det øyeblikket du gir nytt navn eller flytter. Auto-update links fungerer bare når navneendringen skjer innenfra appen. Jeg lærte dette etter å ha bedt Claude rydde opp i filnavn og kom tilbake til et dashboard med halvparten av lenkene ødelagt.

Bekreftet i mcpvaults egen dokumentasjon: PR #101 (wiki link resolution) er under review, ikke merget. Så å flytte via mcpvault ville ødelegge halve vaultet. Ikke egnet.

Forsøk 4: VaultForge (Final)

blacksmithers/vaultforge — spesielt bygget for AI-agenter som gjør refaktorering.

Arkitektonisk korrekt

• Direkte filsystem — ikke avhengig av Obsidian
• Egen wikilink-motor — implementerer [[wikilink]]-oppløsningslogikk som oppdaterer alle former (stem, full sti, alias, embed)
• Dry run som standard på alle destruktive operasjoner — viser først hva som endres, så bekrefter du
• 27 verktøy mot 8–14 hos konkurrenter: batch_rename, update_links, backlinks (impact analysis), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF clustering)
• MIT-lisens, TypeScript, null underavhengigheter
• Installasjon på 30 sekunder via .mcpb (one-click-utvidelse for Claude Desktop)

Sikkerhetstest på isolerte filer

Opprettet 4 testfiler med krysslenker — stem-lenker, lenker med alias, lenker med full sti. Flytter én fil til en undermappe:

delta.md → subfolder/delta-renamed.md

VaultForge viste en dry run: "1 fil vil bli omdøpt, 3 lenker vil bli oppdatert". Utført på ordentlig.

Sjekket etterpå — alle tre lenketyper ble oppdatert korrekt. Dette er nøyaktig det alle tidligere verktøy manglet.

Hvordan installere VaultForge — Endelig instruksjon

Hvis du har macOS og Claude Desktop:

Steg 1

Last ned .mcpb-filen:

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

Steg 2

Claude Desktop åpner installasjonsdialogen for utvidelser. Skriv inn den absolutte stien til vaultet ditt — ingen backslashes, vanlige mellomrom:

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

Steg 3

Klikk Save. Claude Desktop legger til utvidelsen i konfigurasjonen automatisk. Ingen omstart nødvendig — .mcpb-utvidelser plukkes opp automatisk.

Steg 4

Verifiser: i en ny chat spør: "What is the status of my Obsidian vault?" — bør returnere noe som totalFiles: 416, totalDirs: 135, ...

Hva jeg lærte om Obsidians MCP-økosystem

For det første: "mest populær" betyr ikke "fungerer". MarkusPfundstein/mcp-obsidian har 3 400 stjerner og er standardanbefalingen, men det er utdatert og mangler viktige operasjoner.

For det andre: et nativt plugin har en skjult kostnad. Aaronsb-pluginet så ideelt ut — graph, Dataview, nativt move. Men avhengigheten av en kjørende Obsidian-instans og dens indeks gjør det uegnet for seriøse masseoperasjoner.

For det tredje: direkte filsystem uten link-engine er en felle. Mcpvault er raskt og enkelt, men "bare å flytte filer" ødelegger vault-strukturen. Lenker bærer påtvunget semantikk som filsystemet ikke vet om. Uten sin egen wikilink-logikkimplementasjon blir verktøyet en landmine.

For det fjerde: test på isolerte data. Før du betror et verktøy massrefaktorering — lag en testmappe med 4–5 filer med krysslenker og se hva som skjer. 5 minutters testing sparer timer med gjenoppretting fra backup.

For det femte: behold en git-backup av vaultet ditt. Det viktigste av alt. Et enkelt git init inne i vaultet og periodiske commits — det er forsikring mot alle feil fra en AI-agent eller et verktøy. Hvis noe går i stykker — git reset --hard bringer alt tilbake.

Konklusjon

Reisen tok flere timer og tre mislykkede forsøk. Den endelige arkitekturen ser slik ut:

• VaultForge — hovedarbeidsverktøyet. Direkte filsystem + egen wikilink-motor + 27 verktøy = stabil refaktorering i enhver skala.
• Git — vault-versjonering. Gratis rollback for enhver feil.

Nå kan jeg gjøre det alt dette ble startet for: be Claude organisere 400 notater i en ordentlig PARA-arkitektur, slå sammen duplikater, legge til frontmatter, bygge MOC-kart. Hver operasjon er trygg, lenker bevares, dry run viser hva som vil skje før noe endres.

Hvis du også ser på ditt rotete Obsidian og vil ha en AI-assistent — start rett med VaultForge. Ikke gjenta min rute gjennom døde prosjekter, beta-plugins og filsystemservere uten lenkelogikk.

Hva om hvert svart hull er et Big Bang for et nytt univers? Denne artikkelen utforsker ideen om at universet vårt kan være en node i et uendelig rekursivt tre — der svarte hull føder sub-universer, energi sirkulerer tilbake via Hawking-stråling, og fysikkens grunnleggende lover bevisst er utformet for å gjøre kontakt mellom universer umulig.

Svart hull = univers

Ideen kom under et øyeblikk av ettertanke: et svart hull dannes når nok masse og trykk konsentreres i et enkelt punkt. Den singulariteten — uendelig tetthet, uendelig krumning — ser mistenkelig ut som forholdene vi beskriver for Big Bang.

Hva om dette er den samme hendelsen, sett fra forskjellige sider? Utenfra ser vi et svart hull som sluker materie. Innenfra — et nytt univers som eksploderer til eksistens. Massen og energien som kollapset inn i det svarte hullet blir råmaterialet for et helt nytt kosmos med sine egne stjerner, planeter og kanskje sine egne svarte hull.

Hvert svart hull i universet vårt kan inneholde et univers. Og universet vårt kan eksistere inne i et svart hull i et foreldre-univers.

Hvorfor universer ikke kan kontakte hverandre

Her er den elegante delen: når du først har krysset hendelseshorisonten, finnes det ingen vei tilbake. Generell relativitetsteori garanterer dette — foreldre-universets fremtid ligger helt utenfor hendelseshorisonten, utilgjengelig innenfra. Fra sub-universets perspektiv har foreldre-universet allerede tatt slutt. Hele dets tidslinje har allerede passert.

Dette er ikke en teknisk begrensning vi kan overvinne med bedre teknologi. Det er bygget inn i selve romtidens geometri. Universer er fundamentalt isolert fra hverandre — ikke av avstand, men av tidens struktur.

Energisyklusen: å låne og tilbakebetale

Men energi går ikke tapt. Hawking-stråling — den kvanteprosessen der svarte hull sakte fordamper — skaper et bemerkelsesverdig kretsløp:

1. Et foreldre-univers skaper et svart hull og overfører energi til et sub-univers
2. Sub-universet lever gjennom hele sin livssyklus over billioner av år
3. Det svarte hullet fordamper sakte og returnerer energi til foreldre-universet via Hawking-stråling
4. Foreldre-universet mottar energien sin tilbake — med renter

Den "renten" er fascinerende: fysikere tror nå at Hawking-stråling bevarer informasjon. Foreldre-universet får ikke bare tom energi tilbake — det får et avtrykk av alt som skjedde inni. Hver stjerne som ble dannet, hver planet, hvert øyeblikk av bevissthet — kodet i stråling.

Rekursjon helt ned

Hvis du er programmerer, er mønsteret umiskjennelig. Dette er rekursjon. Hvert univers kaller universe() med mindre energi og skaper sub-universer som skaper sub-sub-universer, helt til det ikke er nok energi til å danne svarte hull — grunntilfellet.

universe(energy)
  ├── creates black holes
  │     ├── universe(energy - n)
  │     │     ├── universe(energy - n - m)
  │     │     │     └── base case: not enough energy for black holes
  │     │     └── returns energy via Hawking radiation
  │     └── returns energy via Hawking radiation
  └── receives all energy back

Fysikeren Lee Smolin formaliserte en lignende idé som kosmologisk naturlig utvalg: universer "reproduserer seg" gjennom svarte hull, og hver generasjon har litt forskjellige fysiske konstanter — optimalisert gjennom utallige sykluser for å produsere flere svarte hull, flere universer.

Hvor er vi i denne syklusen?

Universet vårt er omtrent 13,8 milliarder år gammelt. Det høres urgammelt ut, men i sammenheng med hele dets levetid er vi vitne til den aller første begynnelsen:

Vi eksisterer ved omtrent 0,00000000...01% av universets totale levetid. Stjernenes æra — alt vi kan se — er et kort glimt helt i begynnelsen. Universets virkelige historie er den langsomme, tålmodige æraen der svarte hull skaper og fordamper sub-universer.

Spørsmålet om høyere dimensjoner

Alt som er diskutert så langt opererer innenfor vår tredimensjonale forståelse. Men hvis universet vårt er et "snitt" av noe høyere-dimensjonalt, kan hele det rekursive treet av svarte hull og sub-universer bare være en skygge av en struktur vi ikke kan oppfatte.

I 1884 skrev Edwin Abbott Flatland — en fortelling om todimensjonale vesener som ikke kan forestille seg en tredje dimensjon. En kule som passerer gjennom Flatland fremstår som en sirkel som vokser og krymper. "Flatlendingene" kan beskrive det matematisk, men aldri virkelig forstå hva de ser. Vi kan befinne oss i nøyaktig samme posisjon i forhold til vårt univers.

Hva er bevissthet? Hvorfor eksisterer subjektiv opplevelse? David Chalmers kalte dette det "vanskelige problemet" — og det kan være det sterkeste beviset for at noe opererer utenfor vår dimensjonale rekkevidde.

Alt er låst på det fundamentale nivået

Den mest slående erkjennelsen er ikke at vi ikke vet — men at vi ikke kan vite. Hver undersøkelsesretning treffer en fundamental barriere:

• Vil du se foreldre-universet? Blokkert av hendelseshorisonten
• Vil du forstå bevisstheten? Blokkert — et system kan ikke fullt ut analysere seg selv (Gödels ufullstendighetsteoremer)
• Vil du vite hva som var "før"? Blokkert — tiden begynte med Big Bang
• Vil du oppfatte høyere dimensjoner? Blokkert av de kognitive begrensningene til et tredimensjonalt vesen

Filosofen Colin McGinn kaller dette kognitiv lukking: noen spørsmål er lukket for det menneskelige sinnet, ikke på grunn av utilstrekkelige data, men på grunn av sinnets egen arkitektur. Forskjellen mellom "vi vet ikke ennå" og "vi kan ikke vite" er dyptgripende.

Det eneste som gjenstår: selvforbedring

Hvis hver utgang er blokkert med vilje — hvis du ikke kan se utover, ikke kan se bakover, ikke kan se oppover — finnes det bare en retning igjen: innover. Universet virker bevisst konstruert for å tvinge fokus på selvet.

Denne konklusjonen kommer ikke fra religion eller filosofilærebøker. Den kommer fra å følge logikken i svarte hull, rekursjon, informasjonsteori og kognisjonens grenser. Eksistensialister, buddhister, stoikere og fysikere — alle ankommer til det samme punktet via forskjellige veier: formålet med eksistens kan rett og slett være foredlingen av det vesenet som eksisterer.

Vi kom hit ikke gjennom tro, men gjennom fysikk — fra svarte hull, gjennom rekursive universer, til kunnskapens fundamentale blokader, til den eneste åpne døren: å bli bedre.

Referanser

• Lee Smolin — Kosmologisk naturlig utvalg
• Stephen Hawking — Hawking-stråling
• David Chalmers — Bevissthetens vanskelige problem
• Edwin Abbott — Flatland: En roman i mange dimensjoner (1884)
• Kurt Gödel — Ufullstendighetssetningene

For enkle nettsider — porteføljer, blogger, landingssider, småbedriftssider — er et tradisjonelt CMS i ferd med å bli unødvendig overhead. AI-verktøy som Claude Code, Cursor og GitHub Copilot kan nå redigere kodebasen din direkte, forstå kontekst, oversette innhold og deploye endringer via git. Abstraksjonslaget som CMS ga, erstattes av et smartere grensesnitt: naturlig språk.

CMS-skatten du betaler

Ethvert CMS kommer med en skjult kostnad. Ikke bare abonnementsavgiften — hele økosystemet av kompleksitet som pakkes rundt den ellers enkle nettsiden din:

• Infrastruktur: En database å drifte, et API å vedlikeholde, et dashbord å sikre. WordPress alene utgjør ~43% av nettet og ~90% av CMS-rettede angrep.
• Ytelse: Dynamisk sidegenerering, API-kall på hver forespørsel, klientside-hydrering av CMS-data. Porteføljen din på 3 sider har nå arkitekturen til et SaaS-produkt.
• Leverandørinnlåsing: Innholdet ditt lever i noen andres databaseskjema. Migrere fra Contentful til Sanity? Det er et prosjekt, ikke en konfigurasjonsendring.
• Kontekstbytte: Rediger kode i IDE-en din, bytt så til et nettleserbasert CMS-dashbord for å endre en overskrift. To forskjellige mentale modeller for det som i bunn og grunn er den samme operasjonen.
• Kostnad: Headless CMS-priser skalerer ofte med API-kall eller innholdsposter. En personlig blogg trenger ikke en innholdsinfrastruktur til $99/måned.

For en markedsføringsside der 50 personer redigerer innhold daglig, er denne kostnaden berettiget. For en utviklerportefølje eller en småbedrifts landingsside? Du bygger en bro over en sølepytt.

Hva som endret seg: AI forstår koden din

Grunnen til at CMS eksisterte var enkel: ikke-tekniske personer (og selv utviklere som ikke ville røre kode for innholdsendringer) trengte et visuelt grensesnitt for å oppdatere nettsider. Koden var for kompleks, for skjør, for lett å ødelegge.

AI endret denne ligningen fundamentalt. Moderne AI-kodeverktøy gjør ikke bare autofullføring — de forstår prosjektstruktur, leser eksisterende mønstre og gjør kontekstuelt korrekte endringer. Endringen i arbeidsflyten er dramatisk:

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

Dette er ikke hypotetisk. Denne bloggen kjører på SolidStart med innhold lagret som TypeScript-filer. Hver artikkel — inkludert denne — ble laget ved å fortelle AI hva den skal skrive, gjennomgå resultatet og pushe til git. Ikke noe CMS-dashbord. Ingen database. Ikke noe API-lag mellom innholdet og koden.

Virkelige eksempler fra denne siden

Denne nettsiden støtter 10 språk, har en blogg, genererer OG-bilder dynamisk og produserer RSS-feeder og sitemaps. Slik ser innholdslaget ut — ren TypeScript:

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

Ting jeg gjør med AI som tradisjonelt ville krevd et CMS:

• Legge til et nytt blogginnlegg: "Skriv en ny artikkel om X, følg samme struktur som eksisterende innlegg" — AI oppretter filen, legger til oversettelser, registrerer den i indeksen
• Oppdatere landingssidetekst: "Endre hero-overskriften til Y" — AI finner riktig fil og oppdaterer den
• Oversette innhold: "Legg til tysk oversettelse for prissiden" — AI leser den engelske versjonen og produserer en kulturelt tilpasset oversettelse, ikke en ord-for-ord-kopiering
• Rette en skrivefeil: "Det er en skrivefeil på about-siden, 'recieve' skal være 'receive'" — gjort på 3 sekunder, committet til git med en meningsfull melding

Hva CMS faktisk løste — og hvordan AI erstatter det

La oss være ærlige om hva CMS brakte til bordet og hvordan hver evne kartlegges til AI-arbeidsflyten:

Den sentrale innsikten: git er allerede et bedre versjonskontrollsystem enn noe CMS noensinne har bygget. Og naturlig språk er et bedre grensesnitt enn noen WYSIWYG-redigerer — fordi det bærer intensjon, ikke bare formatering.

Paradigmeskiftet: kode er innholdslaget

Vi er vitne til en inversjon. I to tiår var trenden å skille innhold fra kode — legge innholdet i en database, eksponere det via API, rendere det i frontend. Det ga mening da kode var vanskelig å redigere og innhold måtte være tilgjengelig for ikke-utviklere.

AI gjorde ikke CMS foreldet ved å være et bedre CMS. Det gjorde CMS foreldet ved å gjøre kode like tilgjengelig som et dashbord.

Utviklingen av innholdshåndtering på nett følger en tydelig bane:

1. 2000-tallet: Monolittiske CMS (WordPress, Drupal) — innhold og presentasjon koblet i ett system
2. 2010-tallet: Headless CMS (Contentful, Strapi) — innhold separert via API, rendret av frontend-rammeverk
3. 2020-tallet: Statiske nettstedsgeneratorer + Markdown (Hugo, Astro) — innhold som filer, bygget ved deploy
4. 2025+: Kode-som-innhold + AI — innholdet lever i typet kode, AI er redigeringsgrensesnittet

Når du fortsatt trenger et CMS

Dette er ikke et "CMS er dødt"-standpunkt. CMS løser reelle problemer i stor skala. Du trenger fortsatt ett når:

• Store redaksjonsteam: 10+ innholdsredaktører som trenger rollebasert tilgang, godkjenningsflyter og samtidig redigering. Git merge-konflikter er ikke en innholdsredaktørs problem å løse.
• Høyfrekvent innhold: Nyhetssider som publiserer 50+ artikler om dagen trenger optimaliserte redaksjonspipelines, ikke git-commits.
• Komplekse innholdsrelasjoner: E-handelskataloger med tusenvis av SKU-er, produktvarianter og dynamisk prising krever strukturerte databaser.
• Regulatorisk etterlevelse: Bransjer som krever revisjonsspor, innholdsgodkjenningskjeder og lovpålagte gjennomgangsprosesser trenger spesialbygde systemer.

Grensen er tydelig: hvis innholdsendringene dine krever koordinering mellom flere ikke-tekniske interessenter med høy frekvens, fortjener CMS sin kompleksitet. Hvis du er en soloutvikler, et lite team, eller administrerer en side som endres ukentlig i stedet for hver time — er AI + kode enklere, raskere, billigere og mer pålitelig.

Fremtiden: AI som det universelle grensesnittet

Trenden strekker seg utover CMS. Hvert programvareabstraksjonslag som eksisterte fordi "det underliggende systemet er for komplekst for direkte interaksjon" komprimeres av AI. Admin-dashbord, konfigurasjon-UI, visuelle databaseredigerere — alle disse er grensesnitt som oversetter menneskelig intensjon til systemendringer. AI gjør denne oversettelsen nativt.

For enkle nettsider er fremtiden allerede her. Innholdet ditt er kode. Redigeringsverktøyet ditt er AI. Versjonskontrollen din er git. Deployen din er en push. Hele CMS-laget — dashbordet, databasen, API-et, hostingen — var mellomvare mellom intensjonen din og nettsiden din. AI fjernet behovet for den mellomvaren.

Det beste CMS-et er intet CMS. Ikke fordi innholdshåndtering ikke betyr noe — men fordi AI gjorde selve koden til det mest intuitive grensesnittet for innholdshåndtering vi noensinne har hatt.

Perplexity Desktop støtter MCP (Model Context Protocol)-koblinger. Ved å legge til den offisielle @modelcontextprotocol/server-filesystem-serveren som peker på ditt Obsidian-vault, kan du be Perplexity på naturlig språk om å lese, opprette og redigere notater — direkte fra chatten. Ingen plugins, ingen utvidelser, ingen kopiering.

Problemet

Perplexity er utmerket til forskning — det søker på nettet, oppsummerer kilder og gir svar med sitater. Men når du vil lagre funnene i Obsidian-vaultet ditt, bryter arbeidsflyten sammen: kopier tekst, bytt til Obsidian, finn riktig notat, lim inn, formater. Hver. Eneste. Gang.

Nettleserutvidelser som "Perplexity to Obsidian" hjelper med eksport, men de er enveis — AI-en kan ikke se vaultet ditt, kan ikke lese eksisterende notater og kan ikke bestemme hvor ting skal plasseres basert på mappestrukturen din.

Hva er MCP?

Model Context Protocol (MCP) er en åpen standard som lar AI-modeller samhandle med lokale verktøy og datakilder. Tenk på det som en USB-port for AI — du kobler til en "server" (et lite program), og AI-en får nye evner. I vårt tilfelle gir filesystem-serveren Perplexity 14 verktøy for å jobbe med filer:

Perplexity Desktop (Mac App)
  │
  ├── MCP Connector: "Obsidian Vault"
  │     │
  │     └── @modelcontextprotocol/server-filesystem
  │           │
  │           ├── read_file()      → read any .md file
  │           ├── write_file()     → create or overwrite files
  │           ├── edit_file()      → patch existing files
  │           ├── list_directory() → browse vault structure
  │           ├── search_files()   → find files by pattern
  │           └── ... 14 tools total
  │
  └── Perplexity AI Model
        │
        └── "Save this to my daily note" → calls write_file()

Nøkkelpunktet: AI-modellen har ikke direkte tilgang til filene dine. Den kaller verktøy levert av MCP-serveren, som kjører lokalt på maskinen din. Dataene dine forlater aldri datamaskinen din med mindre du eksplisitt ber AI-en om å gjøre noe med dem.

Krav

• Perplexity Pro-abonnement (MCP-koblinger er tilgjengelige for betalende brukere)
• Perplexity Mac App fra App Store (ikke nettleserversjonen)
• Node.js installert på Mac-en (for at npx skal fungere)

Trinn-for-trinn-oppsett

Hele oppsettet tar omtrent 2 minutter:

Kommandoen

Kommandoen som skal limes inn i Command-feltet:

npx -y @modelcontextprotocol/server-filesystem "/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian Vault"

Erstatt banen med den faktiske plasseringen til Obsidian-vaultet ditt. Hvis vaultet synkroniseres via iCloud, vil banen være under ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. Sørg for å beholde anførselstegnene — banen inneholder sannsynligvis mellomrom.

Hvordan bruke det

Når koblingen viser Running med 14 tilgjengelige verktøy, gå til en hvilken som helst Perplexity-chat og begynn å snakke med vaultet ditt:

> Show me the structure of my Obsidian vault
> Add a new reflection to daily notes/2026-04-12.md: "Started using MCP today"
> Find all notes that mention "meditation"
> Create a new note in concepts/ about quantum computing
> List all files in my ideas/ folder

AI-en forstår vault-strukturen din, respekterer formateringskonvensjonene dine og kan jobbe med eksisterende innhold. Du kan be den undersøke et emne på nettet og lagre sammendraget direkte i et spesifikt notat.

Hvorfor MCP er bedre enn andre tilnærminger

Før MCP var det begrensede måter å koble Perplexity og Obsidian på:

Nåværende begrensninger

• Kun Mac — Perplexitys MCP-koblinger fungerer for øyeblikket bare i Mac App Store-versjonen
• Ingen Obsidian API-integrasjon — filesystem-serveren jobber med råfiler, ikke gjennom Obsidians API. Det betyr at den ikke utløser Obsidian-plugins (Linter, Templater) ved filoppretting
• Godkjenning påkrevd — sensitive filoperasjoner kan kreve din bekreftelse i Perplexity-appen — det er en sikkerhetsfunksjon, ikke en feil

Konklusjoner

Dette oppsettet forvandler Perplexity fra et forskningsverktøy til et forsknings-og-fangstverktøy:

1. Søk på nettet og lagre i Obsidian i én samtale
2. AI-en ser vault-strukturen din og tilpasser seg organisasjonssystemet ditt
3. Null appbytter — alt skjer i Perplexity-chatten

Kilder

• Model Context Protocol — official MCP specification
• MCP Filesystem Server — the server used in this setup
• Perplexity Help Center — Local and Remote MCPs for Perplexity
• Perplexity Blog — Everything is Computer

Et 6-linjers bash-skript som kjører Claude Code CLI i headless-modus hver morgen kl 9:00. Det søker nyheter på 11 konfigurerbare emner, filtrerer støy og skriver en formatert markdown-digest direkte til en Obsidian vault synkronisert via iCloud. Null avhengigheter. ~100 linjer konfigurasjon totalt.

Problemet

Som utvikler er det en daglig skatt å holde seg oppdatert. RSS-feeder er støyende, Twitter er en tidssluker, nyhetsbrev kommer når du er dypt fokusert. Jeg trengte noe som gjør research for meg.

Den typiske løsningen er å bygge en scraping-pipeline: planlegger, crawler, NLP-pipeline, database, varslingstjeneste. Det er ukers arbeid. Jeg ville ha noe som kunne bygges på en ettermiddag.

Arkitektur

Hele systemet er 4 filer og null avhengigheter:

macOS launchd (9:00 AM daily)
  │
  └── digest.sh
        │
        └── claude -p "$(cat prompt.md)" --max-turns 20 --allowedTools Read,WebSearch,WebFetch,Write
              │
              ├── Reads topics.yaml (11 configurable topics)
              ├── WebSearch → finds news for each topic (last 24-48h)
              ├── WebFetch → reads full articles
              ├── Filters noise: old tutorials, promos, AI spam
              └── Write → saves digest to Obsidian Vault
                    │
                    └── ~/Obsidian Vault/digests/2026-04-12.md
                          │
                          └── iCloud sync → available on all devices

Koden (hele)

Prosjektet er bevisst minimalt.

Inngangspunkt: digest.sh

Hele applikasjonen er et 6-linjers bash-skript:

#!/bin/bash
DIGEST_DIR="$HOME/Developer/news-digest"

claude -p "$(cat "$DIGEST_DIR/prompt.md")" \
  --max-turns 20 \
  --allowedTools Read,WebSearch,WebFetch,Write

Viktige flagg: -p kjører Claude i headless-modus, --max-turns 20 gir agenten nok svinger, --allowedTools begrenser agenten til lesing, søk og skriving.

Hjernen: prompt.md

Her bor intelligensen. Prompten gjør Claude til en nyhetsforskningsagent:

# News Digest Agent

You are a news research agent. Your job is to find today's most important
and interesting news for a senior frontend developer.

## Instructions

1. Read the topics file at ~/Developer/news-digest/topics.yaml
2. For EACH topic, search the web for news from the last 24-48 hours
3. Filter: only include genuinely new and noteworthy items
4. Write the digest as a markdown file to Obsidian Vault digests/YYYY-MM-DD.md
5. IMPORTANT: Use the Write tool to save the file. Do NOT output to stdout.

## Rules

- Language: Ukrainian for summaries, English for titles and technical terms
- If there's no real news for a topic — SKIP IT ENTIRELY
- Prioritize: releases > breaking changes > security > new patterns > discussions
- Max 5 items per topic, sorted by importance
- Include direct links to sources
- Skip promotional content, generic tutorials, and AI-generated spam

Konfigurasjon: topics.yaml

Emner er fullt konfigurerbare — legg til et nytt emne og det er i morgendagens digest:

topics:
  - name: better-auth
    context: "auth library for TypeScript. New releases, breaking changes"

  - name: Next.js
    context: "GitHub issues, releases, App Router, Turbopack, performance"

  - name: SolidJS
    context: "SolidStart, releases, ecosystem, comparison with React"

  - name: Tailwind CSS
    context: "v4 updates, new utilities, plugins"

  - name: Claude AI
    context: "Anthropic announcements, Claude Code, new models, MCP, API"

  - name: GPT AI
    context: "OpenAI announcements, new models, ChatGPT features"

  - name: React
    context: "React 19+, Server Components, new patterns, ecosystem"

  - name: Apple
    context: "Hardware, software, WWDC, developer tools, Apple Intelligence"

  - name: Notable People
    context: >
      Latest tweets from: Elon Musk, Dario Amodei, Sam Altman,
      Jensen Huang, Andrej Karpathy, Simon Willison, Swyx...

  - name: AI Global
    context: "Major AI news, new models, regulations, open-source AI"

Planlegging med launchd

På macOS er launchd den native måten å planlegge gjentakende oppgaver:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.news-digest</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/you/Developer/news-digest/digest.sh</string>
    </array>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>

    <key>StandardOutPath</key>
    <string>/Users/you/Developer/news-digest/logs/stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/you/Developer/news-digest/logs/stderr.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin</string>
        <key>HOME</key>
        <string>/Users/you</string>
    </dict>
</dict>
</plist>

Installer med launchctl load ~/Library/LaunchAgents/com.news-digest.plist. Skriptet kjører daglig kl 9:00.

Hvordan resultatet ser ut

Hver morgen dukker en ny markdown-fil opp i Obsidian-vaultet:

---
date: 2026-04-12
---

# News Digest — 2026-04-12

## Next.js

### Next.js 16.1 Released with Improved Turbopack Caching
Нова версія Next.js 16.1 включає покращене кешування для Turbopack,
що зменшує час холодного старту на ~40%.
[Посилання](https://nextjs.org/blog/next-16-1)

### Critical Memory Leak Fix in App Router
Виправлено витік пам'яті в App Router при частому перемиканні
між динамічними маршрутами.
[GitHub Issue](https://github.com/vercel/next.js/issues/...)

## Claude AI

### Claude Code 1.5 — MCP Server Auto-Discovery
Anthropic випустив оновлення Claude Code з автоматичним
виявленням MCP серверів у проєкті.
[Блог](https://www.anthropic.com/news/...)

I tall

Viktige designvalg

• Claude Code CLI fremfor API — ingen håndtering av API-nøkler eller HTTP-klienter
• Obsidian fremfor e-post — digests er søkbare, lenkbare og permanente
• launchd fremfor cron — macOS-nativ planlegger med håndtering av tapte kjøringer
• YAML for emner — nytt emne = 2-linjers endring
• Hoppe over tomme emner — ingen nyheter = ingen seksjon

Bygg din egen

Klart på 10 minutter:

1. Installer Claude Code CLI og autentiser
2. Klon repoet: git clone https://github.com/oleksiimazurenko/news-digest
3. Rediger topics.yaml og prompt.md
4. Rediger plist-filen og launchctl load
5. Vent til 9:00 — eller test manuelt med bash digest.sh

Konklusjoner

Det mest interessante med dette prosjektet er hva som ikke er der. Ingen database, ingen API-server, ingen Docker, ingen npm-pakker, ingen Python, ingen HTML-parser, ingen NLP-pipeline.

Slik ser det ut å bygge med AI-agenter: du definerer hva og hvor, agenten håndterer hvordan. Total utviklingstid: cirka 2 timer.

Kilder

• news-digest on GitHub — full source code
• Claude Code Documentation — headless mode and CLI flags
• Apple Developer — creating launchd jobs
• Obsidian — markdown knowledge base

next-themes renderer en <script>-tagg inne i en React Client Component for å forhindre temaflimmer (FOUC). React 19 advarer mot dette. Biblioteket er ikke oppdatert siden mars 2025. Løsning: Zustand-store + useServerInsertedHTML. Null avhengigheter, null FOUC, null advarsler.

Problemet

Hvis du bruker next-themes med Next.js 15+ og React 19, får du denne konsollfeilen ved hver sidelasting:

Encountered a script tag while rendering React component.
Scripts inside React components are never executed when rendering on the client.
Consider using template tag instead.

src/providers/theme-provider.tsx (7:10) @ ThemeProvider

Ingen hydreringsfeil. React 19 advarer om at <script>-tagger i klientkomponenter aldri vil kjøre. Skriptet fungerer i SSR, men React flagger det.

Hvorfor det skjer

next-themes setter temaklasse før hydrering ved å injisere et inline-skript via React.createElement:

// next-themes renders a <script> inside a Client Component
return React.createElement(Provider, { value },
  React.createElement("script", {
    suppressHydrationWarning: true,
    dangerouslySetInnerHTML: { __html: `(...theme init code...)` }
  }),
  children
)

React 19 endret oppførselen — script-tagger i komponenter flagges nå. suppressHydrationWarning hjelper ikke for dette.

Hva vi prøvde (og hvorfor det mislyktes)

Vi prøvde systematisk hver tilnærming:

Løsningen: Zustand + useServerInsertedHTML

useServerInsertedHTML injiserer HTML i SSR-strømmen utenfor React-treet. Skriptet er i HTML, men React "ser" det ikke på klienten. Kombinert med Zustand for reaktiv tematilstand — komplett erstatning, null avhengigheter.

Hvordan det fungerer

SSR (server):
  useServerInsertedHTML → injects <script> into HTML stream
  ↓
  Browser receives HTML with theme script already in it
  ↓
  Script runs BEFORE React hydrates → correct class on <html>
  ↓
  No flash. No mismatch. No warning.

Client (after hydration):
  useEffect → _init() → Zustand store syncs with localStorage
  ↓
  useTheme() → reactive theme state for components

Steg 1: Zustand-store

Storen håndterer tematilstand, DOM-klasser, systemdetektering og synkronisering mellom faner. _init() returnerer en oppryddingsfunksjon for useEffect:

import { create } from "zustand";

const STORAGE_KEY = "theme";
const MEDIA_QUERY = "(prefers-color-scheme: dark)";

function getSystemTheme(): "light" | "dark" {
  return window.matchMedia(MEDIA_QUERY).matches ? "dark" : "light";
}

function applyTheme(resolved: string, disableTransition: boolean) {
  const d = document.documentElement;

  if (disableTransition) {
    const style = document.createElement("style");
    style.appendChild(
      document.createTextNode(
        "*,*::before,*::after{transition:none!important}"
      )
    );
    document.head.appendChild(style);
    window.getComputedStyle(document.body);
    setTimeout(() => document.head.removeChild(style), 1);
  }

  d.classList.remove("light", "dark");
  d.classList.add(resolved);
  d.style.colorScheme = resolved;
}

interface ThemeState {
  theme: string;
  systemTheme: "light" | "dark";
  resolvedTheme: string;
  setTheme: (theme: string) => void;
  _init: (disableTransition: boolean) => () => void;
}

export const useThemeStore = create<ThemeState>((set, get) => ({
  theme: "system",
  systemTheme: "light",
  resolvedTheme: "light",

  setTheme: (newTheme) => {
    const { systemTheme, disableTransitionOnChange } = get();
    const resolved = newTheme === "system" ? systemTheme : newTheme;
    localStorage.setItem(STORAGE_KEY, newTheme);
    applyTheme(resolved, disableTransitionOnChange);
    set({ theme: newTheme, resolvedTheme: resolved });
  },

  _init: (disableTransition) => {
    const stored = localStorage.getItem(STORAGE_KEY) || "system";
    const system = getSystemTheme();
    const resolved = stored === "system" ? system : stored;

    set({ theme: stored, systemTheme: system, resolvedTheme: resolved });
    applyTheme(resolved, disableTransition);

    // System theme changes
    const mq = window.matchMedia(MEDIA_QUERY);
    const onChange = (e: MediaQueryListEvent) => {
      const newSystem = e.matches ? "dark" : "light";
      const { theme } = get();
      set({ systemTheme: newSystem,
            resolvedTheme: theme === "system" ? newSystem : theme });
      if (theme === "system") applyTheme(newSystem, disableTransition);
    };
    mq.addEventListener("change", onChange);

    // Cross-tab sync
    const onStorage = (e: StorageEvent) => {
      if (e.key !== STORAGE_KEY || !e.newValue) return;
      const system = getSystemTheme();
      const resolved = e.newValue === "system" ? system : e.newValue;
      set({ theme: e.newValue, resolvedTheme: resolved });
      applyTheme(resolved, disableTransition);
    };
    window.addEventListener("storage", onStorage);

    return () => {
      mq.removeEventListener("change", onChange);
      window.removeEventListener("storage", onStorage);
    };
  },
}));

export function useTheme() {
  return useThemeStore((s) => ({
    theme: s.theme,
    setTheme: s.setTheme,
    resolvedTheme: s.resolvedTheme,
    systemTheme: s.systemTheme,
  }));
}

Steg 2: ThemeProvider

Provideren injiserer FOUC-forebyggende skript via useServerInsertedHTML og initialiserer Zustand-storen ved montering:

"use client"

import { useEffect } from "react"
import { useServerInsertedHTML } from "next/navigation"
import { useThemeStore } from "@/store/use-theme-store"

const THEME_INIT_SCRIPT = `(function(){
  try {
    var t = localStorage.getItem("theme") || "system";
    var r = t;
    if (t === "system") {
      r = window.matchMedia("(prefers-color-scheme: dark)").matches
        ? "dark" : "light";
    }
    document.documentElement.classList.remove("light", "dark");
    document.documentElement.classList.add(r);
    document.documentElement.style.colorScheme = r;
  } catch(e) {}
})()`

export function ThemeProvider({
  children,
  disableTransitionOnChange = false,
}) {
  // Injects script into SSR HTML outside the React tree
  // — prevents FOUC without triggering React 19 warning
  useServerInsertedHTML(() => (
    <script dangerouslySetInnerHTML={{ __html: THEME_INIT_SCRIPT }} />
  ))

  useEffect(() => {
    return useThemeStore.getState()._init(disableTransitionOnChange)
  }, [disableTransitionOnChange])

  return <>{children}</>
}

Steg 3: Layout

import { ThemeProvider } from "@/providers/theme-provider"

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <ThemeProvider disableTransitionOnChange>
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

Steg 4: Bruk det

import { useTheme } from "@/store/use-theme-store"

export function ThemeSwitch() {
  const { theme, setTheme } = useTheme();

  return (
    <button onClick={() => setTheme(
      theme === "dark" ? "light" : "dark"
    )}>
      {theme === "dark" ? "☀️" : "🌙"}
    </button>
  );
}

Migrering fra next-themes

API-et er bevisst identisk. Migrering er én enkelt importendring per fil:

- import { useTheme } from "next-themes"
+ import { useTheme } from "@/store/use-theme-store"

  // API is identical — no other changes needed
  const { theme, setTheme, resolvedTheme, systemTheme } = useTheme()

Sammenligning

Hvorfor ikke andre alternativer?

@wrksz/themes

Drop-in-erstatning som bruker useServerInsertedHTML. Fungerer, men nok en avhengighet med én vedlikeholder. Om next-themes lærte oss noe — avhengigheter blir forlatt. Med ~100 linjer kode eier du hele løsningen.

next-themes@1.0.0-beta.0

Finnes på npm, ingen releasedato, ingen endringslogg, uklart om React 19-advarselen er fikset. Ikke verdt å satse produksjonskode på.

Kun CSS (prefers-color-scheme)

Fungerer for systemdetektering, men kan ikke håndtere localStorage-persistens, manuell bytting eller "system"-alternativet. Trenger JavaScript.

Konklusjoner

1. next-themes er i praksis forlatt — siste utgivelse mars 2025, React 19-advarsel ufikset
2. useServerInsertedHTML er riktig Next.js-primitiv for skriptinjeksjon uten React-advarsler
3. Zustand gir reaktiv tematilstand med mindre kode enn en Context-provider
4. Hele løsningen ~100 linjer, null nye avhengigheter, du eier hver linje

Kilder

• shadcn/ui #10104 — Dark mode guide should address React 19 script warning
• next-themes #296 — React 19 support request (open since 2024)
• React #34008 — Script tags not executing in components (by design)
• @wrksz/themes — Drop-in replacement using useServerInsertedHTML
• Next.js Docs — useServerInsertedHTML API

Appen vår (Promova) bruker Next.js 16 med en Landing Builder — et CMS-drevet system som setter sammen markedsføringssider fra ~90 forskjellige seksjonskomponenter. Arkitekturen bruker en sectionRegistry.tsx som mapper seksjonsnavn til next/dynamic()-kall:

// sectionRegistry.tsx — imports all 90 sections
export const sectionRegistry = {
  HeroSection: dynamic(() => import('./HeroSection/HeroSection')),
  FAQSection: dynamic(() => import('./FAQSection/FAQSection')),
  ReviewsSection: dynamic(() => import('./ReviewsSection/ReviewsSection')),
  // ... 87 more
}

En enkelt landingsside rendrer bare 5-8 seksjoner. Men Lighthouse viste:

Eliminate render-blocking resources
  94 CSS resources (~330 KB)
  Potential savings: 5,440 ms

Hvorfor? Turbopack ser alle 90 import()-stier som oppnåelige og genererer <link rel="stylesheet"> for hver SCSS-modul. Selv seksjoner som aldri rendres på siden får sin CSS injisert i <head>. Dette er en bekreftet, forventet oppførsel i Next.js App Router. Ingen fix er planlagt.

Alt jeg prøvde (og hvorfor det feilet)

Jeg brukte dager på å gå gjennom hver tilnærming jeg kunne finne. Her er den fullstendige listen:

inlineCss-fellen

Next.js har et experimental.inlineCss-flagg som erstatter alle <link rel="stylesheet"> med inline <style>-tagger. Høres perfekt ut, ikke sant?

Problemet: det er alt eller ingenting. Du kan ikke aktivere det per rute. Hvis du har SSR-sider (force-dynamic), bygger hver forespørsel om all CSS inline. Vi prøvde — vår headless CMS tålte ikke lasten.

Oppdagelsen: Turbopack Import Attributes

Ved å grave i Next.js 16.2-utgivelsesnotater fant jeg en dårlig dokumentert funksjon: Turbopack Import Attributes. Den lar deg overstyre den innebygde bundler-pipelinen for en spesifikk import med TC39 with {}-syntaks:

import { cssText, styles } from './hero.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}

Dette forteller Turbopack: "Ikke behandle denne importen som et stilark. Kjør den gjennom min egendefinerte loader og behandle utdataen som JavaScript."

Dette er den avgjørende innsikten. I stedet for at Turbopack genererer et <link rel="stylesheet"> som blokkerer rendering, kompilerer vår loader SCSS og eksporterer det som en JS-streng. Resultat: bare CSS for seksjoner som faktisk rendres havner i sidens HTML.

Løsningen

1. Egendefinert Turbopack Loader

Et ~70-linjers Node.js-skript som yarn workspace-pakke (@promova/scss-to-inline-loader):

const { createHash } = require('node:crypto')
const sass = require('sass')
const postcss = require('postcss')
const postcssModules = require('postcss-modules')
const path = require('path')

const SHARED_STYLES = path.resolve(__dirname, '../shared/styles')

// Same prependData as sassOptions.prependData in next.config.ts
const PREPEND_DATA = `
@use "sass:math" as math;
@use "sass:list" as list;
@use "${SHARED_STYLES}/_variables.scss" as *;
@use "${SHARED_STYLES}/_breakpoints.scss" as *;
@use "${SHARED_STYLES}/_mixins.scss" as *;
`

module.exports = function scssToInlineLoader(source) {
  const callback = this.async()
  processScss(source, this.resourcePath)
    .then((js) => callback(null, js))
    .catch((err) => callback(err))
}

async function processScss(source, resourcePath) {
  // 1. Compile SCSS → CSS (with global variables, mixins, breakpoints)
  const sassResult = sass.compileString(PREPEND_DATA + '\n' + source, {
    loadPaths: [path.dirname(resourcePath), SHARED_STYLES],
    style: 'compressed',
    sourceMap: false,
    url: new URL('file://' + resourcePath),
  })

  // 2. Scope class names with postcss-modules (CSS Modules compatible)
  let classNames = {}
  const result = await postcss([
    postcssModules({
      generateScopedName(name, filename) {
        const file = path.basename(filename, path.extname(filename))
          .replace('.module', '')
        const hash = createHash('md5')
          .update(filename + name)
          .digest('base64url')
          .slice(0, 6)
        return `${file}__${name}__${hash}`
      },
      getJSON(_, json) { classNames = json },
    }),
  ]).process(sassResult.css, { from: resourcePath })

  // 3. Export as JS module — same interface as CSS Modules
  return [
    `export const cssText = ${JSON.stringify(result.css)};`,
    `export const styles = ${JSON.stringify(classNames)};`,
    `export default styles;`,
  ].join('\n')
}

Hva den gjør: styles — det samme scopede klassenavnkartet som standard CSS Modules. cssText — kompilert CSS som streng.

2. InlineStyle-komponent

Bruker React 19s innebygde <style href precedence>-API for automatisk deduplisering:

export function InlineStyle({ css, id }: { css: string; id: string }) {
  return (
    <style href={id} precedence="default">
      {css}
    </style>
  )
}

React 19 garanterer: samme href → bare én <style> i DOM.

3. Migrering per komponent (~6 linjer per seksjon)

// BEFORE: Turbopack → <link rel="stylesheet"> (render-blocking)
import styles from './hero_section.module.scss'

// AFTER: Custom loader → JS module → inline <style> (non-blocking)
import { cssText, styles } from './hero_section.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}
import { InlineStyle } from '@promova/scss-to-inline-loader/InlineStyle'

export function HeroSection() {
  return (
    <section className={styles.hero}>
      <InlineStyle css={cssText} id="hero-section" />
      {/* ... component JSX, className usage is identical */}
    </section>
  )
}

.module.scss-filene forblir nøyaktig de samme. Ingen CSS-omskriving.

Hvorfor dette er bedre enn inlineCss: true

Her er den kritiske forskjellen:

Med inlineCss: true får en side fortsatt ALLE 94 stilark inline. Med vår tilnærming havner bare CSS som faktisk rendres i HTML-en.

Turbopack-fellen: ingen globale regler for .module.scss

En felle jeg gikk i: du kan tro at du kan legge til en Turbopack-regel i next.config.ts for å bruke loaderen globalt:

// ❌ THIS CAUSES A FATAL PANIC
turbopack: {
  rules: {
    '**/components/**/*.module.scss': {
      loaders: ['@promova/scss-to-inline-loader'],
      as: '*.js'
    }
  }
}

Ikke gjør dette. Turbopacks innebygde CSS-modul-pipeline fanger .module.scss-filer før egendefinerte regler brukes, noe som forårsaker:

FATAL PANIC: inner asset should be CSS processable

with {}-attributter fungerer fordi de instruerer Turbopack på importstedet om å omgå CSS-modul-pipelinen fullstendig.

Resultater

127 seksjonskomponenter migrert i Landing Builder. Produksjonsbygg verifisert.

Begrensninger

• with {} per import er ordrig — hver import trenger 3 ekstra linjer.
• Bare Turbopack — with {}-attributter støttes ikke av Webpack.
• Klassenavnhashing — vår loader bruker en annen hashingsalgoritme enn Turbopacks innebygde.
• HTML-størrelse øker — CSS er inline i HTML i stedet for cachede separate filer.

Når du bør bruke dette

Denne teknikken er mest effektiv når:

1. Du har et registry/barrel-mønster — én fil importerer mange komponenter, men bare noen få rendres per side
2. Du bruker Turbopack — Import Attributes er Turbopack-spesifikke
3. Du vil ha kontroll per komponent — ikke et alt-eller-ingenting-flagg
4. SCSS-en din er kompleks — variabler, mixins, breakpoints, nesting — alt støttet
5. Du ikke kan bruke experimental.inlineCss — fordi du har SSR-sider eller vil ha granulær kontroll

Relaterte GitHub Issues

Hvis du er berørt av render-blokkerende CSS i Next.js App Router — du er ikke alene:

Kjerneproblemet

• #62485 — Render blocking CSS (maintainers: "expected behavior")
• #61066 — Dynamic imports from Server Components are not code-split
• #54935 — Server-side dynamic imports don't split client modules
• #61574 — JS/CSS code splitting doesn't work as documented
• #57634 — Add support for critical CSS inlining with App Router
• #50300 — next/dynamic on server component does not build CSS modules

inlineCss-funksjonen & problemer

• PR #72195 — experimental: css inlining (the implementation)
• PR #73182 — Don't inline CSS in RSC payload for client navigation
• #75648 — WhatsApp preview broken with inlineCss + Tailwind
• #83612 — Turbopack wrong font URL with inline CSS

Fellesskapet søker løsninger

• Discussion #82894 — How to prevent render-blocking with CSS Modules? (2025)
• Discussion #70526 — Ideas for reducing render-blocking CSS
• Discussion #59814 — Render blocking styles with Tailwind
• Discussion #49691 — How to deal with render-blocking modular CSS
• Discussion #59989 — Critical CSS inlining with App Router
• Discussion #80486 — Is optimizeCss still in use?
• Discussion #85465 — Turbopack plugin API (doesn't exist)

Turbopack CSS-feil

• #68412 — Incorrect CSS modules load order with external components
• #76464 — Turbopack sometimes strips SCSS imports
• #82497 — SCSS module not loading when not-found.tsx is present
• #88544 — Exporting Sass variables from CSS modules doesn't work with Turbopack

Bygget hos Promova — en språklæringsplattform som betjener millioner av brukere.

Next.js patcher den globale fetch og legger til et cache-lag som holder referanser til responsdata etter at de burde ha blitt frigjort. Hvert fetch-kall legger til minne som aldri returneres til GC. I Docker/Kubernetes fører dette til OOM-krasj hver par timer. Buggen har eksistert siden Next.js 14 (april 2024) og er fortsatt uløst i 16.2.x (mars 2026). På Vercel viser ikke problemet seg takket være efemere serverless-funksjoner.

Hvordan normal fetch fungerer

Request → fetch → got data → response to user → GC cleans up → memory free

Hvordan fetch fungerer i Next.js

Next.js fanger opp den globale fetch og pakker den inn med sitt eget cache-/tracking-lag:

Request → Next.js fetch wrapper → creates:
  - Performance entry (speed tracking)    ← not cleaned
  - Request metadata object               ← not cleaned
  - Internal promise wrapper              ← not cleaned
  - Cache lookup entry                    ← not cleaned
  - Response body (for unique URL)        ← not cleaned
→ Response to user
→ GC sees objects are still referenced → doesn't touch them
→ Memory grows indefinitely

Hva som skjer i produksjon

Self-hosted (Docker/K8s):
  Request 1:      fetch → +100KB → RAM: 100KB
  Request 2:      fetch → +100KB → RAM: 200KB
  Request 1000:   fetch → +100KB → RAM: 100MB
  Request 50,000: fetch → +100KB → RAM: 5GB → OOM Kill 💀
  → Kubernetes restarts the pod → cycle repeats

Vercel (Serverless):
  Request 1: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  Request 2: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  → Memory never accumulates

Berørte versjoner

Next.js — Alle versjoner med App Router

Node.js

Testet på Node.js 20, 22, 24, 25 — lekker på alle.

Hva som ikke fungerer

Hva som fungerer (workarounds)

Begrensning med axios-workaround

Dine egne API-kall kan erstattes med axios. Men Next.js bruker internt den patchede fetch for:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• Server Components data fetching med deduplisering
• use cache (Next.js 16)

Selv uten en eneste fetch i koden din — bruker Next.js den fortsatt internt.

Hvorfor Vercel ikke fikser det

Forretningslogikk

Vercel er et selskap som tjener penger på å hoste Next.js. På deres plattform viser ikke problemet seg (serverless = efemert). Buggen påvirker bare self-hosted (Docker, K8s, VPS) — de som ikke betaler Vercel.

Offisiell posisjon

Tim Neutkens (Vercel-maintainer) analyserte problemet og erklærte at det er et undici-problem (Node.js fetch-bibliotek), ikke Next.js. Issue #90433 ble stengt. Til tross for at:

• axios og node-fetch på samme Node.js fungerer uten lekkasjer
• Lekkasjen bare oppstår når fetch går gjennom Next.js-wrapperen
• Buggen har vært åpen i 2 år uten fiks

Prioriteringer

I løpet av disse 2 årene har Next.js-teamet sluppet:

• Turbopack (2-5x raskere builds) — markedsføringsfordel
• Cache Components / use cache — reduserer belastningen på Vercel-servere
• proxy.ts i stedet for middleware — forenkler edge-deployment på Vercel
• DevTools MCP — AI-hype

Memory leak i self-hosted? Ikke en prioritet.

Løsning: AWS Lambda (SST + OpenNext)

Hva er det

OpenNext er en open-source-adapter som konverterer en Next.js-build til et format for AWS Lambda. SST er et rammeverk som automatiserer infrastrukturen.

Arkitektur

Next.js build
  → OpenNext
    → AWS Lambda (SSR, API routes)
    → S3 (static, assets)
    → CloudFront (CDN)
    → SQS + DynamoDB (ISR revalidation)

Hvorfor dette løser minneslekkasjen

Lambda-funksjoner behandler forespørsler og resirkuleres etter 5-15 minutters inaktivitet. Minnet rekker ikke å akkumuleres.

Deployment

npx sst@latest init
npx sst deploy --stage production

Sammenligning

Lambda-nyanser

• Cold starts — første forespørsel er tregere (~200-500ms)
• Sikkerhet — aktiver OAC (Origin Access Control), ellers er Lambda-URL-en offentlig
• OpenNext — community-prosjekt, ikke offisielt fra Vercel. Nye Next.js-funksjoner kan gå i stykker
• Lommebokattack — ved DDoS kan Lambda auto-scaling føre til en stor regning

Hvorfor en ekte fiks er urealistisk

1. Arkitekturproblem

Lekkasjen er ikke en tilfeldig bug, men en konsekvens av en designbeslutning: Next.js fanger opp den globale fetch og legger til cache/tracking oppå. For å fikse det må måten App Router interagerer med fetch redesignes. Dette påvirker ISR, revalidation, data cache, request deduplication — kjernen i rammeverket.

2. Interessekonflikt

Vercel er ikke motivert til å fikse det som ikke påvirker deres plattform. Self-hosted konkurrerer med deres forretning. Jo flere problemer i self-hosted — jo flere migrerer til Vercel.

3. Skyldforskyvning

Den offisielle posisjonen er "det er undici, ikke oss". Inntil det endrer seg — vil de ikke jobbe med en fiks.

4. Ingen community-fiks

Next.js AGPL-3.0-lisens tillater forks, men kodebasen er enorm og tett koblet til Vercel-infrastrukturen. En community-PR for å fikse fetch-wrapperen ville kreve dyp forståelse av den interne arkitekturen og godkjenning fra maintainers — som allerede har stengt issuen.

Konklusjoner

1. Hvis du er på Vercel — ikke noe problem, ingenting å gjøre
2. Hvis self-hosted og trenger serverless — SST + OpenNext på AWS Lambda
3. Hvis self-hosted Docker — erstatt fetch med axios der det er mulig, overvåk RAM, konfigurer automatisk pod-omstart
4. Hvis du starter et nytt prosjekt — vurder SvelteKit eller Nuxt som alternativer uten dette problemet

Kilder

• Issue #64212 — Memory Leak with global fetch (April 2024)
• Issue #68578 — Possible memory leak in Fetch API (August 2024)
• Issue #85914 — Memory Leak with fetch + standalone (November 2025)
• Issue #90433 — OOM in 16.0.10 (February 2026)
• Discussion #88603 — OOM in Docker/K8s (January 2026)
• Discussion #88078 — cacheMaxMemorySize behavior
• OpenNext
• SST — Next.js on AWS
• Secret knowledge to self-host Next.js
• Next.js Memory Usage Guide