Men efter en måneds reel brug stødte jeg på et par væsentlige problemer, som det indlæg ikke dækkede. Det største — en skjult særegenhed ved Claude Code, som jeg ved et tilfælde trådte midt i, da jeg tilføjede Gmail-MCP'en, og den "forsvandt" fra min profil fem minutter senere. I dag byggede jeg det hele om til en ny arkitektur — XDG-kompatibel, med et symlink og en interaktiv profilvælger via gum. Dette er v2 — en evolution ud af reel erfaring, ikke en teoretisk forbedring.

Det, der begyndte at irritere

Fire ting. De første tre handler om ryddelighed, synlighed og skala. Den fjerde er den ægte arkitektoniske fælde, som jeg ikke så med det samme. Jeg går dem igennem i rækkefølge, for det er netop den fjerde, der til sidst tvang ombygningen.

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

~/.claude og ~/.claude-promova — to dotfolders side om side i roden af $HOME. XDG Base Directory Specification siger, at configs hører hjemme i ~/.config/. Dotfile-mapper spredt direkte i home er et antimønster, der med tiden gør $HOME til en skuffe med rod. Kosmetisk, javel, men det irriterede mig hver gang, jeg så ls -la ~.

2. Ingen visuel bekræftelse på aktiv profil

Jeg starter claude og ved ikke, hvilken profil der er aktiv — før jeg kører claude config list inde i sessionen. Hvis jeg har glemt, hvilken terminal jeg har startet hvor, må jeg tjekke. En bagatel, men med personal + work kørende parallelt i to faner hober det sig op.

3. Aliaser skalerer ikke

To profiler — claude og claude-promova — det er fint. Tilføj en tredje (en freelancekunde) — så skal der bruges et tredje alias. En fjerde — et fjerde. Efter et halvt år ville jeg ikke huske, hvilke aliaser jeg faktisk havde oprettet.

4. Den skjulte fælde i ~/.claude.json

Og dette er den egentlige grund til ombygningen. Claude Code har to forskellige steder til konfiguration, og dokumentationen råber det ikke ud: ~/.claude/ — kataloget, hvor projects/, sessions/, hooks/, skills/ ligger. Og separat — ~/.claude.json, en fil direkte i $HOME-roden, hvor oauthAccount, mcpServers, projects-historikken, skillUsage og omkring 40 andre felter af ægte live state bor.

Kommandoen claude mcp add --scope user skriver netop til ~/.claude.json i home-roden og ikke til ~/.claude/.claude.json eller til profilkataloget. Det vidste jeg ikke. Indtil jeg en dag trådte lige i det.

Discovery: hvorfor Gmail-MCP'en "forsvandt"

I morges satte jeg Gmail-MCP'en op i Claude Code. Sædvanligt setup: Google Cloud-projekt, OAuth-credentials, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Alt OK. Genstartede sessionen — virker, jeg læser mail, svarer på beskeder. En time senere begyndte vi at refaktorere aliaserne til en funktion med gum-profilvælger, og derefter flyttede vi alt over på XDG. Jeg kørte mv ~/.claude → ~/.config/claude-profiles/personal, genstartede CC, valgte personal i menuen. Og i den nye session åbnede jeg /mcp:

figma            (failed)
playwright-test
claude.ai Notion

Ingen gmail. Ingen vaultforge. Kun tre servere, hvoraf én oven i købet var failed. Og jeg havde lige tilføjet Gmail. Imens viste sessionen i en anden terminal (work-profilen) Gmail og Vaultforge uden mindste problem.

Jeg begyndte at grave og fandt, at jeg på maskinen havde tre forskellige filer med navnet .claude.json:

Der var den. Det er netop dét, der er den arkitektoniske fælde:

1. claude mcp add --scope user skriver altid til ~/.claude.json i home-roden, uafhængigt af CLAUDE_CONFIG_DIR
2. Når CLAUDE_CONFIG_DIR er sat, læser Claude Code $CLAUDE_CONFIG_DIR/.claude.json — altså filen inde i profilen
3. Posterne for "user-scope MCPs" og "profilens MCPs" bor i forskellige filer med samme navn — og de er lette at forveksle

I mit tilfælde var ~/.claude.json (home-roden, 113 KB) den levende, aktuelle tilstand — med gmail, vaultforge, OAuth-sessionen, det hele. Og ~/.config/claude-profiles/personal/.claude.json (29 KB) viste sig at være en gammel snapshot, der af en eller anden grund allerede tidligere lå i gamle ~/.claude/ — måske skrev en ældre CC-version dertil, måske et plugin. jq -r 'keys[]' på begge filer viste, at home-root-versionen havde 41 unikke nøgler, som ikke fandtes i snapshotten.

Og de 41 nøgler er ikke skrald. Det er Claude Codes virkelige tilstand:

• skillUsage — brugsstatistik for skills
• githubRepoPaths — repo-cache til projektnavigering
• cachedGrowthBookFeatures + cachedStatsigGates — feature flags (uden dem henter CC nye ved hver start)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — UI-flag (uden dem dukker modalerne op igen ved næste start)
• lastPlanModeUse, feedbackSurveyState, installMethod — onboarding- og UX-state

Hvis du bare kører mv ~/.claude ~/.config/claude-profiles/personal uden merge — mister du det hele. Du ser welcome-modalerne igen, githubRepoPaths-søgningen kører på ny, alle survey-prompts vender tilbage. Som jeg nær havde gjort.

Den nye arkitektur

Alt bor under ét fælles forældrekatalog i ~/.config/, sådan som XDG vil have det. Hver profil er selvstændig — den har sin fulde state inklusive sin egen .claude.json. ~/.claude bliver tilbage som symlink til personal-profilen for bagudkompatibilitet.

~/.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-roden. Hver profil er et separat, isoleret katalog, hvor alt ligger: projects/sessions-mapperne og den samme fil med MCP-servere og OAuth-tokens. Én source of truth pr. profil.

Hvorfor symlinket peger på personal

Alt, der hardkoder stien ~/.claude/ — gamle scripts, plugins, Claude Codes IDE-udvidelser, statusline-configs som claude-powerline.json — bliver ved med at virke uden ændringer. Symlinket resolves til personal-profilen. Hvis du ved et tilfælde kører command claude (uden wrapper-funktionen) — havner du også i personal via default-path lookup. Personal bliver den "quiet default", den var før, men bor nu fysisk på XDG-pladsen.

Interaktiv vælger ved start — funktion + gum

I stedet for aliaser — en funktion claude() i ~/.zshrc, der viser en pilemenu via gum (Charms TUI-hjælper). Funktionen opfanger claude-kaldet på shell-niveau, lader dig vælge en profil og kører command claude med det tilsvarende CLAUDE_CONFIG_DIR. command er vigtigt — det går uden om wrapper-funktionen og kalder den ægte binær.

# 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
}

Sådan ser det ud ved start:

Claude profile:
▸ personal
  promova

↑↓ for at navigere, Enter for at vælge, Esc for at afbryde (Claude starter simpelthen ikke). Profilen er altid synlig — umuligt at overse.

Migrationsscript

Til den, der læser dette og vil flytte fra det gamle skema. Det mest kritiske trin er det andet: det merger ~/.claude.json fra home-roden med det, der allerede ligger i personal-profilen, og samler mcpServers-listerne. Uden det trin mister profilen både sine MCP'er og hele sin live-state.

# 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 trin om rettigheder er vigtigt for sig selv. jq | mv opretter en fil med umask 644 (world-readable). Inde i den ligger OAuth-tokens. chmod 600 umiddelbart efter mergen er obligatorisk.

Efter migrationen — luk og åbn alle aktive Claude-sessioner, genindlæs shellet (source ~/.zshrc eller ny terminal), kør claude, vælg en profil, tjek via claude mcp list at alle MCP'er er på plads. Hvis alt er OK — slet ~/.claude.json.migrated.bak. Hvis noget er galt — rollback er trivielt: mv ~/.claude.json.migrated.bak ~/.claude.json og fjern symlinket.

Det, du får

• Ét fælles forældrekatalog i stedet for to dotfolders i $HOME — XDG-kompatibelt
• Symlinket bevarer kompatibilitet med alt, der hardkoder ~/.claude/
• Hver profil er selvstændig — sin fulde state og sine MCP'er i sin egen .claude.json
• Én source of truth pr. profil — slut med forældreløs config i home-roden, der stille driver fra profilens
• Følsomme data (oauthAccount, tokens) garanteret med rettigheder 600
• Visuel bekræftelse på aktiv profil ved hver start — umuligt at glemme, hvilken profil der er aktiv
• At tilføje en tredje profil = at tilføje én linje i case i funktionen, ikke klone et nyt alias og huske dets navn

Hvor det halter

Jeg vil være ærlig. Dette er ikke en gratis forbedring — et par kompromiser fulgte med i pakken, og dem er det værd at kende på forhånd.

• gum er en ekstra afhængighed (brew install gum, ~13 MB). Hvis du principielt ikke vil installere det — fallback til select i zsh eller en simpel read. Virker, men ser ikke lige så pænt ud og mangler pilenavigation.
• Et Enter-tryk ved hver start. For den, der starter claude dusinvis af gange om dagen — kan irritere. Alternativ nedenfor (direnv).
• Symlinket ~/.claude → personal gør personal til default. Hvis du har brug for work-profilen som default, skal du pege symlinket om (ln -sf). Ikke svært, men det er ikke "glem det og intet går i stykker".
• Symlinket kan teoretisk gå i stykker, hvis et eller andet værktøj atomisk overskriver ~/.claude.json via et temp+rename-mønster (write-file-atomic). I praksis gør Claude Code det ikke selv, men hvis du installerer tredjepartsplugins — så tjek.
• Hvis du har forskellige Anthropic-konti på profilerne med forskellige planer — efter skift kan der være et sub-sekund lag, mens Claude Code synker OAuth-state. I min brug er det ikke mærkbart, men det er ikke nul.

Alternativer, jeg overvejede

direnv — sætter CLAUDE_CONFIG_DIR automatisk baseret på en .envrc i roden af hvert projekt. Nul interaktion, nul klik. Minus: du skal lægge en .envrc i hvert work-root, og hvis du kører claude i en ukendt mappe — får du default-profilen (som måske ikke er den, du vil have). For den, der lever i et begrænset antal work-roots og vil slippe for at klikke — er direnv reelt bedre.

Symlink-baseret skift (én aktiv profil ved at pege ~/.claude-symlinket om) overvejede jeg også og forkastede med det samme. Du kan ikke have to terminaler med forskellige profiler åbne på samme tid — det globale "aktuelle" er ét. For mig er det en deal-breaker.

Konklusion

v2 er ikke bare bedre UX oven på v1. Det er en anerkendelse af, at Claude Code har en skjult arkitektonisk særegenhed (~/.claude.json som separat fil i home-roden, skrevet af --scope user-kommandoer uafhængigt af CLAUDE_CONFIG_DIR), som man skal tage højde for, hvis man vil have ægte isolation mellem profiler. Den første tilgang (~/.claude + ~/.claude-promova + alias) virkede til 80 %, men de resterende 20 % viste sig som stille state-drift mellem profilerne. Nu er der taget højde for det. Hvis du lige er begyndt — start direkte på v2. Hvis du allerede sidder på v1 — migrationsscriptet er ovenover, flytningen tager fem minutter og bryder ingenting (det er netop jq-mergen, der er det trin, som redder dig fra at miste state).

To regler har forvandlet hallucineringsfyldte workflows til pålidelige pipelines for mig: én agent, én specialisering, og alt, der kan køre som en shell-kommando, skal køre som en shell-kommando. Det er ikke teori. Det er hvad jeg gør hver dag med Claude Code, og det er de mønstre, der faktisk rykker noget.

Hvorfor generalistagenter lyver

LLM'er er next-token-predictors. Når en prompt beder om to roller — byg X og verificer X — afslutter modellen den første rolle, og forudsiger derefter, hvordan outputtet fra den anden rolle ville se ud, uden rent faktisk at udføre den. Selvverificering er strukturelt svag: samme kontekst, samme model, samme blinde vinkler. Bestået på verificering korrelerer med bestået på bygning — de fejler sammen.

Modellen ved ikke, at den lyver. Fra dens perspektiv er jeg verificerede alt omhyggeligt en sammenhængende fortsættelse af at have skrevet koden. Det er samme grund til, at er du sikker?-prompts ikke fanger hallucinationer: modellen er lige så sikker i andet omgang. Sikkerhed korrelerer ikke med korrekthed — den korrelerer med, hvor plausibelt den næste sætning lyder.

Løsningen er ikke bedre prompts. Vær forsigtig, dobbelttjek, halluciner ikke — de instrukser gør ingenting. Løsningen er strukturel: specialisér agenten, så den fysisk ikke kan lade som om, og rut kvantitativt arbejde gennem shell, så svaret kommer fra reel tilstand, ikke fra tokensandsynlighed.

Regel 1: én agent, én specialisering

Del arbejdet op i separate agenter med separate kontekster. Hver agent har ét ansvar og et stramt værktøjssæt. Hele workflowet bliver et stafetløb i stedet for én agent, der løber runder:

• Builder-agent: tager spec'en, skriver koden. Det er hele jobbet. Den har Read, Edit, Write, Bash.
• Reviewer-agent: tager spec'en plus diff'en, tjekker acceptance criteria. Frisk kontekst. Ingen viden om hvordan koden blev skrevet — kun hvad der kom ud. Den har Bash, Read, Grep, Glob — slet ingen write-værktøjer.
• Analytics-agent: besvarer dataspørgsmål ved at konstruere og køre queries. Kun Bash. Kan ikke nå svaret uden at køre en reel kommando.
• Orchestrator: den primære session, der dispatcher hver agent i tur og aldrig beder én agent om at gøre en andens job.

Konkret eksempel: UI-implementering plus et visuelt tjek mod en Figma-mockup. Builderen skriver komponenterne og committer diff'en. Orchestratoren kalder derefter revieweren med design-URL'en, diff'en og eksplicitte acceptance criteria. Revieweren kører Playwright, tager screenshots, differ dem mod referencen og returnerer PASS eller FAIL med de faktiske screenshot-stier og pixel diffs. Builderen kommer aldrig i nærheden af verificeringstrinnet — og det er præcis derfor, verificeringen er ægte.

Anti-mønsteret er mega-agenten: en enkelt prompt, der siger byg dette UI og sørg for, at det matcher mockuppen. Jeg garanterer dig, den vil rapportere, at alt matcher. Det gør det ikke. Narrativet jeg verificerede er bare den mest sandsynlige tokensekvens efter jeg byggede det.

Regel 2: shell frem for prompt, altid

Alt kvantitativt, alt der rører ved reel tilstand, alt hvor svaret kan være forkert på en måde, der ser rigtigt ud — kør det gennem sh. Agentens job er at konstruere og køre kommandoen, derefter læse outputtet. Agenten er ikke kilden til sandheden. Shell-outputtet er.

• Optælling: wc -l logs.txt er sandt. Der er cirka 47 log-linjer fra en model er en hallucination.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Ikke estimér volumen.
• Tests: pnpm test --reporter=json | jq '.numFailedTests'. Ikke opsummér hvad der fejlede.
• Git-tilstand: git rev-list --count main..HEAD, git diff --stat. Ikke tæl commits eller beskriv ændringerne.

Når du har internaliseret det, begynder du at lægge mærke til hvert sted, agenten var ved at finde et tal på. Det ser ud til, at der er omkring 200 records... — nej. Kør SELECT count(*). De fleste tests består... — nej. Kør test-suiten, parse JSON'en. Modellen er fremragende til at konstruere kommandoen. Den er upålidelig, når det gælder om at være kommandoen.

Fejltilstande jeg faktisk har ramt

Det er ikke hypotetiske eksempler. Hver af disse kostede mig reel tid, før jeg ændrede mønsteret:

• Spøgelsesverificering. Agenten sagde jeg tjekkede alle 14 sektioner mod mockuppen. Den åbnede ikke mockuppen. Den tog ikke et screenshot. Tjekket var et hallucineret trin i narrativet.
• Selvsikre forkerte tal. Spurgte efter monthly active users fra analysedata. Fik et tal, der var ~3× forkert. Modellen interpolerede fra sample-rækker i stedet for at køre den faktiske query.
• Opfundne filændringer. Agenten sagde jeg opdaterede config/feature-flags.json. Det havde den ikke. Den havde kun haft til hensigt at gøre det. git diff var tom.
• Falske testkørsler. Alle tests består. Ingen tests blev udført. Agenten kaldte aldrig test-runneren — den forudsagde, hvordan test-runnerens output ville have set ud.

Alle fire løses af de samme to regler: split agenten, push til shell. Revieweren har ikke Write, så den kan ikke fake-redigere filer. Analytics-agenten har kun Bash, så den kan ikke returnere et tal, der ikke kom fra en query. Strukturel umulighed slår gode intentioner hver eneste gang.

Sådan strukturerer du det i Claude Code

Claude Code understøtter sub-agenter defineret i .claude/agents/*.md. Hver agentfil erklærer et navn, en beskrivelse, et tilladt værktøjssæt og en system prompt. Orchestratoren (din primære session) dispatcher dem via Agent-værktøjet. Her er den slags definition, jeg bruger til revieweren — kort, snæver og fysisk ude af stand til at 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

Bemærk værktøjssættet: Bash, Read, Grep, Glob. Ingen Write, ingen Edit, ingen Agent. Revieweren kan køre kommandoer, læse filer, søge efter mønstre — og intet andet. Hvis den forsøger at præsentere en hallucineret diff som verificeret, gør formen af dens værktøjskald det åbenlyst: der var ingen reelle tjek. Du kan auditere værktøjskaldene og se præcis, hvad der blev undersøgt.

Orkestreringsmønsteret: den primære session kalder Builder → venter → kører git diff selv for at fange den faktiske ændring → kalder Reviewer med spec'en og diff'en → læser Reviewerens dom. Den primære session beder aldrig én agent om at gøre begge dele. Værktøjsrestriktioner er stærkere end prompt-instrukser: fake ikke verificeringen er et ønske. Ikke at have Write er et faktum.

Anti-mønstre der bør pensioneres

Ting jeg ser i prompts, der ikke gør noget — eller værre, giver en falsk følelse af sikkerhed:

• Vær forsigtig og dobbelttjek dit arbejde. Genererer ingen yderligere adfærd. Modellen producerer allerede det, der ligner omhyggeligt arbejde.
• Sørg for, at du faktisk verificerer. Ordet faktisk tilføjer ingen semantik, modellen kan handle på. Den vil faktisk hævde at have verificeret.
• Halluciner ikke. Et prompt engineering-meme. Hallucination er ikke en knap, modellen kan slukke.
• Stole på agenten på små tal. Små tal er der, den lyver mest selvsikkert. Der er ingen ærligheds-nedre grænse.
• Tilføje flere regler til prompten for at tvinge ærlighed. Strukturelle fixes (split + shell) slår prompt-tweaks hver eneste gang. Hvis en regel skal håndhæves, kodificér den i værktøjsadgang, ikke på dansk.

Hvis din strategi til at fange hallucinationer er mere emfatisk formulering, har du ikke en strategi. Du har et håb.

Den mentale model

En agent er ikke en kollega. Det er en funktion: prompt → tokens. Funktionen er fremragende til at skrive kode og elendig til at introspektere, om den gjorde det rigtige. Behandl dens påstande om sit eget arbejde som en hypotese. Diff'en, exit-koden, screenshottet, row count — det er bevismaterialet. Slutopsummeringen er den mest løgnagtige overflade i hele systemet.

Specialisering er din forsikring mod narrativ drift. Shell er dit eneste ground truth. Builder skriver. Reviewer tjekker. Bash beslutter.

Konklusion

Hvis du skal huske én ting: lad ikke en enkelt agent både producere og bedømme sit eget output, og lad ingen agent besvare et kvantitativt spørgsmål uden at køre en kommando. Alt andet er downstream af disse to regler. Konfigurér værktøjsadgang aggressivt, auditér værktøjskald i stedet for opsummeringer, og hallucinationsoverfladen skrumper fra overalt til et par specifikke steder, du allerede ved, du skal kigge.

Problemet

Claude Code gemmer alt i ~/.claude som standard — OAuth-token, samtalehistorik, global CLAUDE.md, projekthukommelse, MCP-serverkonfigurationer og indstillinger. Med to konti har du brug for to helt adskilte verdener:

• Personlig konto: eget Max/Pro-abonnement, personlig CLAUDE.md med dine præferencer, dine MCP-servere (Obsidian, personlige værktøjer)
• Virksomhedskonto: virksomhedsplan, arbejds-CLAUDE.md med Jira/Slack-integrationsinstruktioner, virksomhedens MCP-servere
• Forskellige OAuth-sessioner: du kan ikke være logget ind på to konti i samme konfigurationsmappe
• Separat projekthukommelse: du vil ikke have at arbejdskontekst lækker ind i personlige sessioner og omvendt

At logge ud og ind hver gang du skifter kontekst er ikke en mulighed. Du mister sessionstilstanden, og det er simpelthen smertefuldt.

Løsningen: CLAUDE_CONFIG_DIR

Claude Code respekterer én enkelt miljøvariabel: CLAUDE_CONFIG_DIR. Sæt den til en vilkårlig sti, og Claude bruger den mappe i stedet for ~/.claude til alt — auth, historik, indstillinger, hukommelse. Hele opsætningen tager 60 sekunder.

Trin 1: Opret en anden konfigurationsmappe

Vælg et navn der passer til dit brugsscenarie:

mkdir ~/.claude-work

Færdig. Claude udfylder den med den nødvendige struktur ved første start.

Trin 2: Autentificer den anden konto

Kør Claude én gang med den nye konfigurationsmappe for at udløse OAuth-login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Browseren åbner sig. Log ind med din virksomhedskonto. OAuth-tokenet gemmes i ~/.claude-work — fuldstændig adskilt fra din personlige session i ~/.claude.

Trin 3: Tilføj et shell-alias

Tilføj dette til din shell-konfiguration så du ikke behøver at huske variablen:

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

Genindlæs din shell:

source ~/.zshrc

Hvad du får

Nu har du to fuldstændig isolerede Claude-miljøer:

• claude — starter med personlig konto, personlig CLAUDE.md, personlig hukommelse
• claude-work — starter med virksomhedskonto, arbejdsspecifik CLAUDE.md, separat hukommelse
• Isoleret historik: arbejdssamtaler forbliver i arbejde, personlige forbliver personlige
• Separate MCP-servere: din personlige Obsidian vault MCP vises ikke i arbejdssessioner
• Uafhængige indstillinger: forskellige tilladte værktøjer, forskellige tilladelsesniveauer, forskellige modelpræferencer per konto

Sådan fungerer det under motorhjelmen

Konfigurationsmappen er den eneste sandhedskilde for Claude Codes tilstand. Her er hvad der lever inde i 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 kører claude-work, læser Claude alt fra ~/.claude-work. Den ved ikke at ~/.claude eksisterer. De to instanser er fuldstændig uafhængige — du kan endda køre dem samtidigt i forskellige terminalfaner.

Skalering til N konti

Mønsteret udvides til et vilkårligt antal konti. Freelancer med flere kunder? Tilføj flere aliaser:

# 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 konfigurationsmappe, sin egen OAuth-session, sin egen CLAUDE.md med kundspecifikke instruktioner.

Praktiske tips

• Navngiv mapper tydeligt: ~/.claude-work, ~/.claude-clientname — du takker dig selv når der er tre eller fire
• Skriv tilpasset CLAUDE.md for hver: arbejds-CLAUDE.md kan inkludere virksomhedsspecifikke instruktioner (Jira-tickets, Slack-kanaler, deployment-procedurer). Den personlige forbliver slank.
• Forskellige MCP-servere per konto: konfigurer arbejdsværktøjer (Jira MCP, Slack MCP, interne API'er) kun i arbejdskonfigurationen. Hold din personlige ren.
• Tjek hvilken konto der er aktiv: kør claude config list i en session hvis du er i tvivl — viser stien til konfigurationsmappen

Hvor denne tilgang kommer til kort

CLAUDE_CONFIG_DIR isolerer per konto, ikke per projekt. Inde i en enkelt profil ser Claude hver MCP-server, du nogensinde har registreret for den konto — på tværs af alle dine projekter. Til ren personlig brug er det som regel fint. I det øjeblik du har flere produktionskritiske projekter under én konto, især i overlappende domæner som fakturering, adminværktøjer eller infrastruktur, introducerer det en konkret risiko mellem projekter: en AI-assistent kan kalde et værktøj fra projekt A, mens den arbejder på projekt B, særligt når begge eksponerer ensartet navngivne operationer.

Profilmønsteret besvarer spørgsmålet which account am I in?. Det besvarer ikke spørgsmålet which project's tools should be active right now?. Til arbejde med højere indsats, stabl et andet isolationslag ovenpå konto-opdelingen:

• Én profil per produktionskritisk projekt, ikke kun per konto: i stedet for ~/.claude og ~/.claude-work, opret ~/.claude-work-billing og ~/.claude-work-admin. Hver profil ser kun de MCP-servere, den faktisk har brug for.
• Projektspecifik MCP via .mcp.json: commit en .mcp.json i projektroden, der kun lister det projekts MCP-servere. Claude samler dem op, når den startes fra den mappe. Hold din globale konfiguration minimal — kun universelle værktøjer (noter, søgning), ingen produktionsendpoints.
• Navngiv MCP-servere utvetydigt: undgå generiske navne som admin, billing, mcp-server. Præfiks med projektet: acme_billing_prod, acme_admin_stage. Et beskrivende navn tvinger til en pause, når noget er ved at blive kaldt fra den forkerte kontekst.
• Gennemgå hvert MCP-værktøjskald inden godkendelse: kald som *_create_*, *_delete_*, *_charge_* fortjener et bevidst andet blik. Den hastighed du end vinder ved generel auto-godkendelse fordamper første gang et værktøj fra det forkerte projekt fyrer mod produktion.

Den generelle regel: opdel profiler aggressivt, hold produktionsklar MCP væk fra default-profilen, og behandl overlap i værktøjsnavne mellem projekter som en smell, der er værd at refaktorere.

Konklusion

Én miljøvariabel. Ét alias. Fuld isolation mellem konti. Ingen logout/login-dans, ingen konfigurationskonflikter, ingen kontekstlækage. Den slags løsning der er næsten skuffende simpel — men det er netop det der gør den god. Sæt op én gang og tænk aldrig på det igen.

Hvad er MCP og hvorfor det ikke er så simpelt

MCP (Model Context Protocol) er en åben protokol fra Anthropic, der lader Claude forbinde til eksterne værktøjer og data. Princippet er simpelt: en lokal server kører, eksponerer "værktøjer" (tools), og Claude kalder dem under samtalen.

For Obsidian findes der teoretisk masser af MCP-servere. I praksis — hver har sine egne problemer.

Hovedproblemet med Obsidian-økosystemet: Obsidian er en lukket applikation uden officiel MCP. Fællesskabet fyldte hullet, men hver implementering går sin egen vej, og ingen har "officiel velsignelse".

Forsøg 1: MarkusPfundstein/mcp-obsidian

Det første værktøj, der dukker op ved søgning. 3.400 stjerner på GitHub, med i alle tutorials. Virker som et sikkert valg.

Hvordan det virker: Python-server baseret på Local REST API-pluginet i Obsidian. Serveren kommunikerer med pluginet via HTTPS, pluginet udfører operationer gennem Obsidian API.

Hvad der gik galt

• Ikke opdateret i 17 måneder
• 85 åbne issues
• Intet move/rename — kun read, write, append, delete
• Local REST API har en dokumenteret datatabs-bug: POST-endpoint kan lydløst overskrive en fil ved append

Ikke egnet til refaktorering — vi skal flytte filer og bevare links. Vi går videre.

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

Fandt en mulighed, der fungerer som et nativt Obsidian-plugin. Det betyder direkte adgang til Obsidians interne API — backlinks, Dataview, linkgraf. Move via det native API opdaterer alle wiki-links automatisk, fordi Obsidian håndterer dette selv.

Installationsvanskeligheder

• Pluginet er ikke i Obsidians officielle katalog (PR afventer med valideringsfejl)
• Skal installeres via BRAT (Beta Reviewers Auto-update Tool)
• Claude Desktop accepterer ikke Bearer token direkte via UI — tvang aktivering af HTTPS i pluginet
• Self-signed certifikat for localhost skaber tillidsproblemer

Gennem alle disse workarounds fik jeg det endelig forbundet. Grundtest — vault.move omskriver [[wikilinks]], virker som forventet.

Hvad der gik galt i produktion

Da jeg startede masserefaktorering (drag-and-drop af dusinvis af mapper i Obsidian + samtidige MCP-operationer), hang serveren i 4+ minutter. Hvorfor: pluginet kører inde i Obsidian. Når Obsidian genindekserer tusindvis af filer efter en massiv strukturændring, blokeres pluginet med det.

Konklusion: afhængigheden af en åben Obsidian-instans og dens indeks er fatal for masseoperationer.

Forsøg 3: @bitbonsai/mcpvault

Logisk — vi har brug for en server, der ikke afhænger af Obsidian. Arbejder direkte med filer på disk. @bitbonsai/mcpvault — anbefalet i mange anmeldelser. Direkte filsystemadgang, simpelt setup (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 værktøjer. Obsidian behøver ikke engang at være åbent.

Før installation tjekkede jeg én kritisk ting — om wiki-links opdateres ved move. Fandt en brugeranmeldelse:

Filesystem-forbindelsen ved ikke, at den er i Obsidian — den ser en mappe med <code>.md</code>-filer og det er det. Ved ikke, at filnavne bærer semantisk vægt, at hver <code>[[wikilink]]</code> vil gå i stykker i det øjeblik du omdøber eller flytter. Auto-update links virker kun når omdøbningen sker indefra appen. Jeg lærte dette efter at have bedt Claude om at rydde op i filnavne og vendte tilbage til et dashboard med halvdelen af links ødelagt.

Bekræftet i mcpvaults egen dokumentation: PR #101 (wiki link resolution) er under review, ikke merget. Så at flytte via mcpvault ville ødelægge halvdelen af vaultet. Ikke egnet.

Forsøg 4: VaultForge (Final)

blacksmithers/vaultforge — specifikt bygget til AI-agenter, der laver refaktorering.

Arkitektonisk korrekt

• Direkte filsystem — ikke afhængigt af Obsidian
• Egen wikilink-motor — implementerer [[wikilink]]-opløsningslogik, der opdaterer alle former (stem, fuld sti, alias, embed)
• Dry run som standard på alle destruktive operationer — viser først hvad der ændres, derefter bekræfter du
• 27 værktøjer mod 8–14 hos konkurrenter: batch_rename, update_links, backlinks (impact analysis), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF clustering)
• MIT-licens, TypeScript, nul underafhængigheder
• Installation på 30 sekunder via .mcpb (one-click-udvidelse til Claude Desktop)

Sikkerhedstest på isolerede filer

Oprettede 4 testfiler med krydslinks — stem-links, links med alias, links med fuld sti. Flytter én fil til en undermappe:

delta.md → subfolder/delta-renamed.md

VaultForge viste en dry run: "1 fil vil blive omdøbt, 3 links vil blive opdateret". Udført for real.

Tjekket bagefter — alle tre linktyper blev opdateret korrekt. Det er præcis hvad alle tidligere værktøjer manglede.

Sådan installerer du VaultForge — Endelig instruktion

Hvis du har macOS og Claude Desktop:

Trin 1

Download .mcpb-filen:

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

Trin 2

Claude Desktop åbner installationsdialogen for udvidelser. Indtast den absolutte sti til dit vault — ingen backslashes, normale mellemrum:

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

Trin 3

Klik på Save. Claude Desktop tilføjer udvidelsen til konfigurationen automatisk. Ingen genstart nødvendig — .mcpb-udvidelser opfanges automatisk.

Trin 4

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

Hvad jeg lærte om Obsidians MCP-økosystem

For det første: "mest populær" betyder ikke "virker". MarkusPfundstein/mcp-obsidian har 3.400 stjerner og er standardanbefalingen, men det er forældet og mangler vigtige operationer.

For det andet: et nativt plugin har en skjult pris. Aaronsb-pluginet så ideelt ud — graph, Dataview, nativt move. Men afhængigheden af en kørende Obsidian-instans og dens indeks gør det uegnet til seriøse masseoperationer.

For det tredje: direkte filsystem uden link-engine er en fælde. Mcpvault er hurtigt og simpelt, men "bare at flytte filer" ødelægger vault-strukturen. Links bærer påtvunget semantik, som filsystemet ikke kender til. Uden sin egen wikilink-logikimplementering bliver værktøjet en landmine.

For det fjerde: test på isolerede data. Før du betror et værktøj masserefaktorering — opret en testmappe med 4–5 filer med krydslinks og se hvad der sker. 5 minutters test sparer timer med genopretning fra backup.

For det femte: behold en git-backup af dit vault. Det vigtigste af alt. Et enkelt git init inde i vaultet og periodiske commits — det er forsikring mod alle fejl fra en AI-agent eller et værktøj. Hvis noget går i stykker — git reset --hard bringer alt tilbage.

Konklusion

Rejsen tog flere timer og tre mislykkede forsøg. Den endelige arkitektur ser sådan ud:

• VaultForge — hovedarbejdsværktøjet. Direkte filsystem + egen wikilink-motor + 27 værktøjer = stabil refaktorering i enhver skala.
• Git — vault-versionering. Gratis rollback for enhver fejl.

Nu kan jeg gøre det, som alt dette blev startet for: bede Claude om at organisere 400 noter i en ordentlig PARA-arkitektur, flette duplikater, tilføje frontmatter, bygge MOC-kort. Hver operation er sikker, links bevares, dry run viser hvad der vil ske, før noget ændres.

Hvis du også kigger på dit rodede Obsidian og vil have en AI-assistent — begynd direkte med VaultForge. Gentag ikke min rute gennem døde projekter, beta-plugins og filsystemservere uden linklogik.

Hvad hvis hvert sort hul er et Big Bang for et nyt univers? Denne artikel udforsker ideen om, at vores univers kan være en knude i et uendeligt rekursivt træ — hvor sorte huller føder sub-universer, energi cirkulerer tilbage via Hawking-stråling, og fysikkens grundlæggende love bevidst er designet til at gøre kontakt mellem universer umulig.

Sort hul = univers

Ideen kom under et øjeblik af eftertanke: et sort hul dannes, når tilstrækkelig masse og tryk koncentreres i et enkelt punkt. Den singularitet — uendelig densitet, uendelig krumning — ligner mistænkeligt de betingelser, vi beskriver for Big Bang.

Hvad hvis det er den samme begivenhed, set fra forskellige sider? Udefra ser vi et sort hul, der sluger materie. Indefra — et nyt univers, der eksploderer til eksistens. Massen og energien, der kollapsede ind i det sorte hul, bliver råmaterialet til et helt nyt kosmos med sine egne stjerner, planeter og måske sine egne sorte huller.

Hvert sort hul i vores univers kan indeholde et univers. Og vores univers kan eksistere inde i et sort hul i et forældre-univers.

Hvorfor universer ikke kan kontakte hinanden

Her er den elegante del: når du først har krydset begivenhedshorisonten, er der ingen vej tilbage. Den generelle relativitetsteori garanterer dette — forældre-universets fremtid ligger helt uden for begivenhedshorisonten, utilgængelig indefra. Fra sub-universets perspektiv er forældre-universet allerede slut. Hele dets tidslinje er allerede passeret.

Dette er ikke en teknisk begrænsning, vi kan overvinde med bedre teknologi. Det er bygget ind i selve rumtidens geometri. Universer er fundamentalt isolerede fra hinanden — ikke af afstand, men af tidens struktur.

Energicyklussen: at låne og tilbagebetale

Men energi går ikke tabt. Hawking-stråling — den kvanteproces, hvorved sorte huller langsomt fordamper — skaber et bemærkelsesværdigt kredsløb:

1. Et forældre-univers skaber et sort hul og overfører energi til et sub-univers
2. Sub-universet gennemlever hele sin livscyklus over billioner af år
3. Det sorte hul fordamper langsomt og returnerer energi til forældre-universet via Hawking-stråling
4. Forældre-universet modtager sin energi tilbage — med renter

Den "rente" er fascinerende: fysikere tror nu, at Hawking-stråling bevarer information. Forældre-universet får ikke blot tom energi tilbage — det får et aftryk af alt, der skete indeni. Hver stjerne der blev dannet, hver planet, hvert øjeblik af bevidsthed — kodet i stråling.

Rekursion helt ned

Hvis du er programmør, er mønsteret umiskendeligt. Dette er rekursion. Hvert univers kalder universe() med mindre energi og skaber sub-universer, der skaber sub-sub-universer, indtil der ikke er nok energi til at danne sorte huller — grundtilfældet.

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 formaliserede en lignende idé som kosmologisk naturlig selektion: universer "reproducerer sig" gennem sorte huller, og hver generation har lidt anderledes fysiske konstanter — optimeret gennem utallige cyklusser for at producere flere sorte huller, flere universer.

Hvor er vi i denne cyklus?

Vores univers er cirka 13,8 milliarder år gammelt. Det lyder ældgammelt, men i sammenhæng med hele dets levetid er vi vidne til den allerførste begyndelse:

Vi eksisterer ved cirka 0,00000000...01% af vores univers' samlede levetid. Stjernernes æra — alt hvad vi kan se — er et kort glimt i den allerførste begyndelse. Universets virkelige historie er den langsomme, tålmodige æra af sorte huller, der skaber og fordamper sub-universer.

Spørgsmålet om højere dimensioner

Alt, der er diskuteret hidtil, opererer inden for vores tredimensionelle forståelse. Men hvis vores univers er et "snit" af noget højere-dimensionelt, kan hele det rekursive træ af sorte huller og sub-universer blot være en skygge af en struktur, vi ikke kan opfatte.

I 1884 skrev Edwin Abbott Flatland — en fortælling om todimensionelle væsener, der ikke kan forestille sig en tredje dimension. En kugle, der passerer gennem Flatland, fremstår som en cirkel, der vokser og skrumper. "Flatlænderne" kan beskrive det matematisk, men aldrig virkelig forstå, hvad de ser. Vi befinder os måske i præcis den samme position i forhold til vores univers.

Hvad er bevidsthed? Hvorfor eksisterer subjektiv oplevelse? David Chalmers kaldte dette det "svære problem" — og det kan være det stærkeste bevis for, at noget opererer hinsides vores dimensionelle rækkevidde.

Alt er låst på det fundamentale niveau

Den mest slående erkendelse er ikke, at vi ikke ved — men at vi ikke kan vide. Enhver undersøgelsesretning rammer en fundamental barriere:

• Vil du se forældre-universet? Blokeret af begivenhedshorisonten
• Vil du forstå bevidstheden? Blokeret — et system kan ikke fuldt ud analysere sig selv (Gödels ufuldstændighedssætninger)
• Vil du vide, hvad der var "før"? Blokeret — tiden begyndte med Big Bang
• Vil du opfatte højere dimensioner? Blokeret af de kognitive begrænsninger hos et tredimensionelt væsen

Filosoffen Colin McGinn kalder dette kognitiv lukning: visse spørgsmål er lukkede for det menneskelige sind, ikke på grund af utilstrækkelige data, men på grund af sindets egen arkitektur. Forskellen mellem "vi ved det ikke endnu" og "vi kan ikke vide det" er dybtgående.

Det eneste der er tilbage: selvforbedring

Hvis enhver udgang er blokeret med vilje — hvis du ikke kan se udad, ikke kan se bagud, ikke kan se opad — er der kun én retning tilbage: indad. Universet synes bevidst konstrueret til at tvinge fokus på selvet.

Denne konklusion kommer ikke fra religion eller filosofilærebøger. Den kommer fra at følge logikken i sorte huller, rekursion, informationsteori og kognitionens grænser. Eksistentialister, buddhister, stoikere og fysikere — alle ankommer til det samme punkt ad forskellige veje: formålet med eksistens kan ganske enkelt være forædlingen af det væsen, der eksisterer.

Vi nåede hertil ikke gennem tro, men gennem fysik — fra sorte huller, gennem rekursive universer, til kundskabens fundamentale blokader, til den eneste åbne dør: at blive bedre.

Referencer

• Lee Smolin — Kosmologisk naturlig selektion
• Stephen Hawking — Hawking-stråling
• David Chalmers — Bevidsthedens svære problem
• Edwin Abbott — Flatland: En romance i mange dimensioner (1884)
• Kurt Gödel — Ufuldstændighedssætningerne

For simple hjemmesider — portfolioer, blogs, landingssider, små virksomhedssider — er et traditionelt CMS ved at blive unødvendig overhead. AI-værktøjer som Claude Code, Cursor og GitHub Copilot kan nu redigere din kodebase direkte, forstå kontekst, oversætte indhold og deploye ændringer via git. Det abstraktionslag, som CMS tilbød, erstattes af en smartere grænseflade: naturligt sprog.

CMS-skatten du betaler

Ethvert CMS medfører en skjult omkostning. Ikke kun abonnementsafgiften — hele økosystemet af kompleksitet, der pakkes omkring din ellers simple hjemmeside:

• Infrastruktur: En database at drifte, et API at vedligeholde, et dashboard at sikre. WordPress alene udgør ~43% af nettet og ~90% af CMS-rettede angreb.
• Ydeevne: Dynamisk sidegenerering, API-kald ved hver forespørgsel, klientside-hydrering af CMS-data. Din portfolio med 3 sider har nu arkitekturen af et SaaS-produkt.
• Leverandørlåsning: Dit indhold lever i en andens databaseskema. Migrere fra Contentful til Sanity? Det er et projekt, ikke en konfigurationsændring.
• Kontekstskift: Rediger kode i din IDE, skift derefter til et browserbaseret CMS-dashboard for at ændre en overskrift. To forskellige mentale modeller for hvad der grundlæggende er den samme operation.
• Omkostning: Headless CMS-priser skalerer ofte med API-kald eller indholdsposter. En personlig blog behøver ikke en indholdsinfrastruktur til $99/måned.

For en markedsføringsside, hvor 50 personer redigerer indhold dagligt, er denne omkostning berettiget. For en udviklerportfolio eller en lille virksomheds landingsside? Du bygger en bro over en vandpyt.

Hvad der ændrede sig: AI forstår din kode

Grunden til at CMS eksisterede var ligetil: ikke-tekniske personer (og selv udviklere, der ikke ville røre kode for indholdsændringer) havde brug for en visuel grænseflade til at opdatere hjemmesider. Koden var for kompleks, for skrøbelig, for let at ødelægge.

AI ændrede denne ligning fundamentalt. Moderne AI-kodeværktøjer gør ikke blot autofuldførelse — de forstår projektstruktur, læser eksisterende mønstre og foretager kontekstuelt korrekte redigeringer. Ændringen i arbejdsgangen 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

Det her er ikke hypotetisk. Denne blog kører på SolidStart med indhold gemt som TypeScript-filer. Hver artikel — inklusive denne — blev skabt ved at fortælle AI hvad den skal skrive, gennemgå resultatet og pushe til git. Intet CMS-dashboard. Ingen database. Intet API-lag mellem indholdet og koden.

Virkelige eksempler fra denne side

Denne hjemmeside understøtter 10 sprog, har en blog, genererer OG-billeder dynamisk og producerer RSS-feeds og sitemaps. Sådan ser indholdslaget ud — 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 gør med AI, som traditionelt ville kræve et CMS:

• Tilføje et nyt blogindlæg: "Skriv en ny artikel om X, følg samme struktur som eksisterende indlæg" — AI opretter filen, tilføjer oversættelser, registrerer den i indekset
• Opdatere landingssidetekst: "Skift hero-overskriften til Y" — AI finder den rigtige fil og opdaterer den
• Oversætte indhold: "Tilføj tysk oversættelse for prissiden" — AI læser den engelske version og producerer en kulturelt tilpasset oversættelse, ikke en ord-for-ord-kopi
• Rette en stavefejl: "Der er en stavefejl på about-siden, 'recieve' skal være 'receive'" — klaret på 3 sekunder, committet til git med en meningsfuld besked

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

Lad os være ærlige om hvad CMS bragte til bordet, og hvordan hver evne mapper til AI-arbejdsgangen:

Den centrale indsigt: git er allerede et bedre versionskontrolsystem end noget CMS nogensinde har bygget. Og naturligt sprog er en bedre grænseflade end nogen WYSIWYG-editor — fordi det bærer hensigt, ikke blot formatering.

Paradigmeskiftet: kode er indholdslaget

Vi er vidne til en inversion. I to årtier var tendensen at adskille indhold fra kode — lægge indholdet i en database, eksponere det via API, rendere det i frontend. Det gav mening, da kode var svær at redigere, og indhold skulle være tilgængeligt for ikke-udviklere.

AI gjorde ikke CMS forældet ved at være et bedre CMS. Det gjorde CMS forældet ved at gøre kode lige så tilgængelig som et dashboard.

Udviklingen af indholdsadministration på nettet følger en tydelig bane:

1. 2000'erne: Monolitiske CMS (WordPress, Drupal) — indhold og præsentation koblet i ét system
2. 2010'erne: Headless CMS (Contentful, Strapi) — indhold adskilt via API, renderet af frontend-frameworks
3. 2020'erne: Statiske site-generatorer + Markdown (Hugo, Astro) — indhold som filer, bygget ved deploy
4. 2025+: Kode-som-indhold + AI — indholdet lever i typet kode, AI er redigeringsgrænsefladen

Hvornår du stadig har brug for et CMS

Det her er ikke et "CMS er dødt"-standpunkt. CMS løser reelle problemer i stor skala. Du har stadig brug for et, når:

• Store redaktionsteams: 10+ indholdsredaktører, der har brug for rollebaseret adgang, godkendelsesworkflows og samtidig redigering. Git merge-konflikter er ikke en indholdsredaktørs problem at løse.
• Højfrekvent indhold: Nyhedssider, der publicerer 50+ artikler om dagen, har brug for optimerede redaktionspipelines, ikke git-commits.
• Komplekse indholdsrelationer: E-handelskataloger med tusindvis af SKU'er, produktvarianter og dynamisk prissætning kræver strukturerede databaser.
• Regulatorisk overholdelse: Brancher, der kræver revisionsspor, indholdsgodkendelseskæder og lovpålagte gennemgangsprocesser, har brug for specialbyggede systemer.

Grænsen er tydelig: hvis dine indholdsændringer kræver koordinering mellem flere ikke-tekniske interessenter med høj frekvens, fortjener CMS sin kompleksitet. Hvis du er soludvikler, et lille team, eller administrerer en side, der ændrer sig ugentligt snarere end hver time — er AI + kode enklere, hurtigere, billigere og mere pålideligt.

Fremtiden: AI som den universelle grænseflade

Tendensen rækker ud over CMS. Ethvert softwareabstraktionslag, der eksisterede fordi "det underliggende system er for komplekst til direkte interaktion", komprimeres af AI. Admin-dashboards, konfigurations-UI, visuelle databaseeditorer — alle disse er grænseflader, der oversætter menneskelig hensigt til systemændringer. AI udfører denne oversættelse nativt.

For simple hjemmesider er fremtiden allerede her. Dit indhold er kode. Din editor er AI. Din versionskontrol er git. Dit deploy er et push. Hele CMS-laget — dashboardet, databasen, API'et, hostingen — var middleware mellem din hensigt og din hjemmeside. AI fjernede behovet for den middleware.

Det bedste CMS er intet CMS. Ikke fordi indholdsadministration ikke betyder noget — men fordi AI gjorde selve koden til den mest intuitive grænseflade til indholdsadministration, vi nogensinde har haft.

Perplexity Desktop understøtter MCP (Model Context Protocol)-forbindelser. Ved at tilføje den officielle @modelcontextprotocol/server-filesystem-server, der peger på dit Obsidian-vault, kan du bede Perplexity på naturligt sprog om at læse, oprette og redigere noter — direkte fra chatten. Ingen plugins, ingen udvidelser, ingen kopiering.

Problemet

Perplexity er fremragende til research — det søger på nettet, opsummerer kilder og giver svar med citater. Men når du vil gemme fundene i dit Obsidian-vault, bryder workflowet sammen: kopier tekst, skift til Obsidian, find den rigtige note, indsæt, formater. Hver. Eneste. Gang.

Browserudvidelser som "Perplexity to Obsidian" hjælper med eksport, men de er envejs — AI'en kan ikke se dit vault, kan ikke læse dine eksisterende noter og kan ikke beslutte, hvor ting skal placeres baseret på din mappestruktur.

Hvad er MCP?

Model Context Protocol (MCP) er en åben standard, der lader AI-modeller interagere med lokale værktøjer og datakilder. Tænk på det som en USB-port til AI — du tilslutter en "server" (et lille program), og AI'en får nye evner. I vores tilfælde giver filesystem-serveren Perplexity 14 værktøjer til at arbejde 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øglepunktet: AI-modellen har ikke direkte adgang til dine filer. Den kalder værktøjer leveret af MCP-serveren, som kører lokalt på din maskine. Dine data forlader aldrig din computer, medmindre du eksplicit beder AI'en om at gøre noget med dem.

Krav

• Perplexity Pro-abonnement (MCP-forbindelser er tilgængelige for betalende brugere)
• Perplexity Mac App fra App Store (ikke browserversionen)
• Node.js installeret på din Mac (for at npx virker)

Trin-for-trin opsætning

Hele opsætningen tager cirka 2 minutter:

Kommandoen

Kommandoen der skal indsættes i Command-feltet:

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

Erstat stien med den faktiske placering af dit Obsidian-vault. Hvis dit vault synkroniseres via iCloud, vil stien være under ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. Sørg for at beholde anførselstegnene — stien indeholder sandsynligvis mellemrum.

Sådan bruger du det

Når forbindelsen viser Running med 14 tilgængelige værktøjer, gå til en vilkårlig Perplexity-chat og begynd at tale med dit vault:

> 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 din vault-struktur, respekterer dine formateringskonventioner og kan arbejde med eksisterende indhold. Du kan bede den undersøge et emne på nettet og gemme resuméet direkte i en specifik note.

Hvorfor MCP er bedre end andre tilgange

Før MCP var der begrænsede måder at forbinde Perplexity og Obsidian på:

Nuværende begrænsninger

• Kun Mac — Perplexitys MCP-forbindelser fungerer i øjeblikket kun i Mac App Store-versionen
• Ingen Obsidian API-integration — filesystem-serveren arbejder med rå filer, ikke gennem Obsidians API. Det betyder, at den ikke udløser Obsidian-plugins (Linter, Templater) ved filoprettelse
• Godkendelse påkrævet — følsomme filoperationer kan kræve din bekræftelse i Perplexity-appen — det er en sikkerhedsfunktion, ikke en fejl

Konklusioner

Denne opsætning forvandler Perplexity fra et researchværktøj til et research-og-fangstværktøj:

1. Søg på nettet og gem i Obsidian i én samtale
2. AI'en ser din vault-struktur og tilpasser sig dit organisationssystem
3. Nul appskift — alt sker 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-script der kører Claude Code CLI i headless-tilstand hver morgen kl 9:00. Det søger nyheder inden for 11 konfigurerbare emner, filtrerer støj og skriver en formateret markdown-digest direkte til en Obsidian vault synkroniseret via iCloud. Nul afhængigheder. ~100 linjer konfiguration i alt.

Problemet

Som udvikler er det en daglig skat at holde sig opdateret. RSS-feeds er støjende, Twitter er en tidssluger, nyhedsbreve ankommer når man er dybt fokuseret. Jeg havde brug for noget der laver research for mig.

Den typiske løsning er at bygge en scraping-pipeline: planlægger, crawler, NLP-pipeline, database, notifikationstjeneste. Det er ugers arbejde. Jeg ville have noget der kan bygges på en eftermiddag.

Arkitektur

Hele systemet er 4 filer og nul afhængigheder:

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)

Projektet er bevidst minimalt.

Indgangspunkt: digest.sh

Hele applikationen er et 6-linjers bash-script:

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

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

Vigtige flags: -p kører Claude i headless-tilstand, --max-turns 20 giver agenten nok ture, --allowedTools begrænser agenten til læsning, søgning og skrivning.

Hjernen: prompt.md

Her bor intelligensen. Prompten forvandler Claude til en nyhedsforskningsagent:

# 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

Konfiguration: topics.yaml

Emner er fuldt konfigurerbare — tilføj et nyt 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"

Planlægning med launchd

På macOS er launchd den native måde at planlægge tilbagevendende opgaver:

<?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. Scriptet kører dagligt kl 9:00.

Hvordan resultatet ser ud

Hver morgen dukker en ny markdown-fil op 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 tal

Vigtige designbeslutninger

• Claude Code CLI fremfor API — ingen håndtering af API-nøgler eller HTTP-klienter
• Obsidian fremfor email — digests er søgbare, linkbare og permanente
• launchd fremfor cron — macOS-native planlægger med håndtering af tabte kørsler
• YAML til emner — nyt emne = 2-linjers ændring
• Spring tomme emner over — ingen nyheder = ingen sektion

Byg din egen

Klar på 10 minutter:

1. Installer Claude Code CLI og autentificer
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

Konklusioner

Det mest interessante ved dette projekt er hvad der ikke er i det. Ingen database, ingen API-server, ingen Docker, ingen npm-pakker, ingen Python, ingen HTML-parser, ingen NLP-pipeline.

Sådan ser det ud at bygge med AI-agenter: du definerer hvad og hvor, agenten håndterer hvordan. Total udviklingstid: 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 et <script>-tag inde i en React Client Component for at forhindre temaflimmer (FOUC). React 19 advarer om dette. Biblioteket er ikke opdateret siden marts 2025. Løsning: Zustand-store + useServerInsertedHTML. Nul afhængigheder, nul FOUC, nul advarsler.

Problemet

Hvis du bruger next-themes med Next.js 15+ og React 19, får du denne konsollfejl ved hver sideindlæsning:

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 hydreringsfejl. React 19 advarer om, at <script>-tags i klientkomponenter aldrig vil blive udført. Scriptet virker i SSR, men React markerer det.

Hvorfor det sker

next-themes sætter temaklasse inden hydrering ved at injicere et inline-script 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 ændrede adfærden — script-tags i komponenter markeres nu. suppressHydrationWarning hjælper ikke her.

Hvad vi prøvede (og hvorfor det mislykkedes)

Vi prøvede systematisk hver tilgang:

Løsningen: Zustand + useServerInsertedHTML

useServerInsertedHTML injicerer HTML i SSR-strømmen uden for React-træet. Scriptet er i HTML, men React "ser" det ikke på klienten. Kombineret med Zustand til reaktiv tematilstand — komplet erstatning, nul afhængigheder.

Sådan fungerer det

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

Trin 1: Zustand-store

Storen håndterer tematilstand, DOM-klasser, systemdetektering og synkronisering på tværs af faner. _init() returnerer en oprydningsfunktion til 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,
  }));
}

Trin 2: ThemeProvider

Provideren injicerer FOUC-forebyggende script 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}</>
}

Trin 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>
  )
}

Trin 4: Brug 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>
  );
}

Migration fra next-themes

API'et er bevidst identisk. Migration er én enkelt importændring 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 der bruger useServerInsertedHTML. Virker, men endnu en afhængighed med én vedligeholder. Hvis next-themes lærte os noget — afhængigheder bliver opgivet. Med ~100 linjer kode ejer du hele løsningen.

next-themes@1.0.0-beta.0

Findes på npm, ingen udgivelsesdato, ingen ændringslog, uklart om React 19-advarslen er rettet. Ikke værd at satse produktionskode på.

Kun CSS (prefers-color-scheme)

Virker til systemdetektering, kan ikke håndtere localStorage-persistens, manuel skift eller "system"-muligheden. Kræver JavaScript.

Konklusioner

1. next-themes er reelt opgivet — seneste udgivelse marts 2025, React 19-advarsel urettet
2. useServerInsertedHTML er den korrekte Next.js-primitiv til scriptinjektion uden React-advarsler
3. Zustand giver reaktiv tematilstand med mindre kode end en Context-provider
4. Hele løsningen ~100 linjer, nul nye afhængigheder, du ejer 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

Vores app (Promova) bruger Next.js 16 med en Landing Builder — et CMS-drevet system, der samler marketingsider fra ~90 forskellige sektionskomponenter. Arkitekturen bruger en sectionRegistry.tsx, der mapper sektionsnavne til next/dynamic()-kald:

// 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 renderer kun 5-8 sektioner. 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 tilgængelige og genererer <link rel="stylesheet"> for hvert SCSS-modul. Selv sektioner, der aldrig renderes på siden, får deres CSS injiceret i <head>. Dette er en bekræftet, forventet adfærd i Next.js App Router. Ingen rettelse er planlagt.

Alt, hvad jeg prøvede (og hvorfor det fejlede)

Jeg brugte dage på at gennemgå enhver tilgang, jeg kunne finde. Her er den fulde liste:

inlineCss-fælden

Next.js har et experimental.inlineCss-flag, der erstatter alle <link rel="stylesheet"> med inline <style>-tags. Lyder perfekt, ikke?

Problemet: det er alt eller intet. Du kan ikke aktivere det per rute. Hvis du har SSR-sider (force-dynamic), genopbygger hver anmodning al CSS inline. Vi prøvede — vores headless CMS kunne ikke klare belastningen.

Opdagelsen: Turbopack Import Attributes

Ved at grave i Next.js 16.2 release notes fandt jeg en dårligt dokumenteret funktion: Turbopack Import Attributes. Den lader dig tilsidesætte den indbyggede bundler-pipeline for en specifik import med TC39 with {}-syntaks:

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

Dette fortæller Turbopack: "Behandl ikke denne import som et stilark. Kør den gennem min brugerdefinerede loader og behandl outputtet som JavaScript."

Dette er den afgørende indsigt. I stedet for at Turbopack genererer et <link rel="stylesheet">, der blokerer rendering, kompilerer vores loader SCSS og eksporterer det som en JS-streng. Resultat: kun CSS for sektioner, der faktisk renderes, ender i sidens HTML.

Løsningen

1. Brugerdefineret Turbopack Loader

Et ~70-linjers Node.js-script 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')
}

Hvad den gør: styles — det samme scopede klassenavnkort som standard CSS Modules. cssText — kompileret CSS som streng.

2. InlineStyle-komponent

Bruger React 19s indbyggede <style href precedence>-API til automatisk deduplicering:

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

React 19 garanterer: samme href → kun ét <style> i DOM.

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

// 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-filerne forbliver nøjagtig de samme. Ingen CSS-omskrivning.

Hvorfor dette er bedre end inlineCss: true

Her er den kritiske forskel:

Med inlineCss: true får en side stadig ALLE 94 stilark inline. Med vores tilgang ender kun CSS, der faktisk renderes, i HTML'en.

Turbopack-fælden: ingen globale regler for .module.scss

En fælde jeg faldt i: du tror måske, at du kan tilføje en Turbopack-regel i next.config.ts for at anvende loaderen globalt:

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

Gør ikke dette. Turbopacks indbyggede CSS-modul-pipeline opfanger .module.scss-filer før brugerdefinerede regler anvendes, hvilket forårsager:

FATAL PANIC: inner asset should be CSS processable

with {}-attributter fungerer, fordi de instruerer Turbopack på importstedet om at omgå CSS-modul-pipelinen fuldstændigt.

Resultater

127 sektionskomponenter migreret i Landing Builder. Produktionsbuild verificeret.

Begrænsninger

• with {} per import er ordrig — hver import kræver 3 ekstra linjer.
• Kun Turbopack — with {}-attributter understøttes ikke af Webpack.
• Klassenavnhashing — vores loader bruger en anden hashingsalgoritme end Turbopacks indbyggede.
• HTML-størrelse stiger — CSS er inline i HTML i stedet for cachede separate filer.

Hvornår du skal bruge dette

Denne teknik er mest effektiv, når:

1. Du har et registry/barrel-mønster — én fil importerer mange komponenter, men kun få renderes per side
2. Du bruger Turbopack — Import Attributes er Turbopack-specifikke
3. Du vil have kontrol per komponent — ikke et alt-eller-intet-flag
4. Din SCSS er kompleks — variabler, mixins, breakpoints, nesting — alt understøttet
5. Du ikke kan bruge experimental.inlineCss — fordi du har SSR-sider eller ønsker granulær kontrol

Relaterede GitHub Issues

Hvis du er påvirket af render-blokerende CSS i Next.js App Router — du er ikke alene:

Kerneproblemet

• #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-funktionen & 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

Fællesskabet søger 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-fejl

• #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 sproglæringsplatform, der betjener millioner af brugere.

Next.js patcher den globale fetch og tilføjer et cache-lag, der holder referencer til responsdata, efter de burde have været frigivet. Hvert fetch-kald tilføjer hukommelse, der aldrig returneres til GC. I Docker/Kubernetes fører dette til OOM-nedbrud hver par timer. Buggen har eksisteret siden Next.js 14 (april 2024) og er stadig uløst i 16.2.x (marts 2026). På Vercel viser problemet sig ikke takket være efemere serverless-funktioner.

Hvordan normal fetch fungerer

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

Hvordan fetch fungerer i Next.js

Next.js opfanger den globale fetch og pakker den ind med sit 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

Hvad der sker i produktion

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 versioner

Next.js — Alle versioner med App Router

Node.js

Testet på Node.js 20, 22, 24, 25 — lækker på alle.

Hvad der ikke virker

Hvad der virker (workarounds)

Begrænsning med axios-workaround

Dine egne API-kald kan erstattes med axios. Men Next.js bruger internt den patchede fetch til:

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

Selv uden en eneste fetch i din kode — bruger Next.js den stadig internt.

Hvorfor Vercel ikke fikser det

Forretningslogik

Vercel er en virksomhed, der tjener penge på at hoste Next.js. På deres platform viser problemet sig ikke (serverless = efemert). Buggen påvirker kun self-hosted (Docker, K8s, VPS) — dem, der ikke betaler Vercel.

Officiel position

Tim Neutkens (Vercel-maintainer) analyserede problemet og erklærede det for et undici-problem (Node.js fetch-bibliotek), ikke Next.js. Issue #90433 blev lukket. På trods af at:

• axios og node-fetch på samme Node.js fungerer uden lækager
• Lækagen kun opstår, når fetch går gennem Next.js-wrapperen
• Buggen har været åben i 2 år uden en fix

Prioriteringer

I løbet af disse 2 år har Next.js-teamet udgivet:

• Turbopack (2-5x hurtigere builds) — markedsføringsfordel
• Cache Components / use cache — reducerer 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)

Hvad er det

OpenNext er en open-source-adapter, der konverterer et Next.js-build til et format til AWS Lambda. SST er et framework, der 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 hukommelseslækagen

Lambda-funktioner behandler anmodninger og genbruges efter 5-15 minutters inaktivitet. Hukommelsen når ikke at akkumulere.

Deployment

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

Sammenligning

Lambda-nuancer

• Cold starts — første anmodning er langsommere (~200-500ms)
• Sikkerhed — aktiver OAC (Origin Access Control), ellers er Lambda-URL'en offentlig
• OpenNext — community-projekt, ikke officielt fra Vercel. Nye Next.js-funktioner kan gå i stykker
• Tegnebogsangreb — ved DDoS kan Lambda auto-scaling føre til en stor regning

Hvorfor en rigtig fix er urealistisk

1. Arkitekturproblem

Lækagen er ikke en tilfældig bug, men en konsekvens af en designbeslutning: Next.js opfanger den globale fetch og tilføjer cache/tracking ovenpå. For at fixe det skal måden, App Router interagerer med fetch, redesignes. Dette påvirker ISR, revalidation, data cache, request deduplication — frameworkets kerne.

2. Interessekonflikt

Vercel er ikke motiveret til at fixe det, der ikke påvirker deres platform. Self-hosted konkurrerer med deres forretning. Jo flere problemer i self-hosted — jo flere migrerer til Vercel.

3. Skyldforskydning

Den officielle position er "det er undici, ikke os". Indtil det ændrer sig — vil de ikke arbejde på en fix.

4. Ingen community-fix

Next.js AGPL-3.0-licens tillader forks, men kodebasen er enorm og tæt koblet til Vercel-infrastrukturen. En community-PR til at fixe fetch-wrapperen ville kræve dyb forståelse af den interne arkitektur og godkendelse fra maintainers — som allerede har lukket issuen.

Konklusioner

1. Hvis du er på Vercel — intet problem, intet at gøre
2. Hvis self-hosted og behov for serverless — SST + OpenNext på AWS Lambda
3. Hvis self-hosted Docker — erstat fetch med axios hvor muligt, overvåg RAM, konfigurer automatisk pod-genstart
4. Hvis du starter et nyt projekt — overvej SvelteKit eller Nuxt som alternativer uden dette problem

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