Men efter en månads riktig användning sprang jag på ett par rejäla problem som det inlägget inte täckte. Det största — en dold egenhet hos Claude Code som jag av en slump trampade rakt in i när jag lade till Gmail-MCP:n och den "försvann" från min profil fem minuter senare. Idag byggde jag om alltihop till en ny arkitektur — XDG-kompatibel, med en symlänk och en interaktiv profilväljare via gum. Det här är v2 — en evolution ur verklig erfarenhet, inte en teoretisk förbättring.

Det som började skava

Fyra saker. De första tre handlar om snygghet, synlighet och skala. Den fjärde är den riktiga arkitektoniska fällan som jag inte såg direkt. Jag går igenom dem i tur och ordning, för det är just den fjärde som till slut tvingade fram ombyggnaden.

1. Två separata mappar i $HOME — det är rörigt

~/.claude och ~/.claude-promova — två dotfolders sida vid sida i $HOME-roten. XDG Base Directory Specification säger att konfigar hör hemma i ~/.config/. Dotfile-mappar utspridda direkt i home är ett antimönster som med tiden gör $HOME till en skräplåda. Kosmetiskt, visst, men det stack i ögonen varje gång jag körde ls -la ~.

2. Ingen visuell bekräftelse på aktiv profil

Jag startar claude och vet inte vilken profil som är aktiv — inte förrän jag kör claude config list inne i sessionen. Om jag glömt vilken terminal jag startat var, måste jag kolla. En småsak, men med personal + work i parallell i två flikar tornar det upp sig.

3. Alias skalar inte

Två profiler — claude och claude-promova — okej. Jag lägger till en tredje (en frilanskund) — då behövs ett tredje alias. En fjärde — ett fjärde. Efter ett halvår skulle jag inte minnas vilka alias jag faktiskt skapat.

4. Den dolda fällan i ~/.claude.json

Och det här är det verkliga skälet till ombyggnaden. Claude Code har två olika platser för konfiguration, och dokumentationen skriker inte ut det: ~/.claude/ — katalogen där projects/, sessions/, hooks/, skills/ ligger. Och separat — ~/.claude.json, en fil direkt i $HOME-roten, där oauthAccount, mcpServers, projects-historiken, skillUsage och ungefär 40 andra fält av faktisk live state bor.

Kommandot claude mcp add --scope user skriver just till ~/.claude.json i home-roten, inte till ~/.claude/.claude.json eller profilens katalog. Det visste jag inte. Tills jag en dag trampade rätt i det.

Discovery: varför Gmail-MCP:n "försvann"

I morse satte jag upp Gmail-MCP:n i Claude Code. Vanligt setup: Google Cloud-projekt, OAuth-credentials, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Allt OK. Startade om sessionen — funkar, jag läser mail, svarar på meddelanden. En timme senare började vi refaktorera aliasen till en funktion med gum-profilväljare, och flyttade sedan över alltihop till XDG. Jag körde mv ~/.claude → ~/.config/claude-profiles/personal, startade om CC, valde personal i menyn. Och i den nya sessionen öppnade jag /mcp:

figma            (failed)
playwright-test
claude.ai Notion

Ingen gmail. Ingen vaultforge. Bara tre servrar, varav en till och med failed. Och jag hade just lagt till Gmail. Samtidigt visade sessionen i en annan terminal (work-profilen) Gmail och Vaultforge utan minsta problem.

Jag började gräva och hittade att jag på maskinen hade tre olika filer med namnet .claude.json:

Där hade vi det. Det är just det som är den arkitektoniska fällan:

1. claude mcp add --scope user skriver alltid till ~/.claude.json i home-roten, oberoende av CLAUDE_CONFIG_DIR
2. När CLAUDE_CONFIG_DIR är satt läser Claude Code $CLAUDE_CONFIG_DIR/.claude.json — alltså filen inuti profilen
3. Posterna för "user-scope MCPs" och "profilens MCPs" lever i olika filer med samma namn — och de är lätta att blanda ihop

I mitt fall var ~/.claude.json (home-roten, 113 KB) det levande, aktuella tillståndet — med gmail, vaultforge, OAuth-sessionen, allt. Och ~/.config/claude-profiles/personal/.claude.json (29 KB) visade sig vara en gammal snapshot som av någon anledning redan tidigare legat i gamla ~/.claude/ — kanske skrev en äldre CC-version dit, kanske ett plugin. jq -r 'keys[]' på båda filerna visade att home-root-versionen hade 41 unika nycklar som saknades i snapshoten.

Och de 41 nycklarna är inte skräp. Det är Claude Codes verkliga tillstånd:

• skillUsage — användningsstatistik för skills
• githubRepoPaths — repo-cache för projektnavigering
• cachedGrowthBookFeatures + cachedStatsigGates — feature flags (utan dem hämtar CC nya vid varje start)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — UI-flaggor (utan dem dyker modalerna upp igen vid nästa start)
• lastPlanModeUse, feedbackSurveyState, installMethod — onboarding- och UX-state

Om du bara kör mv ~/.claude ~/.config/claude-profiles/personal utan merge — förlorar du allt detta. Du ser welcome-modalerna igen, githubRepoPaths-sökningen körs på nytt, och alla survey-prompts kommer tillbaka. Som jag nästan gjorde.

Den nya arkitekturen

Allt lever under en gemensam föräldrakatalog i ~/.config/, precis som XDG vill ha det. Varje profil är självförsörjande — den har sitt fulla state inklusive en egen .claude.json. ~/.claude stannar kvar som symlänk till personal-profilen för bakåtkompatibilitet.

~/.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. Varje profil är en separat, isolerad katalog där allt ligger: projects/sessions-mapparna och samma fil med MCP-servrar och OAuth-tokens. En source of truth per profil.

Varför symlänken pekar på personal

Allt som hårdkodat sökvägen ~/.claude/ — gamla skript, plugins, Claude Codes IDE-tillägg, statusline-konfigar som claude-powerline.json — fortsätter fungera utan ändringar. Symlänken resolveras till personal-profilen. Om du av misstag kör command claude (utan wrapper-funktionen) — hamnar du också i personal via default-path lookup. Personal blir den "quiet default" den var förr, men bor nu fysiskt på XDG-platsen.

Interaktiv väljare vid start — funktion + gum

I stället för alias — en funktion claude() i ~/.zshrc som visar en pilmeny via gum (Charms TUI-hjälpverktyg). Funktionen fångar claude-anropet på shell-nivå, låter dig välja profil och kör command claude med motsvarande CLAUDE_CONFIG_DIR. command är viktigt — det förbigår wrapper-funktionen och anropar den riktiga 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
}

Så här ser det ut vid start:

Claude profile:
▸ personal
  promova

↑↓ för att navigera, Enter för att välja, Esc för att avbryta (Claude startar helt enkelt inte). Profilen är alltid synlig — omöjlig att missa.

Migreringsskript

För den som läser det här och vill flytta från det gamla upplägget. Det mest kritiska steget är det andra: det mergar ~/.claude.json från home-roten med det som redan ligger i personal-profilen, och slår ihop mcpServers-listorna. Utan det steget förlorar profilen både sina MCPs och hela sitt 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 steget om rättigheter är viktigt i sig. jq | mv skapar en fil med umask 644 (world-readable). Den innehåller OAuth-tokens. chmod 600 direkt efter mergen är obligatoriskt.

Efter migreringen — stäng och öppna alla aktiva Claude-sessioner, ladda om shellet (source ~/.zshrc eller ny terminal), kör claude, välj profil, verifiera via claude mcp list att alla MCPs är på plats. Om allt är OK — radera ~/.claude.json.migrated.bak. Om något är fel — rollback är trivialt: mv ~/.claude.json.migrated.bak ~/.claude.json och ta bort symlänken.

Det du får

• En gemensam föräldrakatalog i stället för två dotfolders i $HOME — XDG-kompatibelt
• Symlänken bevarar kompatibiliteten med allt som hårdkodar ~/.claude/
• Varje profil är självförsörjande — sitt fulla state och sina MCPs i sin egen .claude.json
• En source of truth per profil — slut på övergiven konfig i home-roten som tyst driver isär från profilens
• Känslig data (oauthAccount, tokens) garanterat med rättigheter 600
• Visuell bekräftelse på aktiv profil vid varje start — omöjligt att glömma vilken profil som är aktiv
• Lägga till en tredje profil = lägga till en rad i case i funktionen, inte klona ett nytt alias och komma ihåg dess namn

Där det brister

Jag vill vara ärlig. Det här är inte en gratis förbättring — några kompromisser följer med på köpet, och dem är värda att känna till i förväg.

• gum är ett extra beroende (brew install gum, ~13 MB). Om du av princip inte vill installera det — fallback till select i zsh eller en enkel read. Funkar, men ser inte lika snyggt ut och saknar pilnavigering.
• Ett Enter vid varje start. För den som drar igång claude tiotals gånger om dagen — kan irritera. Alternativ nedan (direnv).
• Symlänken ~/.claude → personal gör personal till default. Om du behöver work-profilen som default — måste du peka om symlänken (ln -sf). Inte svårt, men det är inte "glöm bort det och inget går sönder".
• Symlänken kan teoretiskt gå sönder om något verktyg atomärt skriver om ~/.claude.json via ett temp+rename-mönster (write-file-atomic). I praktiken gör Claude Code inte det själv, men om du installerar tredjepartsplugins — kolla.
• Om du har olika Anthropic-konton på profilerna med olika planer — efter byte kan det bli en lag på under en sekund medan Claude Code synkar OAuth-state. I min användning märks det inte, men det är inte noll.

Alternativ jag övervägde

direnv — sätter automatiskt CLAUDE_CONFIG_DIR utifrån en .envrc i roten på varje projekt. Noll interaktion, noll klick. Minus: du måste lägga en .envrc i varje work-root, och om du kör claude i en okänd mapp — får du default-profilen (kanske inte den du vill ha). För den som lever i ett begränsat antal work-roots och aldrig vill klicka — är direnv faktiskt bättre.

Symlänk-baserad växling (en enda aktiv profil genom att peka om ~/.claude-symlänken) övervägde jag också och förkastade direkt. Du kan inte ha två terminaler med olika profiler öppna samtidigt — det globala "aktuella" är ett enda. För mig är det en deal-breaker.

Slutsats

v2 är inte bara bättre UX ovanpå v1. Det är ett erkännande av att Claude Code har en dold arkitektonisk egenhet (~/.claude.json som separat fil i home-roten, skriven av --scope user-kommandon oberoende av CLAUDE_CONFIG_DIR) som man måste ta hänsyn till om man vill ha riktig isolation mellan profiler. Den första ansatsen (~/.claude + ~/.claude-promova + alias) fungerade till 80 %, men de återstående 20 % visade sig som tyst state-drift mellan profilerna. Nu är det hanterat. Om du precis börjar — starta direkt med v2. Om du redan sitter på v1 — migreringsskriptet finns ovan, flytten tar fem minuter och bryter ingenting (det är just jq-mergen som räddar dig från state-förlust).

Två regler har förvandlat hallucination-tunga arbetsflöden till tillförlitliga pipelines för mig: en agent, en specialisering och allt som kan köras som ett shell-kommando måste köras som ett shell-kommando. Det här är ingen teori. Det här är vad jag gör varje dag med Claude Code, och det är dessa mönster som faktiskt gör skillnad.

Varför generalistiska agenter ljuger

LLM:er är prediktorer för nästa token. När en prompt ber om två roller — bygg X och verifiera X — avslutar modellen den första rollen och förutsäger sedan hur utdata från den andra rollen skulle se ut, utan att faktiskt utföra den. Självverifiering är strukturellt svag: samma kontext, samma modell, samma blinda fläckar. Godkänt vid verifiering korrelerar med godkänt vid byggandet — de misslyckas tillsammans.

Modellen vet inte att den ljuger. Ur dess perspektiv är jag verifierade allt noggrant en sammanhängande fortsättning på att ha skrivit koden. Det är samma anledning till varför är du säker?-prompts inte fångar hallucinationer: modellen är lika säker vid det andra försöket. Säkerhet korrelerar inte med korrekthet — det korrelerar med hur rimligt nästa mening låter.

Lösningen är inte bättre prompts. Var försiktig, dubbelkolla, hallucinera inte — de instruktionerna gör ingenting. Lösningen är strukturell: specialisera agenten så att den fysiskt inte kan låtsas, och dirigera kvantitativt arbete genom shell:en så att svaret kommer från verkligt tillstånd, inte från tokensannolikhet.

Regel 1: en agent, en specialisering

Dela upp arbetet i separata agenter med separata kontexter. Varje agent har ett enda ansvar och en tight verktygsuppsättning. Hela arbetsflödet blir ett stafettlopp istället för att en agent springer varv:

• Builder-agent: tar spec:en, skriver koden. Det är hela jobbet. Den har Read, Edit, Write, Bash.
• Reviewer-agent: tar spec:en plus diff:en, kontrollerar acceptanskriterier. Fräscht kontext. Ingen kunskap om hur koden skrevs, bara vad som kom ut. Den har Bash, Read, Grep, Glob — inga skrivverktyg alls.
• Analytics-agent: svarar på datafrågor genom att konstruera och köra queries. Bara Bash. Kan inte nå svaret utan att köra ett riktigt kommando.
• Orchestrator: huvudsessionen som dispatchar varje agent i tur och ordning och aldrig ber en agent göra en annans jobb.

Konkret exempel: UI-implementation plus en visuell kontroll mot en Figma-mockup. Builder:n skriver komponenterna och committar diff:en. Orchestratorn anropar sedan Reviewer med design-URL:en, diff:en och explicita acceptanskriterier. Reviewer:n kör Playwright, tar skärmdumpar, jämför dem mot referensen och returnerar PASS eller FAIL med faktiska skärmdumpsvägar och pixel-diffs. Builder:n kommer aldrig i närheten av verifieringssteget — och det är exakt därför verifieringen är verklig.

Anti-mönstret är mega-agenten: en enda prompt som säger bygg det här UI:t och se till att det matchar mockupen. Jag garanterar dig, den kommer rapportera att allt matchar. Det gör det inte. Narrativet jag verifierade är bara den mest sannolika tokensekvensen efter jag byggde det.

Regel 2: shell framför prompt, alltid

Allt kvantitativt, allt som rör verkligt tillstånd, allt där svaret kan vara fel på ett sätt som ser rätt ut — kör det genom sh. Agentens jobb är att konstruera och köra kommandot, sedan läsa dess utdata. Agenten är inte källan till sanning. Shell-utdatan är det.

• Räkning: wc -l logs.txt är sant. Det finns ungefär 47 loggrader från en modell är en hallucination.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Inte uppskatta volymen.
• Tester: pnpm test --reporter=json | jq '.numFailedTests'. Inte sammanfatta vad som misslyckades.
• Git-tillstånd: git rev-list --count main..HEAD, git diff --stat. Inte räkna commits eller beskriv ändringarna.

När du väl internaliserat det här börjar du lägga märke till varje ställe där agenten var på väg att hitta på ett tal. Det verkar finnas ungefär 200 poster... — nej. Kör SELECT count(*). De flesta tester går igenom... — nej. Kör testsviten, parsa JSON:en. Modellen är utmärkt på att konstruera kommandot. Den är opålitlig när det gäller att vara kommandot.

Felmoder jag faktiskt råkat ut för

Det här är inga hypotetiska exempel. Vart och ett av dessa kostade mig verklig tid innan jag ändrade mönstret:

• Spökverifiering. Agenten sa jag kontrollerade alla 14 sektioner mot mockupen. Den öppnade inte mockupen. Den tog ingen skärmdump. Kontrollen var ett hallucinerat steg i narrativet.
• Säkra felaktiga tal. Frågade efter monthly active users från analysdata. Fick ett tal som var ~3× fel. Modellen interpolerade från exempelrader istället för att köra den faktiska queryn.
• Påhittade filändringar. Agenten sa jag uppdaterade config/feature-flags.json. Det hade den inte gjort. Den hade bara haft för avsikt att göra det. git diff var tom.
• Fejkade testkörningar. Alla tester går igenom. Inga tester kördes. Agenten anropade aldrig test runner:n — den förutsåg hur test runner:ns utdata skulle ha sett ut.

Alla fyra löses av samma två regler: dela agenten, skicka till shell. Reviewer:n har inte Write, så den kan inte fejk-redigera filer. Analytics-agenten har bara Bash, så den kan inte returnera ett tal som inte kom från en query. Strukturell omöjlighet slår goda intentioner varje gång.

Hur man strukturerar detta i Claude Code

Claude Code stödjer sub-agents definierade i .claude/agents/*.md. Varje agentfil deklarerar ett namn, en beskrivning, en tillåten verktygsuppsättning och en systemprompt. Orchestratorn (din huvudsession) dispatchar dem med verktyget Agent. Här är den typ av definition jag använder för reviewer:n — kort, smal och fysiskt oförmögen att skriva kod:

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

Lägg märke till verktygsuppsättningen: Bash, Read, Grep, Glob. Ingen Write, ingen Edit, ingen Agent. Reviewer:n kan köra kommandon, läsa filer, söka efter mönster — och ingenting annat. Om den försöker lura igenom en hallucinerad diff som verifierad gör formen på dess verktygsanrop det uppenbart: det gjordes inga riktiga kontroller. Du kan granska verktygsanropen och se exakt vad som inspekterades.

Orchestrerings-mönstret: huvudsessionen anropar Builder → väntar → kör git diff själv för att fånga den faktiska ändringen → anropar Reviewer med spec och diff → läser Reviewer:ns utlåtande. Huvudsessionen ber aldrig en agent göra bådas jobb. Verktygsbegränsningar är starkare än promptinstruktioner: fejka inte verifieringen är en önskan. Att inte ha Write är ett faktum.

Anti-mönster att pensionera

Saker jag ser i prompts som inte gör något — eller ännu värre, ger en falsk känsla av trygghet:

• Var försiktig och dubbelkolla ditt arbete. Genererar inget ytterligare beteende. Modellen producerar redan det som ser ut som noggrant arbete.
• Se till att du faktiskt verifierar. Ordet faktiskt tillför ingen semantik som modellen kan agera på. Den kommer faktiskt hävda att den verifierade.
• Hallucinera inte. Ett prompt engineering-meme. Hallucination är inte en switch modellen kan stänga av.
• Lita på agenten med små tal. Det är på små tal den ljuger mest säkert. Det finns ingen ärlighets-tröskel.
• Lägga till fler regler i prompten för att tvinga fram ärlighet. Strukturella åtgärder (dela + shell) slår promptjusteringar varje gång. Om en regel behöver enforças, koda in den i verktygsåtkomst, inte i text.

Om din strategi för att fånga hallucinationer är mer emfatiska formuleringar har du ingen strategi. Du har ett hopp.

Den mentala modellen

En agent är inte en kollega. Det är en funktion: prompt → tokens. Funktionen är utmärkt på att skriva kod och usel på att introspektera om den gjorde rätt sak. Behandla dess påståenden om sitt eget arbete som en hypotes. Diff:en, exit-koden, skärmdumpen, radantalet — det är bevisen. Sammanfattningen i slutet av ett drag är den mest lögn-benägna ytan i hela systemet.

Specialisering är din försäkring mot narrativt drift. Shell:en är din enda ground truth. Builder skriver. Reviewer kontrollerar. Bash avgör.

Slutsats

Om du ska minnas en sak: låt inte en enda agent både producera och bedöma sin egen utdata, och låt ingen agent svara på en kvantitativ fråga utan att köra ett kommando. Allt annat följer av dessa två regler. Konfigurera verktygsåtkomst aggressivt, granska verktygsanrop istället för sammanfattningar, och hallucinationsytan krymper från överallt till ett fåtal specifika ställen du redan vet att titta på.

Problemet

Claude Code lagrar allt i ~/.claude som standard — OAuth-token, konversationshistorik, global CLAUDE.md, projektminne, MCP-serverkonfigurationer och inställningar. Med två konton behöver du två helt separata världar:

• Personligt konto: egen Max/Pro-prenumeration, personlig CLAUDE.md med dina preferenser, dina MCP-servrar (Obsidian, personliga verktyg)
• Företagskonto: företagsplan, arbets-CLAUDE.md med Jira/Slack-integrationsinstruktioner, företagets MCP-servrar
• Olika OAuth-sessioner: du kan inte vara inloggad på två konton i samma konfigurationskatalog
• Separerat projektminne: du vill inte att arbetskontext läcker in i personliga sessioner och vice versa

Att logga ut och in varje gång du byter kontext är inte ett alternativ. Du förlorar sessionstillståndet, och det är helt enkelt smärtsamt.

Lösningen: CLAUDE_CONFIG_DIR

Claude Code respekterar en enda miljövariabel: CLAUDE_CONFIG_DIR. Sätt den till vilken sökväg som helst, och Claude använder den katalogen istället för ~/.claude för allt — auth, historik, inställningar, minne. Hela setupen tar 60 sekunder.

Steg 1: Skapa en andra konfigurationskatalog

Välj ett namn som passar ditt användningsfall:

mkdir ~/.claude-work

Klart. Claude fyller den med nödvändig struktur vid första start.

Steg 2: Autentisera det andra kontot

Kör Claude en gång med den nya konfigurationskatalogen för att trigga OAuth-login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Webbläsaren öppnas. Logga in med ditt företagskonto. OAuth-token sparas i ~/.claude-work — helt separat från din personliga session i ~/.claude.

Steg 3: Lägg till ett shell-alias

Lägg till detta i din shell-konfiguration så du inte behöver komma ihåg variabeln:

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

Ladda om din shell:

source ~/.zshrc

Vad du får

Nu har du två helt isolerade Claude-miljöer:

• claude — startar med personligt konto, personlig CLAUDE.md, personligt minne
• claude-work — startar med företagskonto, arbetsspecifik CLAUDE.md, separat minne
• Isolerad historik: arbetskonversationer stannar i arbetet, personliga stannar personliga
• Separata MCP-servrar: din personliga Obsidian vault MCP syns inte i arbetssessioner
• Oberoende inställningar: olika tillåtna verktyg, olika behörighetsnivåer, olika modellpreferenser per konto

Hur det fungerar under huven

Konfigurationskatalogen är den enda sanningskällan för Claude Codes tillstånd. Här är vad som lever inuti varje:

~/.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ör claude-work läser Claude allt från ~/.claude-work. Den vet inte att ~/.claude existerar. De två instanserna är helt oberoende — du kan till och med köra dem samtidigt i olika terminalflikar.

Skalning till N konton

Mönstret utökas till valfritt antal konton. Frilansare med flera kunder? Lägg till fler 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'

Varje alias får sin egen konfigurationskatalog, sin egen OAuth-session, sin egen CLAUDE.md med kundspecifika instruktioner.

Praktiska tips

• Namnge kataloger tydligt: ~/.claude-work, ~/.claude-clientname — du tackar dig själv när det finns tre eller fyra
• Skriv skräddarsydd CLAUDE.md för varje: arbets-CLAUDE.md kan innehålla företagsspecifika instruktioner (Jira-tickets, Slack-kanaler, deployment-procedurer). Den personliga förblir mager.
• Olika MCP-servrar per konto: konfigurera arbetsverktyg (Jira MCP, Slack MCP, interna API:er) bara i arbetskonfigurationen. Håll din personliga ren.
• Kolla vilket konto som är aktivt: kör claude config list i en session om du är osäker — visar sökvägen till konfigurationskatalogen

Där den här lösningen inte räcker till

CLAUDE_CONFIG_DIR isolerar per konto, inte per projekt. Inuti en enskild profil ser Claude varje MCP-server du någonsin har registrerat för det kontot — tvärs över alla dina projekt. För rent personlig användning är det oftast okej. I det ögonblick du har flera produktionskritiska projekt under ett konto, särskilt i överlappande domäner som fakturering, adminverktyg eller infrastruktur, introducerar det en konkret risk mellan projekt: en AI-assistent kan anropa ett verktyg från projekt A medan den jobbar med projekt B, särskilt när båda exponerar liknande namngivna operationer.

Profilmönstret besvarar frågan which account am I in?. Det besvarar inte frågan which project's tools should be active right now?. För arbete med högre insatser, stapla ett andra isolationslager ovanpå kontouppdelningen:

• En profil per produktionskritiskt projekt, inte bara per konto: istället för ~/.claude och ~/.claude-work, skapa ~/.claude-work-billing och ~/.claude-work-admin. Varje profil ser bara de MCP-servrar den faktiskt behöver.
• Projektspecifik MCP via .mcp.json: commit:a en .mcp.json i projektroten som listar bara det projektets MCP-servrar. Claude plockar upp dem när den startas från den katalogen. Håll din globala konfiguration minimal — bara universella verktyg (anteckningar, sökning), inga produktionsendpoints.
• Namnge MCP-servrar otvetydigt: undvik generiska namn som admin, billing, mcp-server. Prefixa med projektet: acme_billing_prod, acme_admin_stage. Ett beskrivande namn tvingar fram en paus när något är på väg att anropas från fel kontext.
• Granska varje MCP-verktygsanrop innan du godkänner: anrop som *_create_*, *_delete_*, *_charge_* förtjänar en medveten andra blick. Vilken hastighet du än vinner på rakt av automatiskt godkännande avdunstar första gången ett verktyg från fel projekt avfyras mot produktion.

Den allmänna regeln: dela upp profiler aggressivt, håll produktionsklar MCP utanför default-profilen, och behandla överlapp i verktygsnamn mellan projekt som en smell värd att refaktorera.

Slutsats

En miljövariabel. Ett alias. Fullständig isolation mellan konton. Ingen logout/login-dans, inga konfigurationskonflikter, inget kontextläckage. Den typen av lösning som är nästan besvikande enkel — men det är precis det som gör den bra. Sätt upp en gång och tänk aldrig på det igen.

Vad är MCP och varför det inte är så enkelt

MCP (Model Context Protocol) är ett öppet protokoll från Anthropic som låter Claude ansluta till externa verktyg och data. Principen är enkel: en lokal server körs, exponerar "verktyg" (tools), och Claude anropar dem under konversationen.

För Obsidian finns det teoretiskt gott om MCP-servrar. I praktiken — var och en har sina egna problem.

Huvudproblemet med Obsidian-ekosystemet: Obsidian är en stängd applikation utan officiell MCP. Communityn fyllde gapet, men varje implementation går sin egen väg, och ingen har "officiellt godkännande".

Försök 1: MarkusPfundstein/mcp-obsidian

Första verktyget som dyker upp vid sökning. 3 400 stjärnor på GitHub, med i varje tutorial. Verkar vara ett säkert val.

Hur det fungerar: Python-server baserad på Local REST API-pluginet i Obsidian. Servern kommunicerar med pluginet via HTTPS, pluginet utför operationer via Obsidian API.

Vad som gick fel

• Inte uppdaterat på 17 månader
• 85 öppna issues
• Inget move/rename — bara read, write, append, delete
• Local REST API har en dokumenterad bug för dataförlust: POST-endpoint kan tyst skriva över en fil vid append

Inte lämpligt för refaktorering — vi behöver flytta filer och bevara länkar. Vi går vidare.

Försök 2: aaronsb/obsidian-mcp-plugin

Hittade ett alternativ som fungerar som ett nativt Obsidian-plugin. Det innebär direkt åtkomst till Obsidians interna API — backlinks, Dataview, länkgraf. Move via det nativa API:et uppdaterar alla wiki-länkar automatiskt, eftersom Obsidian hanterar detta själv.

Installationssvårigheter

• Pluginet finns inte i Obsidians officiella katalog (PR väntar med valideringsfel)
• Måste installeras via BRAT (Beta Reviewers Auto-update Tool)
• Claude Desktop accepterar inte Bearer token direkt via UI — tvingade aktivering av HTTPS i pluginet
• Self-signed certifikat för localhost skapar förtroendeproblem

Genom alla dessa lösningar lyckades jag äntligen ansluta det. Grundtest — vault.move skriver om [[wikilinks]], fungerar som förväntat.

Vad som gick fel i produktion

När jag började med massrefaktorering (drag-and-drop av dussintals mappar i Obsidian + samtidiga MCP-operationer), hängde servern i 4+ minuter. Varför: pluginet körs inuti Obsidian. När Obsidian omindexerar tusentals filer efter en massiv strukturförändring, blockeras pluginet med det.

Slutsats: beroendet av en öppen Obsidian-instans och dess index är fatalt för massoperationer.

Försök 3: @bitbonsai/mcpvault

Logiskt — vi behöver en server som inte beror på Obsidian. Arbetar direkt med filer på disk. @bitbonsai/mcpvault — rekommenderas i många recensioner. Direkt filsystemåtkomst, enkel installation (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 verktyg. Obsidian behöver inte ens vara öppet.

Innan installation kontrollerade jag en kritisk sak — om wiki-länkarna uppdateras vid move. Hittade en användarrecension:

Filesystem-anslutningen vet inte att den är i Obsidian — den ser en mapp med <code>.md</code>-filer och det är allt. Vet inte att filnamn bär semantisk vikt, att varje <code>[[wikilink]]</code> kommer att gå sönder i det ögonblick du byter namn eller flyttar. Auto-update links fungerar bara när namnbytet sker inifrån appen. Jag lärde mig detta efter att ha bett Claude rensa filnamn och kom tillbaka till en dashboard med hälften av länkarna trasiga.

Bekräftat i mcpvaults egen dokumentation: PR #101 (wiki link resolution) är under review, inte mergad. Så att flytta via mcpvault skulle förstöra halva vaultet. Inte lämpligt.

Försök 4: VaultForge (Final)

blacksmithers/vaultforge — specifikt byggt för AI-agenter som gör refaktorering.

Arkitektoniskt korrekt

• Direkt filsystem — beror inte på Obsidian
• Egen wikilink-motor — implementerar [[wikilink]]-upplösningslogik som uppdaterar alla former (stem, fullständig sökväg, alias, embed)
• Dry run som standard på alla destruktiva operationer — visar först vad som ändras, sedan bekräftar du
• 27 verktyg 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-licens, TypeScript, noll underberoenden
• Installation på 30 sekunder via .mcpb (one-click-tillägg för Claude Desktop)

Säkerhetstest på isolerade filer

Skapade 4 testfiler med korslänkar — stem-länkar, länkar med alias, länkar med fullständig sökväg. Flyttar en fil till en undermapp:

delta.md → subfolder/delta-renamed.md

VaultForge visade en dry run: "1 fil kommer att döpas om, 3 länkar kommer att uppdateras". Kördes på riktigt.

Kontrollerade efteråt — alla tre länktyper uppdaterades korrekt. Det här är precis vad alla tidigare verktyg saknade.

Hur man installerar VaultForge — Slutgiltig instruktion

Om du har macOS och Claude Desktop:

Steg 1

Ladda ner .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 öppnar installationsdialogen för tillägg. Ange den absoluta sökvägen till ditt vault — inga backslashes, vanliga mellanslag:

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

Steg 3

Klicka på Save. Claude Desktop lägger till tillägget i konfigurationen automatiskt. Ingen omstart behövs — .mcpb-tillägg plockas upp automatiskt.

Steg 4

Verifiera: i en ny chatt fråga: "What is the status of my Obsidian vault?" — bör returnera något som totalFiles: 416, totalDirs: 135, ...

Vad jag lärde mig om Obsidians MCP-ekosystem

För det första: "mest populär" betyder inte "fungerar". MarkusPfundstein/mcp-obsidian har 3 400 stjärnor och är standardrekommendationen, men det är föråldrat och saknar viktiga operationer.

För det andra: ett nativt plugin har en dold kostnad. Aaronsb-pluginet såg idealiskt ut — graph, Dataview, nativt move. Men beroendet av en körande Obsidian-instans och dess index gör det olämpligt för seriösa massoperationer.

För det tredje: direkt filsystem utan link-engine är en fälla. Mcpvault är snabbt och enkelt, men "bara flytta filer" förstör vault-strukturen. Länkar bär påtvingad semantik som filsystemet inte känner till. Utan sin egen wikilink-logikimplementation blir verktyget en landmina.

För det fjärde: testa på isolerade data. Innan du anförtror ett verktyg massrefaktorering — skapa en testmapp med 4–5 filer med korslänkar och se vad som händer. 5 minuters testning sparar timmar av återställning från backup.

För det femte: behåll en git-backup av ditt vault. Det viktigaste av allt. Ett enda git init inuti vaultet och periodiska commits — det är försäkring mot alla misstag av en AI-agent eller ett verktyg. Om något går sönder — git reset --hard tar tillbaka allt.

Slutsats

Resan tog flera timmar och tre misslyckade försök. Den slutgiltiga arkitekturen ser ut så här:

• VaultForge — huvudarbetsverktyget. Direkt filsystem + egen wikilink-motor + 27 verktyg = stabil refaktorering i alla skalor.
• Git — vault-versionshantering. Gratis rollback för alla misstag.

Nu kan jag göra det som allt detta startades för: be Claude organisera 400 anteckningar i en ordentlig PARA-arkitektur, slå samman dubbletter, lägga till frontmatter, bygga MOC-kartor. Varje operation är säker, länkarna bevaras, dry run visar vad som kommer att hända innan något ändras.

Om du också tittar på ditt stökiga Obsidian och vill ha en AI-assistent — börja direkt med VaultForge. Upprepa inte min väg genom döda projekt, beta-plugins och filsystemservrar utan länklogik.

Tänk om varje svart hål är en Big Bang för ett nytt universum? Den här artikeln utforskar idén att vårt universum kan vara en nod i ett oändligt rekursivt träd — där svarta hål föder sub-universum, energi cirkulerar tillbaka genom Hawkingstrålning, och fysikens grundläggande lagar medvetet är utformade för att göra kontakt mellan universum omöjlig.

Svart hål = universum

Idén kom under ett ögonblick av eftertanke: ett svart hål bildas när tillräckligt med massa och tryck koncentreras i en enda punkt. Den singulariteten — oändlig densitet, oändlig krökning — påminner misstänkt mycket om de förhållanden vi beskriver för Big Bang.

Tänk om det är samma händelse, betraktad från olika sidor? Utifrån ser vi ett svart hål som slukar materia. Inifrån — ett nytt universum som exploderar till existens. Massan och energin som kollapsade in i det svarta hålet blir råmaterialet för ett helt nytt kosmos med egna stjärnor, planeter och möjligen egna svarta hål.

Varje svart hål i vårt universum kan innehålla ett universum. Och vårt universum kan existera inuti ett svart hål i ett föräldra-universum.

Varför universum inte kan kontakta varandra

Här är den eleganta delen: när du väl passerat händelsehorisonten finns det ingen återvändo. Allmän relativitetsteori garanterar detta — föräldra-universumets framtid ligger helt utanför händelsehorisonten, oåtkomlig inifrån. Från sub-universumets perspektiv har föräldra-universumet redan tagit slut. Hela dess tidslinje har redan passerat.

Det här är inte en teknisk begränsning som vi kan övervinna med bättre teknik. Det är inbyggt i själva rumtidens geometri. Universum är fundamentalt isolerade från varandra — inte av avstånd, utan av tidens struktur.

Energicykeln: att låna och återlämna

Men energi går inte förlorad. Hawkingstrålning — den kvantprocess genom vilken svarta hål långsamt avdunstar — skapar ett anmärkningsvärt kretslopp:

1. Ett föräldra-universum skapar ett svart hål och överför energi till ett sub-universum
2. Sub-universumet lever igenom hela sin livscykel under biljoner år
3. Det svarta hålet avdunstar långsamt och återlämnar energi till föräldra-universumet via Hawkingstrålning
4. Föräldra-universumet får tillbaka sin energi — med ränta

Den "räntan" är fascinerande: fysiker tror nu att Hawkingstrålning bevarar information. Föräldra-universumet får inte bara tillbaka tom energi — det får ett avtryck av allt som hände inuti. Varje stjärna som bildades, varje planet, varje ögonblick av medvetande — kodat i strålning.

Rekursion hela vägen ner

Om du är programmerare är mönstret omöjligt att missa. Det här är rekursion. Varje universum anropar universe() med mindre energi och skapar sub-universum som skapar sub-sub-universum, tills det inte finns tillräckligt med energi för att bilda svarta hål — basfallet.

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

Fysikern Lee Smolin formaliserade en liknande idé som kosmologiskt naturligt urval: universum "reproducerar sig" genom svarta hål, och varje generation har lite annorlunda fysikaliska konstanter — optimerade genom otaliga cykler för att producera fler svarta hål, fler universum.

Var befinner vi oss i denna cykel?

Vårt universum är ungefär 13,8 miljarder år gammalt. Det låter urgammalt, men i förhållande till dess totala livslängd bevittnar vi den allra första början:

Vi existerar vid ungefär 0,00000000...01% av vårt universums totala livslängd. Stjärnornas era — allt vi kan se — är en kort blixt i den allra första början. Universumets verkliga berättelse är den långsamma, tålmodiga eran av svarta hål som skapar och avdunstar sub-universum.

Frågan om högre dimensioner

Allt som diskuterats hittills verkar inom vår tredimensionella förståelse. Men om vårt universum är ett "snitt" av något högre-dimensionellt, kan hela det rekursiva trädet av svarta hål och sub-universum bara vara en skugga av en struktur vi inte kan uppfatta.

År 1884 skrev Edwin Abbott Flatland — en berättelse om tvådimensionella varelser som inte kan föreställa sig en tredje dimension. En sfär som passerar genom Flatland framträder som en cirkel som växer och krymper. "Flatlänningarna" kan beskriva det matematiskt men aldrig verkligen förstå vad de ser. Vi kan befinna oss i exakt samma position i förhållande till vårt universum.

Vad är medvetande? Varför finns subjektiv upplevelse? David Chalmers kallade detta det "svåra problemet" — och det kan vara det starkaste beviset för att något verkar bortom vår dimensionella räckvidd.

Allt är låst på den fundamentala nivån

Den mest slående insikten är inte att vi inte vet — utan att vi inte kan veta. Varje undersökningsriktning stöter på en fundamental barriär:

• Vill du se föräldra-universumet? Blockerat av händelsehorisonten
• Vill du förstå medvetandet? Blockerat — ett system kan inte fullt ut analysera sig självt (Gödels ofullständighetssatser)
• Vill du veta vad som var "innan"? Blockerat — tiden började med Big Bang
• Vill du uppfatta högre dimensioner? Blockerat av de kognitiva begränsningarna hos en tredimensionell varelse

Filosofen Colin McGinn kallar detta kognitiv stängning: vissa frågor är stängda för det mänskliga sinnet, inte på grund av otillräckliga data, utan på grund av sinnets egen arkitektur. Skillnaden mellan "vi vet inte ännu" och "vi kan inte veta" är djupgående.

Det enda som återstår: självförbättring

Om varje utgång är blockerad avsiktligt — om du inte kan se utåt, inte kan se bakåt, inte kan se uppåt — finns det bara en riktning kvar: inåt. Universum verkar medvetet konstruerat för att tvinga fokus på jaget.

Den här slutsatsen kommer inte från religion eller filosofiläroböcker. Den kommer från att följa logiken i svarta hål, rekursion, informationsteori och kognitionens gränser. Existentialister, buddhister, stoiker och fysiker — alla anländer till samma punkt via olika vägar: existensens syfte kan helt enkelt vara förädlingen av den varelse som existerar.

Vi kom hit inte genom tro, utan genom fysik — från svarta hål, genom rekursiva universum, till kunskapens fundamentala blockeringar, till den enda öppna dörren: att bli bättre.

Referenser

• Lee Smolin — Kosmologiskt naturligt urval
• Stephen Hawking — Hawkingstrålning
• David Chalmers — Medvetandets svåra problem
• Edwin Abbott — Flatland: En roman i många dimensioner (1884)
• Kurt Gödel — Ofullständighetssatserna

För enkla webbplatser — portfolios, bloggar, landningssidor, småföretagssajter — håller traditionella CMS på att bli onödig overhead. AI-verktyg som Claude Code, Cursor och GitHub Copilot kan nu redigera din kodbas direkt, förstå kontext, översätta innehåll och driftsätta ändringar via git. Det abstraktionslager som CMS erbjöd ersätts av ett smartare gränssnitt: naturligt språk.

CMS-skatten du betalar

Varje CMS kommer med en dold kostnad. Inte bara prenumerationsavgiften — hela ekosystemet av komplexitet som lindas kring din i grunden enkla webbplats:

• Infrastruktur: En databas att drifta, ett API att underhålla, en instrumentpanel att säkra. Enbart WordPress utgör ~43% av webben och ~90% av CMS-riktade attacker.
• Prestanda: Dynamisk sidgenerering, API-anrop vid varje begäran, klientsidig hydrering av CMS-data. Din portfolio med 3 sidor har nu arkitekturen hos en SaaS-produkt.
• Leverantörsinlåsning: Ditt innehåll lever i någon annans databasschema. Migrera från Contentful till Sanity? Det är ett projekt, inte en konfigurationsändring.
• Kontextväxling: Redigera kod i din IDE, byt sedan till en webbläsarbaserad CMS-instrumentpanel för att ändra en rubrik. Två olika mentala modeller för vad som i grunden är samma operation.
• Kostnad: Headless CMS-priser skalas ofta med API-anrop eller innehållsposter. En personlig blogg behöver inte en innehållsinfrastruktur för $99/månad.

För en marknadsföringssajt där 50 personer redigerar innehåll dagligen är denna kostnad motiverad. För en utvecklarportfolio eller en småföretagslandningssida? Du bygger en bro över en vattenpöl.

Vad som förändrades: AI förstår din kod

Anledningen till att CMS existerade var enkel: icke-tekniska personer (och även utvecklare som inte ville röra kod för innehållsändringar) behövde ett visuellt gränssnitt för att uppdatera webbplatser. Koden var för komplex, för skör, för lätt att förstöra.

AI förändrade denna ekvation i grunden. Moderna AI-kodverktyg gör inte bara autokomplettering — de förstår projektstrukturen, läser befintliga mönster och gör kontextuellt korrekta redigeringar. Förändringen i arbetsflödet är 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 här är inte hypotetiskt. Den här bloggen körs på SolidStart med innehåll lagrat som TypeScript-filer. Varje artikel — inklusive denna — skapades genom att berätta för AI vad den ska skriva, granska resultatet och pusha till git. Ingen CMS-instrumentpanel. Ingen databas. Inget API-lager mellan innehållet och koden.

Verkliga exempel från den här sajten

Den här webbplatsen stödjer 10 språk, har en blogg, genererar OG-bilder dynamiskt och producerar RSS-flöden och sajtkarta. Så här ser innehållslagret 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
  },
};

Saker jag gör med AI som traditionellt skulle kräva ett CMS:

• Lägga till ett nytt blogginlägg: "Skriv en ny artikel om X, följ samma struktur som befintliga inlägg" — AI skapar filen, lägger till översättningar, registrerar den i indexet
• Uppdatera landningssidans text: "Ändra hero-rubriken till Y" — AI hittar rätt fil och uppdaterar den
• Översätta innehåll: "Lägg till tysk översättning för prissidan" — AI läser den engelska versionen och producerar en kulturellt anpassad översättning, inte en ordagrann kopia
• Rätta ett stavfel: "Det finns ett stavfel på about-sidan, 'recieve' ska vara 'receive'" — klart på 3 sekunder, committat till git med ett meningsfullt meddelande

Vad CMS faktiskt löste — och hur AI ersätter det

Låt oss vara ärliga om vad CMS bidrog med och hur varje förmåga mappas till AI-arbetsflödet:

Den centrala insikten: git är redan ett bättre versionshanteringssystem än något CMS någonsin har byggt. Och naturligt språk är ett bättre gränssnitt än någon WYSIWYG-redigerare — för det bär avsikt, inte bara formatering.

Paradigmskiftet: kod är innehållslagret

Vi bevittnar en inversion. I två decennier var trenden att separera innehåll från kod — lägga innehållet i en databas, exponera det via API, rendera det i frontend. Det var vettigt när kod var svår att redigera och innehåll behövde vara tillgängligt för icke-utvecklare.

AI gjorde inte CMS föråldrat genom att vara ett bättre CMS. Det gjorde CMS föråldrat genom att göra kod lika tillgänglig som en instrumentpanel.

Utvecklingen av webbinnehållshantering följer en tydlig bana:

1. 2000-talet: Monolitiska CMS (WordPress, Drupal) — innehåll och presentation kopplade i ett system
2. 2010-talet: Headless CMS (Contentful, Strapi) — innehåll separerat via API, renderat av frontend-ramverk
3. 2020-talet: Statiska sajt-generatorer + Markdown (Hugo, Astro) — innehåll som filer, byggs vid driftsättning
4. 2025+: Kod-som-innehåll + AI — innehållet lever i typad kod, AI är redigeringsgränssnittet

När du fortfarande behöver ett CMS

Det här är inte ett "CMS är dött"-uttalande. CMS löser verkliga problem i stor skala. Du behöver fortfarande ett när:

• Stora redaktionsteam: 10+ innehållsredaktörer som behöver rollbaserad åtkomst, godkännandeflöden och simultanredigering. Git merge-konflikter är inte en innehållsredaktörs problem att lösa.
• Högfrekvent innehåll: Nyhetssajter som publicerar 50+ artiklar per dag behöver optimerade redaktionspipelines, inte git-commits.
• Komplexa innehållsrelationer: E-handelskataloger med tusentals SKU:er, produktvarianter och dynamisk prissättning kräver strukturerade databaser.
• Regulatorisk efterlevnad: Branscher som kräver revisionsspår, innehållsgodkännandekedjor och lagstadgade granskningsprocesser behöver specialbyggda system.

Gränsen är tydlig: om dina innehållsändringar kräver samordning mellan flera icke-tekniska intressenter med hög frekvens, förtjänar CMS sin komplexitet. Om du är en soloutvecklare, ett litet team, eller hanterar en sajt som ändras veckovis snarare än varje timme — är AI + kod enklare, snabbare, billigare och mer tillförlitligt.

Framtiden: AI som det universella gränssnittet

Trenden sträcker sig bortom CMS. Varje mjukvaruabstraktionslager som existerade för att "det underliggande systemet är för komplext för direkt interaktion" komprimeras av AI. Adminpaneler, konfigurationsgränssnitt, visuella databasredigerare — alla dessa är gränssnitt som översätter mänsklig avsikt till systemändringar. AI gör denna översättning inbyggt.

För enkla webbplatser är framtiden redan här. Ditt innehåll är kod. Din redigerare är AI. Din versionshantering är git. Din driftsättning är en push. Hela CMS-lagret — instrumentpanelen, databasen, API:et, hostingen — var mellanprogram mellan din avsikt och din webbplats. AI tog bort behovet av den mellanprogramvaran.

Det bästa CMS:et är inget CMS. Inte för att innehållshantering inte spelar roll — utan för att AI gjorde koden själv till det mest intuitiva gränssnittet för innehållshantering vi någonsin haft.

Perplexity Desktop stöder MCP (Model Context Protocol)-anslutningar. Genom att lägga till den officiella @modelcontextprotocol/server-filesystem-servern som pekar på ditt Obsidian-vault kan du be Perplexity på naturligt språk att läsa, skapa och redigera anteckningar — direkt från chatten. Inga plugins, inga tillägg, ingen kopiering.

Problemet

Perplexity är utmärkt på forskning — det söker på webben, sammanfattar källor och ger svar med citat. Men när du vill spara dessa fynd i ditt Obsidian-vault bryts arbetsflödet: kopiera text, byta till Obsidian, hitta rätt anteckning, klistra in, formatera. Varje. Gång.

Webbläsartillägg som "Perplexity to Obsidian" hjälper med export, men de är enkelriktade — AI:n kan inte se ditt vault, kan inte läsa dina befintliga anteckningar och kan inte bestämma var saker ska placeras baserat på din mappstruktur.

Vad är MCP?

Model Context Protocol (MCP) är en öppen standard som låter AI-modeller interagera med lokala verktyg och datakällor. Tänk på det som en USB-port för AI — du ansluter en "server" (ett litet program) och AI:n får nya förmågor. I vårt fall ger filesystem-servern Perplexity 14 verktyg för att arbeta 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()

Nyckelpunkten: AI-modellen har inte direkt åtkomst till dina filer. Den anropar verktyg som tillhandahålls av MCP-servern, som körs lokalt på din maskin. Dina data lämnar aldrig din dator om du inte uttryckligen ber AI:n att göra något med dem.

Krav

• Perplexity Pro-prenumeration (MCP-anslutningar är tillgängliga för betalande användare)
• Perplexity Mac App från App Store (inte webbläsarversionen)
• Node.js installerat på din Mac (för att npx ska fungera)

Steg-för-steg-installation

Hela installationen tar cirka 2 minuter:

Kommandot

Kommandot att klistra in i Command-fältet:

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

Ersätt sökvägen med den faktiska platsen för ditt Obsidian-vault. Om ditt vault synkroniseras via iCloud kommer sökvägen att vara under ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. Se till att behålla citattecknen — sökvägen innehåller troligen mellanslag.

Hur man använder det

När anslutningen visar Running med 14 tillgängliga verktyg, gå till valfri Perplexity-chatt och börja prata med ditt 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:n förstår din vault-struktur, respekterar dina formateringskonventioner och kan arbeta med befintligt innehåll. Du kan be den att undersöka ett ämne på webben och spara sammanfattningen direkt i en specifik anteckning.

Varför MCP är bättre än andra metoder

Före MCP fanns det begränsade sätt att koppla ihop Perplexity och Obsidian:

Nuvarande begränsningar

• Endast Mac — Perplexitys MCP-anslutningar fungerar för närvarande bara i Mac App Store-versionen
• Ingen Obsidian API-integration — filesystem-servern arbetar med råfiler, inte genom Obsidians API. Det innebär att den inte utlöser Obsidian-plugins (Linter, Templater) vid filskapande
• Godkännande krävs — känsliga filoperationer kan kräva din bekräftelse i Perplexity-appen — det är en säkerhetsfunktion, inte en bugg

Slutsatser

Denna installation förvandlar Perplexity från ett forskningsverktyg till ett forsknings-och-fångstverktyg:

1. Sök på webben och spara i Obsidian i en konversation
2. AI:n ser din vault-struktur och anpassar sig till ditt organisationssystem
3. Noll appbyten — allt sker i Perplexity-chatten

Källor

• 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

Ett 6-radigt bash-skript som kör Claude Code CLI i headless-läge varje morgon kl 9:00. Det söker nyheter inom 11 konfigurerbara ämnen, filtrerar brus och skriver en formaterad markdown-digest direkt till en Obsidian vault synkad via iCloud. Noll beroenden. ~100 rader konfiguration totalt.

Problemet

Som utvecklare är det en daglig skatt att hålla sig uppdaterad. RSS-flöden är brusiga, Twitter är en tidstjuv, nyhetsbrev kommer när man är djupt fokuserad. Jag behövde något som gör research åt mig.

Den typiska lösningen är att bygga en scraping-pipeline: schemaläggare, crawler, NLP-pipeline, databas, notifieringstjänst. Det är veckors arbete. Jag ville ha något som kan byggas på en eftermiddag.

Arkitektur

Hela systemet är 4 filer och noll beroenden:

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 (hela)

Projektet är avsiktligt minimalt.

Startpunkt: digest.sh

Hela applikationen är ett 6-radigt 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

Viktiga flaggor: -p kör Claude i headless-läge, --max-turns 20 ger agenten tillräckligt med svängar, --allowedTools begränsar agenten till läsning, sökning och skrivning.

Hjärnan: prompt.md

Här lever intelligensen. Prompten förvandlar Claude till en nyhetsresearch-agent:

# 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

Ämnen är helt konfigurerbara — lägg till ett nytt ämne och det finns i morgondagens 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"

Schemaläggning med launchd

På macOS är launchd det nativa sättet att schemalägga återkommande uppgifter:

<?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>

Installera med launchctl load ~/Library/LaunchAgents/com.news-digest.plist. Skriptet körs dagligen kl 9:00.

Hur resultatet ser ut

Varje morgon dyker en ny markdown-fil upp 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 siffror

Viktiga designbeslut

• Claude Code CLI istället för API — inget behov av att hantera API-nycklar eller HTTP-klienter
• Obsidian istället för e-post — digests är sökbara, länkbara och permanenta
• launchd istället för cron — macOS-nativ schemaläggare med hantering av missade körningar
• YAML för ämnen — nytt ämne = 2-raders ändring
• Hoppa över tomma ämnen — inga nyheter = ingen sektion

Bygg din egen

Klart på 10 minuter:

1. Installera Claude Code CLI och autentisera
2. Klona repot: git clone https://github.com/oleksiimazurenko/news-digest
3. Redigera topics.yaml och prompt.md
4. Redigera plist-filen och launchctl load
5. Vänta till 9:00 — eller testa manuellt med bash digest.sh

Slutsatser

Det mest intressanta med detta projekt är vad som inte finns i det. Ingen databas, ingen API-server, ingen Docker, inga npm-paket, ingen Python, ingen HTML-parser, ingen NLP-pipeline.

Så ser det ut att bygga med AI-agenter: du definierar vad och var, agenten hanterar hur. Total utvecklingstid: cirka 2 timmar.

Källor

• 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 renderar en <script>-tagg inuti en React Client Component för att förhindra temablixt (FOUC). React 19 varnar för detta. Biblioteket har inte uppdaterats sedan mars 2025. Lösning: Zustand-store + useServerInsertedHTML. Noll beroenden, noll FOUC, noll varningar.

Problemet

Om du använder next-themes med Next.js 15+ och React 19 får du det här konsolfelet vid varje sidladdning:

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 hydreringsmismatch. React 19 varnar om att <script>-taggar i klientkomponenter aldrig kommer att köras. Skriptet fungerar i SSR men React flaggar det.

Varför det händer

next-themes sätter temaklass innan hydrering genom att injicera ett 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 ändrade beteendet — script-taggar i komponenter flaggas nu. suppressHydrationWarning hjälper inte för detta.

Vad vi försökte (och varför det misslyckades)

Vi prövade systematiskt varje metod:

Lösningen: Zustand + useServerInsertedHTML

useServerInsertedHTML injicerar HTML i SSR-strömmen utanför React-trädet. Skriptet finns i HTML men React "ser" det inte på klienten. Kombinerat med Zustand för reaktivt tematillstånd — fullständig ersättning, noll beroenden.

Hur det fungerar

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 hanterar tematillstånd, DOM-klasser, systemdetektering och synkronisering mellan flikar. _init() returnerar en cleanup-funktion för 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

Providern injicerar FOUC-förebyggande skript via useServerInsertedHTML och initialiserar Zustand-storen vid 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: Använd 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 från next-themes

API:et är avsiktligt identiskt. Migrering är en enda 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()

Jämförelse

Varför inte andra alternativ?

@wrksz/themes

Drop-in-ersättning med useServerInsertedHTML. Fungerar, men ytterligare ett beroende med en enda underhållare. Om next-themes lärde oss något — beroenden överges. Med ~100 rader kod äger du hela lösningen.

next-themes@1.0.0-beta.0

Finns på npm, inget releasedatum, ingen ändringslogg, oklart om React 19-varningen är åtgärdad. Inte värt att satsa produktionskod på.

Bara CSS (prefers-color-scheme)

Fungerar för systemdetektering, men kan inte hantera localStorage-persistens, manuell växling eller alternativet "system". JavaScript behövs.

Slutsatser

1. next-themes är i praktiken övergiven — senaste utgåvan mars 2025, React 19-varningen ej åtgärdad
2. useServerInsertedHTML är rätt Next.js-primitiv för skriptinjektion utan React-varningar
3. Zustand ger reaktivt tematillstånd med mindre kod än en Context-provider
4. Hela lösningen ~100 rader, noll nya beroenden, du äger varje rad

Källor

• 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

Vår app (Promova) använder Next.js 16 med en Landing Builder — ett CMS-drivet system som sätter ihop marknadsföringssidor från ~90 olika sektionskomponenter. Arkitekturen använder en sectionRegistry.tsx som mappar sektionsnamn till next/dynamic()-anrop:

// 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 enda landningssida renderar bara 5-8 sektioner. Men Lighthouse visade:

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

Varför? Turbopack ser alla 90 import()-sökvägar som nåbara och genererar <link rel="stylesheet"> för varje SCSS-modul. Även sektioner som aldrig renderas på sidan får sin CSS injicerad i <head>. Detta är ett bekräftat, förväntat beteende i Next.js App Router. Ingen fix planeras.

Allt jag försökte (och varför det misslyckades)

Jag spenderade dagar på att gå igenom varje tillvägagångssätt jag kunde hitta. Här är hela listan:

inlineCss-fällan

Next.js har en experimental.inlineCss-flagga som ersätter alla <link rel="stylesheet"> med inline <style>-taggar. Låter perfekt, eller hur?

Problemet: det är allt eller inget. Du kan inte aktivera det per rutt. Om du har SSR-sidor (force-dynamic) bygger varje begäran om all CSS inline. Vi försökte — vår headless CMS klarade inte lasten.

Upptäckten: Turbopack Import Attributes

Genom att gräva i Next.js 16.2-releasenotes hittade jag en dåligt dokumenterad funktion: Turbopack Import Attributes. Den låter dig åsidosätta den inbyggda bundler-pipelinen för en specifik import med TC39 with {}-syntax:

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

Detta säger till Turbopack: "Bearbeta inte denna import som en stilmall. Kör den genom min anpassade loader och behandla utdatan som JavaScript."

Detta är den avgörande insikten. Istället för att Turbopack genererar ett <link rel="stylesheet"> som blockerar rendering, kompilerar vår loader SCSS och exporterar det som en JS-sträng. Resultat: bara CSS för sektioner som faktiskt renderas hamnar i sidans HTML.

Lösningen

1. Anpassad Turbopack Loader

Ett ~70-radigt Node.js-skript som yarn workspace-paket (@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')
}

Vad den gör: styles — samma scopade klassnamnskarta som standard CSS Modules. cssText — kompilerad CSS som sträng.

2. InlineStyle-komponent

Använder React 19s inbyggda <style href precedence>-API för automatisk deduplicering:

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

React 19 garanterar: samma href → bara en <style> i DOM.

3. Migration per komponent (~6 rader 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-filerna förblir exakt desamma. Ingen CSS-omskrivning.

Varför detta är bättre än inlineCss: true

Här är den kritiska skillnaden:

Med inlineCss: true får en sida fortfarande ALLA 94 stilmallar inline. Med vår metod hamnar bara CSS som faktiskt renderas i HTML:en.

Turbopack-fällan: inga globala regler för .module.scss

En fälla jag föll i: du kanske tror att du kan lägga till en Turbopack-regel i next.config.ts för att tillämpa loadern globalt:

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

Gör inte detta. Turbopacks inbyggda CSS-module-pipeline fångar .module.scss-filer innan anpassade regler tillämpas, vilket orsakar:

FATAL PANIC: inner asset should be CSS processable

with {}-attribut fungerar eftersom de instruerar Turbopack vid import-platsen att helt kringgå CSS-module-pipelinen.

Resultat

127 sektionskomponenter migrerade i Landing Builder. Produktionsbygge verifierat.

Begränsningar

• with {} per import är mångsidigt — varje import behöver 3 extra rader.
• Bara Turbopack — with {}-attribut stöds inte av Webpack.
• Klassnamns-hashning — vår loader använder en annan hashningsalgoritm än Turbopacks inbyggda.
• HTML-storlek ökar — CSS är inline i HTML istället för cachade separata filer.

När man ska använda detta

Denna teknik är mest effektiv när:

1. Du har ett registry/barrel-mönster — en fil importerar många komponenter, men bara några få renderas per sida
2. Du använder Turbopack — Import Attributes är Turbopack-specifika
3. Du vill ha kontroll per komponent — inte en allt-eller-inget-flagga
4. Din SCSS är komplex — variabler, mixins, breakpoints, nästling — allt stöds
5. Du inte kan använda experimental.inlineCss — för att du har SSR-sidor eller vill ha granulär kontroll

Relaterade GitHub Issues

Om du påverkas av renderingsblockerande CSS i Next.js App Router — du är inte ensam:

Kärnproblemet

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

• 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

Communityn söker lösningar

• 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-buggar

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

Byggt på Promova — en språkinlärningsplattform som betjänar miljontals användare.

Next.js patchar den globala fetch och lägger till ett cache-lager som håller referenser till svarsdata efter att de borde ha frigjorts. Varje fetch-anrop lägger till minne som aldrig returneras till GC. I Docker/Kubernetes leder detta till OOM-krascher var några timmar. Buggen har funnits sedan Next.js 14 (april 2024) och är fortfarande olöst i 16.2.x (mars 2026). På Vercel visar sig problemet inte tack vare efemära serverless-funktioner.

Hur normal fetch fungerar

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

Hur fetch fungerar i Next.js

Next.js fångar upp den globala fetch och omsluter den med sitt eget cache-/tracking-lager:

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

Vad som händer 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

Drabbade versioner

Next.js — Alla versioner med App Router

Node.js

Testat på Node.js 20, 22, 24, 25 — läcker på alla.

Vad som inte fungerar

Vad som fungerar (workarounds)

Begränsning med axios-workaround

Dina egna API-anrop kan ersättas med axios. Men Next.js använder internt den patchade fetch för:

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

Även utan en enda fetch i din kod — använder Next.js det fortfarande internt.

Varför Vercel inte fixar det

Affärslogik

Vercel är ett företag som tjänar pengar på att hosta Next.js. På deras plattform visar sig problemet inte (serverless = efemärt). Buggen påverkar bara self-hosted (Docker, K8s, VPS) — de som inte betalar Vercel.

Officiell position

Tim Neutkens (Vercel-maintainer) analyserade problemet och förklarade att det är ett undici-problem (Node.js fetch-bibliotek), inte Next.js. Issue #90433 stängdes. Trots att:

• axios och node-fetch på samma Node.js fungerar utan läckor
• Läckan bara uppstår när fetch går genom Next.js-wrappern
• Buggen har varit öppen i 2 år utan fix

Prioriteringar

Under dessa 2 år har Next.js-teamet släppt:

• Turbopack (2-5x snabbare builds) — marknadsföringsfördel
• Cache Components / use cache — minskar belastningen på Vercel-servrar
• proxy.ts istället för middleware — förenklar edge-deployment på Vercel
• DevTools MCP — AI-hype

Memory leak i self-hosted? Inte en prioritet.

Lösning: AWS Lambda (SST + OpenNext)

Vad är det

OpenNext är en open-source-adapter som konverterar en Next.js-build till ett format för AWS Lambda. SST är ett ramverk som automatiserar infrastrukturen.

Arkitektur

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

Varför detta löser minnesläckan

Lambda-funktioner bearbetar förfrågningar och återvinns efter 5-15 minuters inaktivitet. Minnet hinner inte ackumuleras.

Deployment

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

Jämförelse

Lambda-nyanser

• Cold starts — första förfrågan är långsammare (~200-500ms)
• Säkerhet — aktivera OAC (Origin Access Control), annars är Lambda-URL:en publik
• OpenNext — community-projekt, inte officiellt från Vercel. Nya Next.js-funktioner kan gå sönder
• Plånboksattack — vid DDoS kan Lambda auto-scaling leda till en stor faktura

Varför en riktig fix är orealistisk

1. Arkitekturproblem

Läckan är inte en slumpmässig bugg utan en konsekvens av ett designbeslut: Next.js fångar upp den globala fetch och lägger till cache/tracking ovanpå. För att fixa det behöver sättet App Router interagerar med fetch designas om. Detta påverkar ISR, revalidation, data cache, request deduplication — ramverkets kärna.

2. Intressekonflikt

Vercel är inte motiverat att fixa det som inte påverkar deras plattform. Self-hosted konkurrerar med deras affär. Ju fler problem i self-hosted — desto fler migrerar till Vercel.

3. Skuldförskjutning

Den officiella positionen är "det är undici, inte vi". Tills det ändras — kommer de inte arbeta på en fix.

4. Ingen community-fix

Next.js AGPL-3.0-licens tillåter forks, men kodbasen är enorm och tätt kopplad till Vercel-infrastrukturen. En community-PR för att fixa fetch-wrappern skulle kräva djup förståelse av den interna arkitekturen och godkännande från maintainers — som redan stängt issuen.

Slutsatser

1. Om du är på Vercel — inget problem, inget att göra
2. Om self-hosted och behöver serverless — SST + OpenNext på AWS Lambda
3. Om self-hosted Docker — ersätt fetch med axios där det är möjligt, övervaka RAM, konfigurera automatisk pod-omstart
4. Om du startar ett nytt projekt — överväg SvelteKit eller Nuxt som alternativ utan detta problem

Källor

• 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