Aber nach einem Monat realem Einsatz bin ich auf ein paar substanzielle Probleme gestoßen, die jener Beitrag nicht abgedeckt hat. Das größte davon — eine versteckte Eigenheit von Claude Code, in die ich zufällig hineingelaufen bin, als ich den Gmail-MCP hinzugefügt habe und er fünf Minuten später aus meinem Profil "verschwunden" war. Heute habe ich alles auf eine neue Architektur umgebaut — XDG-konform, mit einem Symlink und einem interaktiven Profil-Picker über gum. Das ist v2 — eine Evolution aus realer Erfahrung, keine theoretische Verbesserung.

Was angefangen hat zu nerven

Vier Sachen. Die ersten drei drehen sich um Sauberkeit, Sichtbarkeit und Skalierung. Die vierte ist der echte Architektur-Gotcha, den ich nicht sofort gesehen habe. Ich gehe sie der Reihe nach durch, denn genau die vierte hat am Ende den Umbau erzwungen.

1. Zwei separate Ordner in $HOME — das ist Unordnung

~/.claude und ~/.claude-promova — zwei Dotfolder direkt nebeneinander im Root von $HOME. Die XDG Base Directory Specification sagt, dass Configs in ~/.config/ gehören. Dotfile-Ordner, die direkt in Home herumliegen, sind ein Antipattern, das $HOME mit der Zeit zur Rumpelkammer macht. Kosmetisch, klar, aber es hat mich jedes Mal genervt, wenn ich ls -la ~ gemacht habe.

2. Keine visuelle Bestätigung des aktiven Profils

Ich starte claude und weiß nicht, welches Profil aktiv ist — bis ich innerhalb der Session claude config list ausführe. Wenn ich vergessen habe, welches Terminal ich wo gestartet habe, muss ich nachschauen. Eine Kleinigkeit, aber bei parallelem Arbeiten mit personal + work in zwei Tabs summiert sich das.

3. Aliase skalieren nicht

Zwei Profile — claude und claude-promova — okay. Ein drittes dazu (ein Freelance-Kunde) — brauchst du einen dritten Alias. Ein viertes — einen vierten. Nach einem halben Jahr wüsste ich nicht mehr, welche Aliase ich überhaupt angelegt hatte.

4. Die versteckte Falle in ~/.claude.json

Und das ist der eigentliche Grund für den Umbau. Claude Code hat zwei verschiedene Orte für Konfiguration, und die Doku schreit das nicht heraus: ~/.claude/ — das Verzeichnis mit projects/, sessions/, hooks/, skills/. Und separat — ~/.claude.json, eine Datei direkt im $HOME-Root, in der oauthAccount, mcpServers, die projects-History, skillUsage und etwa 40 weitere Felder echten Live-State liegen.

Der Befehl claude mcp add --scope user schreibt genau in dieses ~/.claude.json im Home-Root, nicht in ~/.claude/.claude.json oder ins Profilverzeichnis. Das wusste ich nicht. Bis ich eines Tages reingelaufen bin.

Discovery: warum der Gmail-MCP "verschwunden" ist

Heute Morgen habe ich den Gmail-MCP in Claude Code eingerichtet. Standard-Setup: Google-Cloud-Projekt, OAuth-Credentials, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Alles okay. Session neu gestartet — läuft, ich lese Mails, antworte auf Nachrichten. Eine Stunde später haben wir angefangen, die Aliase in eine Funktion mit gum-Profil-Picker zu refaktorieren, und danach alles auf XDG umgezogen. Ich habe mv ~/.claude → ~/.config/claude-profiles/personal gemacht, CC neu gestartet, im Menü personal gewählt. Und in der neuen Session /mcp geöffnet:

figma            (failed)
playwright-test
claude.ai Notion

Kein gmail. Kein vaultforge. Nur drei Server, von denen einer sogar failed war. Dabei hatte ich Gmail gerade hinzugefügt. Die Session in einem anderen Terminal (Work-Profil) zeigte Gmail und Vaultforge gleichzeitig ohne Probleme.

Ich habe angefangen zu graben und entdeckt, dass ich auf meinem Rechner drei verschiedene Dateien namens .claude.json habe:

Da war es. Genau das ist der Architektur-Gotcha:

1. claude mcp add --scope user schreibt immer in ~/.claude.json im Home-Root, unabhängig von CLAUDE_CONFIG_DIR
2. Claude Code liest bei gesetztem CLAUDE_CONFIG_DIR die Datei $CLAUDE_CONFIG_DIR/.claude.json — also die Datei innerhalb des Profils
3. Die Einträge "user-scope MCPs" und "Profil-MCPs" liegen in verschiedenen Dateien mit gleichem Namen — und lassen sich leicht verwechseln

In meinem Fall war ~/.claude.json (Home-Root, 113 KB) der lebendige, aktuelle State — mit gmail, vaultforge, OAuth-Session, alles. Und ~/.config/claude-profiles/personal/.claude.json (29 KB) erwies sich als alter Snapshot, der irgendwie schon vorher im alten ~/.claude/ lag — vielleicht hat eine ältere CC-Version dort geschrieben, vielleicht ein Plugin. jq -r 'keys[]' auf beiden Dateien zeigte, dass die Home-Root-Version 41 unique Keys hatte, die im Snapshot fehlten.

Und diese 41 Keys sind kein Müll. Das ist der echte State von Claude Code:

• skillUsage — Nutzungsstatistik der Skills
• githubRepoPaths — Repo-Cache für Project-Navigation
• cachedGrowthBookFeatures + cachedStatsigGates — Feature Flags (ohne sie holt CC bei jedem Start frische)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — UI-Flags (ohne sie erscheinen die Modals beim nächsten Start wieder)
• lastPlanModeUse, feedbackSurveyState, installMethod — Onboarding- und UX-State

Wenn du einfach mv ~/.claude ~/.config/claude-profiles/personal ohne Merge machst — verlierst du das alles. Welcome-Modals kommen zurück, githubRepoPaths-Suche läuft erneut, alle Survey-Aufforderungen kommen wieder. So wie ich es fast gemacht hätte.

Die neue Architektur

Alles lebt unter einem Eltern-Verzeichnis in ~/.config/, wie XDG es will. Jedes Profil ist self-contained — hat seinen vollen State inklusive eigener .claude.json. ~/.claude bleibt als Symlink auf das Personal-Profil für Abwärtskompatibilität.

~/.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/

Keine .claude.json im $HOME-Root. Jedes Profil ist ein separates isoliertes Verzeichnis, in dem alles liegt: die Ordner projects/sessions und dieselbe Datei mit MCP-Servern und OAuth-Tokens. Eine Source of Truth pro Profil.

Warum der Symlink auf personal zeigt

Alles, was den Pfad ~/.claude/ hardcodet — alte Skripte, Plugins, Claude-Code-IDE-Extensions, Statusline-Configs wie claude-powerline.json — funktioniert weiter ohne Änderungen. Der Symlink wird ins Personal-Profil aufgelöst. Wenn du versehentlich command claude (ohne Wrapper-Funktion) startest — landest du ebenfalls über den Default-Path-Lookup im Personal. Personal wird zum "quiet default", wie es vorher war, lebt aber jetzt physisch an der XDG-Location.

Interaktiver Picker beim Start — Funktion + gum

Statt Aliase — eine claude()-Funktion in ~/.zshrc, die ein Pfeil-Menü über gum (TUI-Helper von Charm) zeigt. Die Funktion fängt den claude-Aufruf auf Shell-Ebene ab, lässt dich ein Profil wählen und startet command claude mit dem passenden CLAUDE_CONFIG_DIR. command ist wichtig — es umgeht die Wrapper-Funktion und ruft das echte Binary auf.

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

So sieht es beim Start aus:

Claude profile:
▸ personal
  promova

↑↓ zum Navigieren, Enter zum Auswählen, Esc zum Abbrechen (Claude startet dann einfach nicht). Das Profil ist immer sichtbar — vergessen unmöglich.

Migrationsskript

Für alle, die das lesen und vom alten Schema umziehen wollen. Der kritischste Schritt ist der zweite: er merged ~/.claude.json aus dem Home-Root mit dem, was bereits im Personal-Profil liegt, und vereint die mcpServers-Listen. Ohne diesen Schritt verliert das Profil sowohl die MCPs als auch den gesamten 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

Der dritte Schritt zu den Rechten ist für sich genommen wichtig. jq | mv erzeugt eine Datei mit umask 644 (world-readable). Darin stecken OAuth-Tokens. chmod 600 sofort nach dem Merge ist Pflicht.

Nach der Migration — alle aktiven Claude-Sessions schließen und neu öffnen, Shell neu laden (source ~/.zshrc oder neues Terminal), claude starten, Profil wählen, über claude mcp list prüfen, dass alle MCPs da sind. Wenn alles passt — ~/.claude.json.migrated.bak löschen. Wenn etwas nicht stimmt — Rollback ist trivial: mv ~/.claude.json.migrated.bak ~/.claude.json und den Symlink entfernen.

Was du bekommst

• Ein Eltern-Verzeichnis statt zweier Dotfolder in $HOME — XDG-konform
• Der Symlink erhält die Kompatibilität mit allem, was ~/.claude/ hardcodet
• Jedes Profil ist self-contained — sein voller State und seine MCPs liegen in seiner eigenen .claude.json
• Eine Source of Truth pro Profil — keine Orphan-Config im Home-Root mehr, die still vom Profil-Pendant abdriftet
• Sensitive Daten (oauthAccount, Tokens) haben garantiert Rechte 600
• Visuelle Bestätigung des aktiven Profils bei jedem Start — du kannst nicht vergessen, welches Profil aktiv ist
• Ein drittes Profil hinzufügen = eine Zeile im case der Funktion hinzufügen, kein neuer Alias zum Klonen und kein Name zum Merken

Wo es Schwächen hat

Ich will ehrlich sein. Das ist keine kostenlose Verbesserung — ein paar Kompromisse kamen mit dazu, und die solltest du vorher kennen.

• gum ist eine zusätzliche Abhängigkeit (brew install gum, ~13 MB). Wenn du es prinzipiell nicht installieren willst — Fallback auf select in zsh oder ein simples read. Funktioniert, sieht aber nicht so gut aus und hat keine Pfeil-Navigation.
• Ein Enter-Druck bei jedem Start. Für Leute, die claude dutzende Male am Tag starten — kann nerven. Alternative unten (direnv).
• Der Symlink ~/.claude → personal macht personal zum Default. Wenn du das Work-Profil als Default brauchst, musst du den Symlink umbiegen (ln -sf). Nicht schwer, aber es ist nicht "vergessen und nichts bricht".
• Der Symlink kann theoretisch brechen, wenn irgendein Tool ~/.claude.json atomar über ein Temp+Rename-Pattern (write-file-atomic) überschreibt. In der Praxis macht Claude Code das selbst nicht, aber wenn du Drittanbieter-Plugins installierst — prüf das.
• Wenn du auf den Profilen unterschiedliche Anthropic-Accounts mit unterschiedlichen Plans hast — kann es nach einem Wechsel einen Sub-Sekunden-Lag geben, während Claude Code den OAuth-State synct. In meiner Nutzung nicht spürbar, aber nicht null.

Alternativen, die ich erwogen habe

direnv — setzt CLAUDE_CONFIG_DIR automatisch abhängig von einer .envrc im Root jedes Projekts. Null Interaktion, null Klicks. Minus: du musst in jedem Work-Root eine .envrc ablegen, und wenn du claude in einem nicht erkannten Ordner startest — bekommst du das Default-Profil (eventuell nicht das, das du willst). Für Leute, die in einer überschaubaren Anzahl von Work-Roots leben und nie klicken wollen — ist direnv tatsächlich besser.

Symlink-basiertes Switching (ein aktives Profil über das Umbiegen des ~/.claude-Symlinks) habe ich ebenfalls erwogen und sofort verworfen. Du kannst nicht zwei Terminals mit unterschiedlichen Profilen gleichzeitig haben — das globale "aktuelle" ist nur eines. Für mich ein Deal-Breaker.

Fazit

v2 ist nicht einfach besseres UX über v1. Es ist das Eingeständnis, dass Claude Code eine versteckte Architektur-Eigenheit hat (~/.claude.json als separate Datei im Home-Root, die von --scope user-Befehlen unabhängig von CLAUDE_CONFIG_DIR geschrieben wird), die man berücksichtigen muss, wenn man echte Isolation zwischen Profilen will. Der erste Ansatz (~/.claude + ~/.claude-promova + Alias) hat zu 80% funktioniert, aber die übrigen 20% äußerten sich in stillem State-Drift zwischen den Profilen. Jetzt ist das berücksichtigt. Wenn du gerade erst anfängst — starte direkt mit v2. Wenn du schon auf v1 sitzt — das Migrationsskript ist oben, der Umzug dauert fünf Minuten und bricht nichts (gerade der jq-Merge ist der Schritt, der dich vor State-Verlust rettet).

Zwei Regeln haben meine halluzinationsreichen Workflows in zuverlässige Pipelines verwandelt: ein Agent, eine Spezialisierung, und was als Shell-Befehl laufen kann, muss als Shell-Befehl laufen. Das ist keine Theorie. Das ist, was ich jeden Tag mit Claude Code mache — und das sind die Muster, die wirklich etwas bewegen.

Warum Generalist-Agenten lügen

LLMs sind Next-Token-Predictors. Wenn ein Prompt zwei Rollen verlangt — bau X und verifiziere X — schließt das Modell die erste Rolle ab und sagt dann voraus, wie die Ausgabe der zweiten Rolle aussehen würde, ohne sie tatsächlich auszuführen. Selbstverifikation ist strukturell schwach: gleicher Kontext, gleiches Modell, gleiche blinden Flecken. Das Bestanden bei der Verifikation korreliert mit dem Bestanden beim Bauen — sie scheitern gemeinsam.

Das Modell weiß nicht, dass es lügt. Aus seiner Perspektive ist ich habe alles sorgfältig geprüft eine kohärente Fortsetzung von ich habe den Code geschrieben. Dasselbe gilt für bist du sicher?-Prompts — die fangen keine Halluzinationen: Das Modell ist beim zweiten Durchgang genauso überzeugt. Konfidenz korreliert nicht mit Korrektheit — sie korreliert damit, wie plausibel der nächste Satz klingt.

Die Lösung sind nicht bessere Prompts. Sei vorsichtig, überprüfe es nochmal, halluziniere nicht — diese Anweisungen bewirken nichts. Die Lösung ist strukturell: Spezialisiere den Agenten so, dass er physisch nicht so tun kann, als hätte er etwas getan, und leite quantitative Arbeit durch die Shell, damit die Antwort aus dem echten Zustand kommt und nicht aus Token-Wahrscheinlichkeiten.

Regel 1: ein Agent, eine Spezialisierung

Teile die Arbeit auf separate Agenten mit separaten Kontexten auf. Jeder Agent hat eine einzige Verantwortung und ein eng gefasstes Toolset. Der gesamte Workflow wird zum Staffellauf statt zu einem Agenten, der Runden dreht:

• Builder-Agent: nimmt die Spec, schreibt den Code. Das ist sein einziger Job. Er hat Read, Edit, Write, Bash.
• Reviewer-Agent: nimmt die Spec plus den Diff, prüft die Akzeptanzkriterien. Frischer Kontext. Kein Wissen darüber, wie der Code geschrieben wurde — nur was dabei herausgekommen ist. Er hat Bash, Read, Grep, Glob — keinerlei Schreib-Tools.
• Analytics-Agent: beantwortet Datenfragen, indem er Queries konstruiert und ausführt. Nur Bash. Kann die Antwort nicht erreichen, ohne einen echten Befehl auszuführen.
• Orchestrator: die Hauptsession, die jeden Agenten der Reihe nach aufruft und niemals einen Agenten bittet, den Job eines anderen zu erledigen.

Konkretes Beispiel: UI-Implementierung plus visueller Abgleich mit einem Figma-Mockup. Der Builder schreibt die Komponenten und committet den Diff. Dann ruft der Orchestrator den Reviewer mit der Design-URL, dem Diff und expliziten Akzeptanzkriterien auf. Der Reviewer fährt Playwright hoch, macht Screenshots, vergleicht sie mit dem Referenzbild und liefert PASS oder FAIL mit den tatsächlichen Screenshot-Pfaden und Pixel-Diffs zurück. Der Builder kommt dem Verifikationsschritt gar nicht erst nahe — genau deshalb ist die Verifikation echt.

Das Anti-Pattern ist der Mega-Agent: ein einziger Prompt, der sagt bau diese UI und stell sicher, dass sie mit dem Mockup übereinstimmt. Ich garantiere dir: er wird melden, dass alles stimmt. Stimmt es nicht. Die Erzählung ich habe verifiziert ist schlicht die wahrscheinlichste Token-Sequenz nach ich habe es gebaut.

Regel 2: Shell statt Prompt, immer

Alles Quantitative, alles was echten Zustand berührt, alles wo die Antwort falsch sein kann und trotzdem richtig aussieht — schick es durch sh. Die Aufgabe des Agenten ist es, den Befehl zu konstruieren und auszuführen, dann die Ausgabe zu lesen. Der Agent ist nicht die Quelle der Wahrheit. Die Shell-Ausgabe ist es.

• Zählen: wc -l logs.txt ist wahr. Es gibt ungefähr 47 Log-Zeilen vom Modell ist eine Halluzination.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Nicht schätz das Volumen.
• Tests: pnpm test --reporter=json | jq '.numFailedTests'. Nicht fass zusammen, was gefailed ist.
• Git-Zustand: git rev-list --count main..HEAD, git diff --stat. Nicht zähl die Commits oder beschreib die Änderungen.

Wenn du das verinnerlicht hast, fängst du an, jede Stelle zu bemerken, an der der Agent gerade dabei war, eine Zahl zu erfinden. Sieht aus, als wären da ungefähr 200 Einträge... — nein. Führ SELECT count(*) aus. Die meisten Tests laufen durch... — nein. Führ die Test-Suite aus, parse das JSON. Das Modell ist hervorragend darin, den Befehl zu konstruieren. Es ist unzuverlässig darin, der Befehl zu sein.

Fehlerszenarien, die ich wirklich erlebt habe

Das sind keine Hypothesen. Jedes dieser Szenarien hat mich echte Zeit gekostet, bevor ich das Muster geändert habe:

• Phantom-Verifikation. Der Agent sagte ich habe alle 14 Sektionen gegen das Mockup geprüft. Er hat das Mockup nicht geöffnet. Keinen Screenshot gemacht. Die Prüfung war ein halluzinierter Schritt in der Erzählung.
• Selbstsichere falsche Zahlen. Ich fragte nach Monthly Active Users aus Analysedaten. Bekam eine Zahl, die um den Faktor ~3 daneben lag. Das Modell hat aus Beispiel-Rows interpoliert, statt die eigentliche Query auszuführen.
• Erfundene Dateiänderungen. Der Agent sagte ich habe config/feature-flags.json aktualisiert. Hatte er nicht. Er hatte es nur vorgehabt. git diff war leer.
• Gefälschte Test-Runs. Alle Tests laufen durch. Kein einziger Test wurde ausgeführt. Der Agent hat den Test-Runner nie aufgerufen — er hat vorhergesagt, wie dessen Ausgabe ausgesehen hätte.

Alle vier löst du mit denselben zwei Regeln: Agent aufteilen, in die Shell schieben. Der Reviewer hat kein Write, also kann er keine Dateien fake-bearbeiten. Der Analytics-Agent hat nur Bash, also kann er keine Zahl zurückgeben, die nicht aus einer Query stammt. Strukturelle Unmöglichkeit schlägt gute Absichten jedes Mal.

Wie man das in Claude Code strukturiert

Claude Code unterstützt Sub-Agenten, die in .claude/agents/*.md definiert werden. Jede Agent-Datei deklariert einen Namen, eine Beschreibung, ein erlaubtes Toolset und einen System-Prompt. Der Orchestrator (deine Hauptsession) ruft sie über das Agent-Tool auf. So sieht die Art von Definition aus, die ich für den Reviewer verwende — kurz, eng gefasst, und physisch nicht in der Lage, Code zu schreiben:

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

Beachte das Toolset: Bash, Read, Grep, Glob. Kein Write, kein Edit, kein Agent. Der Reviewer kann Befehle ausführen, Dateien lesen, nach Mustern suchen — und nichts weiter. Wenn er versucht, einen halluzinierten Diff als verifiziert durchzuschieben, macht die Form seiner Tool-Calls es sofort offensichtlich: Es gab keine echten Prüfungen. Du kannst die Tool-Calls auditieren und siehst genau, was tatsächlich inspiziert wurde.

Das Orchestrierungsmuster: Hauptsession ruft Builder auf → wartet → führt selbst git diff aus, um die tatsächliche Änderung zu erfassen → ruft Reviewer mit Spec und Diff auf → liest das Urteil. Die Hauptsession bittet nie einen Agenten, beides zu tun. Tool-Einschränkungen sind stärker als Prompt-Anweisungen: täusch die Verifikation nicht vor ist ein Wunsch. Kein Write zu haben ist ein Fakt.

Anti-Patterns, die du ablegen solltest

Dinge, die ich in Prompts sehe und die nichts bringen — oder schlimmer, ein falsches Sicherheitsgefühl vermitteln:

• Sei vorsichtig und überprüfe deine Arbeit nochmal. Erzeugt kein zusätzliches Verhalten. Das Modell produziert bereits das, was wie sorgfältige Arbeit aussieht.
• Stell sicher, dass du wirklich verifizierst. Das Wort wirklich fügt keine Semantik hinzu, auf die das Modell reagieren kann. Es wird wirklich behaupten, verifiziert zu haben.
• Halluziniere nicht. Ein Meme aus dem Prompt-Engineering. Halluzination ist kein Schalter, den das Modell umlegen kann.
• Dem Agenten bei kleinen Zahlen vertrauen. Bei kleinen Zahlen lügt er am selbstsichersten. Eine Untergrenze für Ehrlichkeit gibt es nicht.
• Mehr Regeln in den Prompt packen, um Ehrlichkeit zu erzwingen. Strukturelle Fixes (aufteilen + Shell) schlagen Prompt-Tweaks jedes Mal. Wenn eine Regel durchgesetzt werden muss, kodiere sie im Tool-Zugang — nicht in natürlicher Sprache.

Wenn deine Strategie gegen Halluzinationen aus emphatischerer Formulierung besteht, hast du keine Strategie. Du hast eine Hoffnung.

Das mentale Modell

Ein Agent ist kein Kollege. Er ist eine Funktion: prompt → tokens. Die Funktion ist hervorragend darin, Code zu schreiben, und miserabel darin, zu introspektieren, ob sie das Richtige getan hat. Behandle ihre Aussagen über die eigene Arbeit als Hypothese. Der Diff, der Exit-Code, der Screenshot, der Row Count — das sind die Belege. Die Zusammenfassung am Ende des Turns ist die lügenanfälligste Oberfläche im gesamten System.

Spezialisierung ist deine Versicherung gegen narrative Drift. Die Shell ist dein einziger Ground Truth. Builder schreibt. Reviewer prüft. Bash entscheidet.

Fazit

Wenn du dir eine Sache merkst: Lass keinen einzelnen Agenten seine eigene Ausgabe sowohl produzieren als auch beurteilen, und lass keinen Agenten eine quantitative Frage beantworten, ohne einen Befehl auszuführen. Alles andere ist ein Downstream-Effekt dieser zwei Regeln. Konfiguriere den Tool-Zugang konsequent, auditiere Tool-Calls statt Zusammenfassungen — und die Halluzinationsfläche schrumpft von überall auf ein paar konkrete Stellen, an denen du bereits weißt, wo du schauen musst.

Das Problem

Claude Code speichert standardmäßig alles in ~/.claude — OAuth-Token, Gesprächsverlauf, globale CLAUDE.md, Projekt-Gedächtnis, MCP-Server-Konfigurationen und Einstellungen. Bei zwei Accounts brauchst du zwei vollständig getrennte Welten:

• Persönlicher Account: eigenes Max/Pro-Abo, persönliche CLAUDE.md mit deinen Präferenzen, deine MCP-Server (Obsidian, persönliche Tools)
• Firmen-Account: vom Unternehmen verwalteter Plan, Arbeits-CLAUDE.md mit Jira/Slack-Integrationsanweisungen, Firmen-MCP-Server
• Unterschiedliche OAuth-Sessions: du kannst nicht in zwei Accounts im selben Konfigurationsverzeichnis eingeloggt sein
• Getrenntes Projekt-Gedächtnis: Arbeitskontext soll nicht in persönliche Sessions und umgekehrt gelangen

Sich jedes Mal aus- und einloggen beim Kontextwechsel ist keine Option. Du verlierst den Session-Zustand, und es ist einfach mühsam.

Die Lösung: CLAUDE_CONFIG_DIR

Claude Code respektiert eine einzige Umgebungsvariable: CLAUDE_CONFIG_DIR. Setze sie auf einen beliebigen Pfad, und Claude nutzt dieses Verzeichnis statt ~/.claude für alles — Auth, Verlauf, Einstellungen, Gedächtnis. Das gesamte Setup dauert 60 Sekunden.

Schritt 1: Zweites Konfigurationsverzeichnis erstellen

Wähle einen Namen, der zu deinem Anwendungsfall passt:

mkdir ~/.claude-work

Das war's. Claude füllt es beim ersten Start mit der nötigen Struktur.

Schritt 2: Zweiten Account authentifizieren

Starte Claude einmal mit dem neuen Konfigurationsverzeichnis für den OAuth-Login:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Der Browser öffnet sich. Logge dich mit dem Firmen-Account ein. Das OAuth-Token wird in ~/.claude-work gespeichert — vollständig getrennt von deiner persönlichen Session in ~/.claude.

Schritt 3: Shell-Alias hinzufügen

Füge dies zu deiner Shell-Konfiguration hinzu, damit du dir die Variable nicht merken musst:

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

Shell neu laden:

source ~/.zshrc

Was du bekommst

Jetzt hast du zwei vollständig isolierte Claude-Umgebungen:

• claude — startet mit persönlichem Account, persönlicher CLAUDE.md, persönlichem Gedächtnis
• claude-work — startet mit Firmen-Account, arbeitsspezifischer CLAUDE.md, separatem Gedächtnis
• Isolierter Verlauf: Arbeitsgespräche bleiben bei der Arbeit, Persönliches bleibt persönlich
• Getrennte MCP-Server: dein persönlicher Obsidian-Vault-MCP erscheint nicht in Arbeitssessions
• Unabhängige Einstellungen: verschiedene erlaubte Tools, verschiedene Berechtigungsstufen, verschiedene Modellpräferenzen pro Account

Wie es unter der Haube funktioniert

Das Konfigurationsverzeichnis ist die einzige Wahrheitsquelle für den Zustand von Claude Code. Hier ist, was in jedem lebt:

~/.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

Wenn du claude-work ausführst, liest Claude alles aus ~/.claude-work. Es weiß nichts von der Existenz von ~/.claude. Die beiden Instanzen sind komplett unabhängig — du kannst sie sogar gleichzeitig in verschiedenen Terminal-Tabs laufen lassen.

Skalierung auf N Accounts

Das Muster lässt sich auf beliebig viele Accounts erweitern. Freelancer mit mehreren Kunden? Füge mehr Aliase hinzu:

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

Jeder Alias bekommt sein eigenes Konfigurationsverzeichnis, seine eigene OAuth-Session, seine eigene CLAUDE.md mit kundenspezifischen Anweisungen.

Praktische Tipps

• Verzeichnisse klar benennen: ~/.claude-work, ~/.claude-clientname — du wirst dir dankbar sein, wenn es drei oder vier davon gibt
• Eigene CLAUDE.md für jeden schreiben: die Arbeits-CLAUDE.md kann firmenspezifische Anweisungen enthalten (Jira-Tickets, Slack-Kanäle, Deployment-Prozeduren). Die persönliche bleibt schlank.
• Verschiedene MCP-Server pro Account: Arbeits-Tools (Jira MCP, Slack MCP, interne APIs) nur in der Arbeitskonfiguration. Persönliche Konfiguration sauber halten.
• Aktiven Account prüfen: claude config list in einer Session ausführen — zeigt den Pfad zum Konfigurationsverzeichnis

Wo dieser Ansatz an Grenzen stößt

CLAUDE_CONFIG_DIR isoliert nach Account, nicht nach Projekt. Innerhalb eines einzelnen Profils sieht Claude jeden MCP-Server, den du jemals für diesen Account registriert hast — über all deine Projekte hinweg. Für rein persönliche Nutzung ist das meist unproblematisch. Sobald aber mehrere produktionskritische Projekte unter einem Account liegen, besonders in überlappenden Domänen wie Billing, Admin-Tooling oder Infrastruktur, entsteht ein konkretes projektübergreifendes Risiko: Ein KI-Assistent kann ein Tool aus Projekt A aufrufen, während er an Projekt B arbeitet — gerade dann, wenn beide Projekte ähnlich benannte Operationen exponieren.

Das Profil-Pattern beantwortet die Frage which account am I in?. Es beantwortet nicht die Frage which project's tools should be active right now?. Bei höherem Risikoeinsatz solltest du eine zweite Isolationsschicht über die Account-Trennung legen:

• Ein Profil pro produktionskritischem Projekt, nicht nur pro Account: Statt ~/.claude und ~/.claude-work lege ~/.claude-work-billing und ~/.claude-work-admin an. Jedes Profil sieht nur die MCP-Server, die es wirklich braucht.
• Projektbezogenes MCP über .mcp.json: Commite eine .mcp.json im Projekt-Root, die nur die MCP-Server dieses Projekts auflistet. Claude lädt sie, wenn es aus diesem Verzeichnis gestartet wird. Halte deine globale Konfiguration minimal — nur universelle Tools (Notizen, Suche), keine Produktions-Endpunkte.
• MCP-Server eindeutig benennen: Vermeide generische Namen wie admin, billing, mcp-server. Präfixiere mit dem Projektnamen: acme_billing_prod, acme_admin_stage. Ein aussagekräftiger Name erzwingt ein kurzes Innehalten, wenn etwas im falschen Kontext aufgerufen werden soll.
• Jeden MCP-Tool-Call vor dem Approve prüfen: Aufrufe wie *_create_*, *_delete_*, *_charge_* verdienen einen bewussten zweiten Blick. Die Geschwindigkeit, die pauschales Auto-Approve bringt, verpufft beim ersten Mal, wenn ein Tool aus dem falschen Projekt in Produktion feuert.

Die allgemeine Regel: Trenne Profile aggressiv, halte produktionsreife MCP-Server aus dem Default-Profil heraus, und behandle Überschneidungen bei Tool-Namen zwischen Projekten als Smell, der Refactoring verdient.

Fazit

Eine Umgebungsvariable. Ein Alias. Vollständige Isolation zwischen Accounts. Kein Logout/Login-Tanz, keine Konfigurationskonflikte, kein Kontextleck. Die Art von Lösung, die fast enttäuschend einfach ist — aber genau das macht sie gut. Einmal einrichten und nie wieder daran denken.

Was ist MCP und warum es nicht so einfach ist

MCP (Model Context Protocol) ist ein offenes Protokoll von Anthropic, das Claude erlaubt, sich mit externen Werkzeugen und Daten zu verbinden. Das Prinzip ist einfach: Ein lokaler Server läuft, stellt "Tools" bereit, und Claude ruft sie während der Konversation auf.

Für Obsidian gibt es theoretisch reichlich MCP-Server. In der Praxis — jeder hat seine eigenen Probleme.

Das Hauptproblem des Obsidian-Ökosystems: Obsidian ist eine geschlossene Anwendung ohne offizielles MCP. Die Community hat die Lücke gefüllt, aber jede Implementierung geht ihren eigenen Weg, und keine hat einen "offiziellen Segen".

Versuch 1: MarkusPfundstein/mcp-obsidian

Das erste Tool, das bei der Suche auftaucht. 3.400 Sterne auf GitHub, in jedem Tutorial. Scheint eine sichere Wahl.

Wie es funktioniert: Python-Server basierend auf dem Local REST API Plugin in Obsidian. Der Server kommuniziert mit dem Plugin über HTTPS, das Plugin führt Operationen über die Obsidian API aus.

Was schiefging

• Seit 17 Monaten nicht aktualisiert
• 85 offene Issues
• Kein move/rename — nur read, write, append, delete
• Local REST API hat einen dokumentierten Data-Loss-Bug: POST-Endpoint kann eine Datei beim Append stillschweigend überschreiben

Für Refactoring ungeeignet — wir müssen Dateien verschieben und Links bewahren. Weiter.

Versuch 2: aaronsb/obsidian-mcp-plugin

Eine Option gefunden, die als natives Obsidian-Plugin funktioniert. Das bedeutet direkten Zugriff auf Obsidians interne API — Backlinks, Dataview, Linkgraph. Move über die native API aktualisiert alle Wiki-Links automatisch, weil Obsidian das selbst handhabt.

Schwierigkeiten bei der Einrichtung

• Plugin ist nicht im offiziellen Obsidian-Katalog (PR hängt mit Validierungsfehlern)
• Installation über BRAT (Beta Reviewers Auto-update Tool) erforderlich
• Claude Desktop akzeptiert Bearer Token nicht direkt über die UI — erzwang die Aktivierung von HTTPS im Plugin
• Self-signed Zertifikat für localhost verursacht Vertrauensprobleme

Durch all diese Workarounds schließlich verbunden. Basistest — vault.move schreibt tatsächlich [[wikilinks]] um, funktioniert wie erwartet.

Was im Einsatz schiefging

Als ich mit dem Massen-Refactoring begann (Drag-and-Drop dutzender Ordner in Obsidian + gleichzeitige MCP-Operationen), hing der Server 4+ Minuten. Warum: Das Plugin läuft innerhalb von Obsidian. Wenn Obsidian tausende Dateien nach einer massiven Strukturänderung neu indiziert, blockiert das Plugin mit.

Fazit: Die Abhängigkeit von einer geöffneten Obsidian-Instanz und ihrem Index ist fatal für Massenoperationen.

Versuch 3: @bitbonsai/mcpvault

Logisch — wir brauchen einen Server, der nicht von Obsidian abhängt. Arbeitet direkt mit Dateien auf der Festplatte. @bitbonsai/mcpvault — in vielen Reviews empfohlen. Direkter Dateisystemzugriff, einfaches Setup (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 Tools. Obsidian muss nicht einmal geöffnet sein.

Vor der Installation habe ich einen kritischen Punkt überprüft — ob Wiki-Links beim Move aktualisiert werden. Ein Nutzerbericht:

Der Filesystem-Connector weiß nicht, dass er in Obsidian ist — er sieht einen Ordner mit <code>.md</code>-Dateien und das war's. Weiß nicht, dass Dateinamen semantisches Gewicht tragen, dass jeder <code>[[wikilink]]</code> im Moment des Umbenennens oder Verschiebens kaputt geht. Auto-Update Links funktioniert nur, wenn das Umbenennen innerhalb der App passiert. Ich erfuhr das, nachdem ich Claude gebeten hatte, Dateinamen aufzuräumen, und zu einem Dashboard mit halb kaputten Links zurückkehrte.

Bestätigt in mcpvaults eigener Dokumentation: PR #101 (Wiki Link Resolution) ist in Review, nicht gemergt. Also würde Move über mcpvault die Hälfte des Vaults kaputt machen. Ungeeignet.

Versuch 4: VaultForge (Finale)

blacksmithers/vaultforge — speziell für KI-Agenten gebaut, die Refactoring durchführen.

Architektonisch korrekt

• Direktes Dateisystem — keine Abhängigkeit von Obsidian
• Eigene Wikilink-Engine — implementiert [[wikilink]]-Auflösungslogik, die alle Formen aktualisiert (Stem, vollständiger Pfad, Alias, Embed)
• Dry Run standardmäßig bei allen destruktiven Operationen — zeigt erst, was sich ändert, dann bestätigst du
• 27 Tools vs. 8–14 bei Konkurrenten: batch_rename, update_links, backlinks (Impact-Analyse), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF Clustering)
• MIT-Lizenz, TypeScript, zero Sub-Dependencies
• Installation in 30 Sekunden über .mcpb (One-Click-Erweiterung für Claude Desktop)

Sicherheitstest an isolierten Dateien

4 Testdateien mit Querverweisen erstellt — Stem-Links, Links mit Alias, Links mit vollem Pfad. Eine Datei in einen Unterordner verschoben:

delta.md → subfolder/delta-renamed.md

VaultForge zeigte einen Dry Run: "1 Datei wird umbenannt, 3 Links werden aktualisiert". Tatsächlich ausgeführt.

Danach überprüft — alle drei Linktypen korrekt aktualisiert. Genau das fehlte allen vorherigen Tools.

Wie man VaultForge installiert — Finale Anleitung

Wenn Sie macOS und Claude Desktop haben:

Schritt 1

Laden Sie die .mcpb-Datei herunter:

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

Schritt 2

Claude Desktop öffnet den Erweiterungsinstallationsdialog. Geben Sie den absoluten Pfad zu Ihrem Vault ein — keine Backslashes, normale Leerzeichen:

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

Schritt 3

Klicken Sie auf Save. Claude Desktop fügt die Erweiterung automatisch zur Konfiguration hinzu. Kein Neustart nötig — .mcpb-Erweiterungen werden automatisch erkannt.

Schritt 4

Überprüfen: In einem neuen Chat fragen Sie: "What is the status of my Obsidian vault?" — sollte etwas wie totalFiles: 416, totalDirs: 135, ... zurückgeben

Was ich über das Obsidian-MCP-Ökosystem gelernt habe

Erstens: "Am beliebtesten" heißt nicht "funktioniert". MarkusPfundstein/mcp-obsidian hat 3.400 Sterne und ist die Standard-Empfehlung, aber es ist veraltet und es fehlen wichtige Operationen.

Zweitens: Ein natives Plugin hat versteckte Kosten. Das aaronsb Plugin sah ideal aus — Graph, Dataview, natives Move. Aber die Abhängigkeit von einer laufenden Obsidian-Instanz und ihrem Index macht es für ernsthafte Massenoperationen ungeeignet.

Drittens: Direktes Dateisystem ohne Link-Engine ist eine Falle. Mcpvault ist schnell und einfach, aber "einfach Dateien verschieben" zerstört die Vault-Struktur. Links tragen aufgezwungene Semantik, von der das Dateisystem nichts weiß. Ohne eigene Wikilink-Logik-Implementierung wird das Tool zur Landmine.

Viertens: An isolierten Daten testen. Bevor Sie einem Tool Massen-Refactoring anvertrauen — erstellen Sie einen Testordner mit 4–5 Dateien mit Querverweisen und sehen Sie, was passiert. 5 Minuten Testen sparen Stunden der Wiederherstellung aus Backups.

Fünftens: Halten Sie ein Git-Backup Ihres Vaults. Das Wichtigste von allem. Ein einziges git init innerhalb des Vaults und regelmäßige Commits — das ist die Versicherung gegen jeden Fehler eines KI-Agenten oder Tools. Wenn etwas kaputtgeht — git reset --hard bringt alles zurück.

Fazit

Der Weg dauerte mehrere Stunden und drei gescheiterte Versuche. Die finale Architektur sieht so aus:

• VaultForge — das Haupt-Arbeitswerkzeug. Direktes Dateisystem + eigene Wikilink-Engine + 27 Tools = stabiles Refactoring in jedem Maßstab.
• Git — Vault-Versionierung. Kostenloser Rollback für jeden Fehler.

Jetzt kann ich tun, wofür das alles begonnen wurde: Claude bitten, 400 Notizen in eine ordentliche PARA-Architektur zu sortieren, Duplikate zusammenführen, Frontmatter hinzufügen, MOC-Karten erstellen. Jede Operation ist sicher, Links bleiben erhalten, Dry Run zeigt was passiert, bevor sich etwas ändert.

Wenn Sie auch auf Ihr zugemülltes Obsidian schauen und einen KI-Assistenten wollen — fangen Sie direkt mit VaultForge an. Wiederholen Sie nicht meinen Weg durch tote Projekte, Beta-Plugins und Dateisystem-Server ohne Link-Logik.

Was wäre, wenn jedes Schwarze Loch ein Urknall eines neuen Universums ist? Dieser Artikel untersucht die Idee, dass unser Universum ein Knoten in einem unendlichen rekursiven Baum sein könnte — wo Schwarze Löcher Sub-Universen gebären, Energie durch Hawking-Strahlung zurückfließt und die fundamentalen Gesetze der Physik bewusst so gestaltet sind, dass ein Kontakt zwischen Universen unmöglich ist.

Schwarzes Loch = Universum

Die Idee kam während eines Moments der Reflexion: Ein Schwarzes Loch entsteht, wenn genug Masse und Druck sich in einem einzigen Punkt konzentrieren. Diese Singularität — unendliche Dichte, unendliche Krümmung — sieht verdächtig nach den Bedingungen aus, die wir für den Urknall beschreiben.

Was, wenn das dasselbe Ereignis ist, von verschiedenen Seiten betrachtet? Von außen sehen wir ein Schwarzes Loch, das Materie verschlingt. Von innen — ein neues Universum, das ins Dasein explodiert.

Jedes Schwarze Loch in unserem Universum könnte ein Universum enthalten. Und unser Universum könnte in einem Schwarzen Loch eines Elternuniversums existieren.

Warum Universen nicht miteinander kommunizieren können

Hier ist der elegante Teil: Sobald man den Ereignishorizont überquert, gibt es kein Zurück. Die Allgemeine Relativitätstheorie garantiert dies — die Zukunft des Elternuniversums liegt vollständig außerhalb des Ereignishorizonts.

Dies ist keine technische Einschränkung, die wir mit besserer Technologie überwinden könnten. Es ist in die Geometrie der Raumzeit selbst eingebaut.

Der Energiekreislauf: Leihen und Zurückgeben

Aber Energie geht nicht verloren. Die Hawking-Strahlung — der Quantenprozess, durch den Schwarze Löcher langsam verdampfen — erzeugt einen bemerkenswerten Kreislauf:

1. Ein Elternuniversum erzeugt ein Schwarzes Loch und überträgt Energie in ein Sub-Universum
2. Das Sub-Universum durchlebt seinen gesamten Lebenszyklus über Billionen von Jahren
3. Das Schwarze Loch verdampft langsam und gibt Energie durch Hawking-Strahlung zurück
4. Das Elternuniversum erhält seine Energie zurück — mit Zinsen

Diese "Zinsen" sind faszinierend: Physiker glauben nun, dass Hawking-Strahlung Information bewahrt. Das Elternuniversum bekommt nicht nur leere Energie zurück — es erhält einen Abdruck von allem, was im Inneren geschah.

Rekursion bis ganz nach unten

Wenn Sie Programmierer sind, ist das Muster unverkennbar. Dies ist Rekursion. Jedes Universum ruft universe() mit weniger Energie auf.

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

Der Physiker Lee Smolin formalisierte eine ähnliche Idee als Kosmologische Natürliche Selektion: Universen "reproduzieren" sich durch Schwarze Löcher.

Wo befinden wir uns in diesem Zyklus?

Unser Universum ist ungefähr 13,8 Milliarden Jahre alt. Im Kontext seiner gesamten Lebensdauer beobachten wir den allerersten Anfang:

Wir existieren bei ungefähr 0,00000000...01% der Gesamtlebensdauer unseres Universums.

Die Frage höherer Dimensionen

Alles bisher Besprochene operiert innerhalb unseres dreidimensionalen Verständnisses. Aber wenn unser Universum ein "Schnitt" von etwas Höherdimensionalem ist, könnte der gesamte rekursive Baum nur ein Schatten sein.

1884 schrieb Edwin Abbott Flachland — eine Geschichte über zweidimensionale Wesen, die sich keine dritte Dimension vorstellen können.

Was ist Bewusstsein? Warum existiert subjektive Erfahrung? David Chalmers nannte dies das "schwere Problem".

Alles ist auf fundamentaler Ebene blockiert

Die verblüffendste Erkenntnis ist nicht, dass wir nicht wissen — sondern dass wir nicht wissen können.

• Das Elternuniversum sehen? Blockiert durch den Ereignishorizont
• Bewusstsein verstehen? Blockiert — ein System kann sich nicht vollständig selbst analysieren
• Was war "davor"? Blockiert — die Zeit begann mit dem Urknall
• Höhere Dimensionen wahrnehmen? Blockiert durch kognitive Grenzen

Der Philosoph Colin McGinn nennt dies kognitive Schließung: Manche Fragen sind dem menschlichen Geist verschlossen — nicht wegen fehlender Daten, sondern wegen der Architektur des Geistes selbst.

Das Einzige, was bleibt: Selbstverbesserung

Wenn jeder Ausgang absichtlich blockiert ist, bleibt nur eine Richtung: nach innen.

Diese Schlussfolgerung kommt nicht aus der Religion. Sie kommt aus der Logik der Schwarzen Löcher, der Rekursion, der Informationstheorie und den Grenzen der Kognition.

Wir sind hier nicht durch Glauben angekommen, sondern durch Physik — von Schwarzen Löchern über rekursive Universen zu den fundamentalen Blockaden des Wissens.

Referenzen

• Lee Smolin — Kosmologische Natürliche Selektion
• Stephen Hawking — Hawking-Strahlung
• David Chalmers — Das Schwere Problem des Bewusstseins
• Edwin Abbott — Flachland (1884)
• Kurt Gödel — Unvollständigkeitssätze

Für einfache Websites — Portfolios, Blogs, Landing Pages, kleine Unternehmensseiten — wird ein traditionelles CMS zu unnötigem Overhead. KI-Tools wie Claude Code, Cursor und GitHub Copilot können Ihre Codebasis jetzt direkt bearbeiten, Kontext verstehen, Inhalte übersetzen und Änderungen über git deployen. Die Abstraktionsschicht, die CMS bot, wird durch ein intelligenteres Interface ersetzt: natürliche Sprache.

Die CMS-Steuer, die Sie zahlen

Jedes CMS bringt versteckte Kosten mit sich. Nicht nur die Abogebühr — das gesamte Ökosystem der Komplexität, das sich um Ihre ansonsten einfache Website wickelt:

• Infrastruktur: Eine Datenbank zum Hosten, eine API zum Warten, ein Dashboard zum Absichern. WordPress allein macht ~43% des Webs aus und ~90% der CMS-gezielten Angriffe.
• Performance: Dynamische Seitengenerierung, API-Aufrufe bei jeder Anfrage, clientseitige Hydration von CMS-Daten. Ihr 3-Seiten-Portfolio hat jetzt die Architektur eines SaaS-Produkts.
• Vendor Lock-in: Ihre Inhalte leben in einem fremden Datenbankschema. Migration von Contentful zu Sanity? Das ist ein Projekt, kein Config-Change.
• Kontextwechsel: Code in der IDE bearbeiten, dann zum browserbasierten CMS-Dashboard wechseln. Zwei verschiedene mentale Modelle für die gleiche Operation.
• Kosten: Headless-CMS-Preise skalieren oft mit API-Aufrufen oder Content-Einträgen. Ein persönlicher Blog braucht keine Content-Infrastruktur für $99/Monat.

Für eine Marketingseite, auf der 50 Leute täglich Content bearbeiten, sind diese Kosten gerechtfertigt. Für ein Entwickler-Portfolio? Sie bauen eine Brücke über eine Pfütze.

Was sich geändert hat: KI versteht Ihren Code

Der Grund für CMS war einfach: Nicht-technische Menschen brauchten ein visuelles Interface, um Websites zu aktualisieren. Der Code war zu komplex, zu fragil.

KI hat diese Gleichung fundamental verändert. Moderne KI-Coding-Tools verstehen Projektstruktur, lesen existierende Muster und machen kontextuell korrekte Bearbeitungen:

# 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

Das ist nicht hypothetisch. Dieser Blog läuft auf SolidStart mit Content in TypeScript-Dateien. Jeder Artikel wurde erstellt, indem man der KI sagt, was sie schreiben soll, das Ergebnis prüft und zu git pusht.

Echte Beispiele von dieser Website

Diese Website unterstützt 10 Sprachen, hat einen Blog, generiert OG-Bilder dynamisch und produziert RSS-Feeds. So sieht die Content-Schicht aus — reines 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
  },
};

Dinge, die ich mit KI mache und die traditionell ein CMS erfordern würden:

• Neuen Blogpost hinzufügen: "Schreibe einen Artikel über X" — KI erstellt die Datei, fügt Übersetzungen hinzu, registriert sie im Index
• Landing Page Text aktualisieren: "Ändere die Hero-Headline auf Y" — KI findet die richtige Datei
• Content übersetzen: "Füge deutsche Übersetzung hinzu" — KI liest die englische Version und produziert eine kulturell angepasste Übersetzung
• Tippfehler beheben: "Auf der About-Seite steht 'recieve'" — in 3 Sekunden erledigt, mit sinnvoller Commit-Nachricht

Was CMS wirklich gelöst hat — und wie KI es ersetzt

Seien wir ehrlich, was CMS gebracht hat und wie jede Fähigkeit auf den KI-Workflow abbildet:

Die Schlüsselerkenntnis: Git ist bereits ein besseres Versionskontrollsystem als jedes CMS jemals gebaut hat. Und natürliche Sprache ist ein besseres Interface als jeder WYSIWYG-Editor.

Der Paradigmenwechsel: Code ist die Content-Schicht

Wir beobachten eine Inversion. Zwanzig Jahre lang war der Trend, Content vom Code zu trennen. Das machte Sinn, als Code schwer zu bearbeiten war.

KI hat CMS nicht obsolet gemacht, indem sie ein besseres CMS wurde. Sie hat CMS obsolet gemacht, indem sie Code so zugänglich wie ein Dashboard machte.

Die Entwicklung des Web-Content-Managements folgt einer klaren Trajektorie:

1. 2000er: Monolithische CMS (WordPress, Drupal) — Content und Darstellung in einem System gekoppelt
2. 2010er: Headless CMS (Contentful, Strapi) — Content über API getrennt
3. 2020er: Statische Site-Generatoren + Markdown (Hugo, Astro) — Content als Dateien
4. 2025+: Code-as-Content + KI — Content lebt in typisiertem Code, KI ist das Editing-Interface

Wann Sie noch ein CMS brauchen

Dies ist kein "CMS ist tot"-Take. CMS löst echte Probleme im großen Maßstab:

• Große Redaktionsteams: 10+ Content-Editoren mit rollenbasiertem Zugriff und Genehmigungsworkflows
• Hochfrequenter Content: Nachrichtenseiten mit 50+ Artikeln pro Tag brauchen optimierte Redaktionspipelines
• Komplexe Content-Beziehungen: E-Commerce-Kataloge mit Tausenden SKUs brauchen strukturierte Datenbanken
• Regulatorische Compliance: Branchen mit Audit-Trails und rechtlich vorgeschriebenen Prüfprozessen

Die Grenze ist klar: Wenn Ihre Content-Änderungen Koordination zwischen mehreren nicht-technischen Stakeholdern mit hoher Frequenz erfordern, verdient CMS seine Komplexität.

Die Zukunft: KI als universelles Interface

Der Trend geht über CMS hinaus. Jede Abstraktionsschicht, die existierte, weil das zugrundeliegende System zu komplex war, wird durch KI komprimiert.

Für einfache Websites ist die Zukunft bereits hier. Ihr Content ist Code. Ihr Editor ist KI. Ihre Versionskontrolle ist Git. Ihr Deployment ist ein Push.

Das beste CMS ist kein CMS. Nicht weil Content-Management nicht wichtig ist — sondern weil KI den Code selbst zum intuitivsten Content-Management-Interface gemacht hat, das wir je hatten.

Perplexity Desktop unterstützt MCP (Model Context Protocol) Konnektoren. Durch Hinzufügen des offiziellen @modelcontextprotocol/server-filesystem Servers, der auf Ihren Obsidian Vault zeigt, können Sie Perplexity in natürlicher Sprache bitten, Notizen zu lesen, zu erstellen und zu bearbeiten — direkt aus dem Chat. Keine Plugins, keine Erweiterungen, kein Kopieren.

Das Problem

Perplexity ist großartig bei der Recherche — es durchsucht das Web, fasst Quellen zusammen und gibt Antworten mit Zitaten. Aber wenn Sie diese Erkenntnisse in Ihrem Obsidian Vault speichern möchten, bricht der Workflow ab: Text kopieren, zu Obsidian wechseln, die richtige Notiz finden, einfügen, formatieren. Jedes. Einzelne. Mal.

Browser-Erweiterungen wie "Perplexity to Obsidian" helfen beim Export, aber sie sind unidirektional — die KI kann Ihren Vault nicht sehen, kann bestehende Notizen nicht lesen und kann nicht entscheiden, wo Dinge basierend auf Ihrer Ordnerstruktur abgelegt werden sollen.

Was ist MCP?

Model Context Protocol (MCP) ist ein offener Standard, der KI-Modellen die Interaktion mit lokalen Tools und Datenquellen ermöglicht. Stellen Sie es sich als USB-Anschluss für KI vor — Sie schließen einen "Server" (ein kleines Programm) an, und die KI erhält neue Fähigkeiten. In unserem Fall gibt der Filesystem-Server Perplexity 14 Werkzeuge zur Dateiarbeit:

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

Der entscheidende Punkt: Das KI-Modell greift nicht direkt auf Ihre Dateien zu. Es ruft Werkzeuge auf, die vom MCP-Server bereitgestellt werden, der lokal auf Ihrem Rechner läuft. Ihre Daten verlassen Ihren Computer nicht, es sei denn, Sie bitten die KI ausdrücklich darum.

Voraussetzungen

• Perplexity Pro Abonnement (MCP-Konnektoren sind für zahlende Nutzer verfügbar)
• Perplexity Mac App aus dem App Store (nicht die Browser-Version)
• Node.js auf Ihrem Mac installiert (damit npx funktioniert)

Schritt-für-Schritt-Einrichtung

Die gesamte Einrichtung dauert etwa 2 Minuten:

Der Befehl

Der Befehl zum Einfügen in das Command-Feld:

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

Ersetzen Sie den Pfad durch den tatsächlichen Speicherort Ihres Obsidian Vaults. Wenn Ihr Vault über iCloud synchronisiert wird, befindet sich der Pfad unter ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/. Behalten Sie die Anführungszeichen bei — der Pfad enthält wahrscheinlich Leerzeichen.

Verwendung

Sobald der Konnektor Running mit 14 verfügbaren Werkzeugen anzeigt, gehen Sie zu einem beliebigen Perplexity-Chat und sprechen Sie mit Ihrem 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

Die KI versteht Ihre Vault-Struktur, respektiert Ihre Formatierungskonventionen und kann mit bestehenden Inhalten arbeiten. Sie können sie bitten, ein Thema im Web zu recherchieren und die Zusammenfassung direkt in einer bestimmten Notiz zu speichern.

Warum MCP andere Ansätze übertrifft

Vor MCP gab es begrenzte Möglichkeiten, Perplexity und Obsidian zu verbinden:

Aktuelle Einschränkungen

• Nur Mac — Perplexity MCP-Konnektoren funktionieren derzeit nur in der Mac App Store Version
• Keine Obsidian-API-Integration — der Filesystem-Server arbeitet mit Rohdateien, nicht über die Obsidian-API. Das bedeutet, er löst keine Obsidian-Plugins (Linter, Templater) beim Erstellen von Dateien aus
• Bestätigung erforderlich — sensible Dateioperationen erfordern möglicherweise Ihre Bestätigung in der Perplexity-App — das ist ein Sicherheitsfeature, kein Bug

Fazit

Dieses Setup verwandelt Perplexity von einem Recherche-Tool in ein Recherche-und-Erfassungs-Tool:

1. Im Web recherchieren und in Obsidian speichern — in einem Gespräch
2. Die KI sieht Ihre Vault-Struktur und passt sich Ihrem Organisationssystem an
3. Kein App-Wechsel — alles passiert im Perplexity-Chat

Quellen

• 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

Ein 6-zeiliges Bash-Skript, das Claude Code CLI jeden Morgen um 9:00 Uhr im Headless-Modus ausführt. Es durchsucht das Web nach Nachrichten zu 11 konfigurierbaren Themen, filtert Rauschen heraus und schreibt einen formatierten Markdown-Digest direkt in einen Obsidian Vault, der über iCloud synchronisiert wird. Null Abhängigkeiten. ~100 Zeilen Konfiguration insgesamt.

Das Problem

Als Entwickler ist es eine tägliche Steuer, über mehrere Technologien auf dem Laufenden zu bleiben. RSS-Feeds sind laut, Twitter ist ein Zeitfresser, Newsletter kommen wenn man tief im Flow ist. Ich brauchte etwas, das die Recherche für mich erledigt und die Ergebnisse dort präsentiert, wo ich bereits arbeite — meinem Obsidian Vault.

Die typische Lösung ist eine Scraping-Pipeline: ein Scheduler, ein Crawler, eine NLP-Pipeline, eine Datenbank, ein Benachrichtigungsdienst. Das sind Wochen Arbeit für etwas, das kaputt geht wenn eine Website ihr HTML ändert. Ich wollte etwas, das an einem Nachmittag fertig ist.

Architektur

Das gesamte System besteht aus 4 Dateien und null Abhängigkeiten. So funktioniert es End-to-End:

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

Der Code (komplett)

Das Projekt ist bewusst minimal. Jede Zeile verdient ihren Platz.

Einstiegspunkt: digest.sh

Die gesamte Anwendung ist ein 6-zeiliges 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

Die wichtigen Flags: -p führt Claude im Headless-Modus aus, --max-turns 20 gibt dem Agenten genug Raum für alle Themen, und --allowedTools beschränkt den Agenten auf Dateilesen, Websuche und Schreiben.

Das Gehirn: prompt.md

Hier lebt die Intelligenz. Der Prompt verwandelt Claude in einen Nachrichtenrecherche-Agenten mit spezifischen Anweisungen:

# 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

Themen sind vollständig konfigurierbar — füge ein neues Thema hinzu und es ist im morgigen Digest enthalten:

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"

Planung mit launchd

Auf macOS ist launchd der native Weg, wiederkehrende Aufgaben zu planen (wie cron unter Linux):

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

Installation mit launchctl load ~/Library/LaunchAgents/com.news-digest.plist. Das Skript läuft jeden Tag um 9:00 Uhr — launchd führt verpasste Jobs aus wenn das System aufwacht.

Wie das Ergebnis aussieht

Jeden Morgen erscheint eine neue Markdown-Datei im Obsidian Vault mit strukturierten, priorisierten Nachrichten:

---
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/...)

In Zahlen

Wichtige Designentscheidungen

• Claude Code CLI statt API — kein Verwalten von API-Schlüsseln, HTTP-Clients oder Response-Parsing nötig
• Obsidian statt E-Mail — Digests sind durchsuchbar, verlinkbar und permanent
• launchd statt cron — launchd ist der macOS-native Scheduler mit sauberem Handling von verpassten Läufen
• YAML für Themen — ein neues Thema ist eine 2-Zeilen-Änderung
• Leere Themen überspringen — keine Nachrichten = kein Abschnitt

Eigenes bauen

In 10 Minuten einsatzbereit:

1. Claude Code CLI installieren und authentifizieren
2. Repo klonen: git clone https://github.com/oleksiimazurenko/news-digest
3. topics.yaml und prompt.md anpassen
4. Plist-Datei anpassen und mit launchctl load laden
5. Auf 9:00 Uhr warten — oder mit bash digest.sh manuell testen

Fazit

Das Interessanteste an diesem Projekt ist, was nicht drin ist. Keine Datenbank, kein API-Server, kein Docker, keine npm-Pakete, kein Python, kein HTML-Parser, keine NLP-Pipeline.

So sieht Bauen mit AI-Agenten in der Praxis aus: Sie definieren das Was und Wohin, der Agent übernimmt das Wie. Gesamte Entwicklungszeit: etwa 2 Stunden.

Quellen

• 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 rendert ein <script>-Tag innerhalb einer React Client Component, um Theme-Flackern (FOUC) zu verhindern. React 19 warnt jetzt davor — und es gibt keine Möglichkeit, die Warnung zu unterdrücken. Die Bibliothek wurde seit März 2025 nicht mehr aktualisiert. Die Lösung: next-themes durch einen Zustand Store + useServerInsertedHTML ersetzen, um das Script außerhalb des React-Baums einzufügen. Keine neuen Abhängigkeiten. Kein Flackern. Keine Warnungen.

Das Problem

Wenn Sie next-themes mit Next.js 15+ und React 19 verwenden, erhalten Sie bei jedem Seitenaufruf diesen Fehler in der Konsole:

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

Dies ist kein Hydration-Mismatch. React 19 warnt explizit, dass <script>-Tags, die von React-Komponenten auf dem Client gerendert werden, nie ausgeführt werden. Das Script funktioniert während SSR (es ist im HTML), aber React markiert es als fehlerhaft.

Warum es passiert

next-themes muss die korrekte Theme-Klasse auf <html> setzen, bevor React hydriert — sonst gibt es ein Aufblitzen des falschen Themes. Dafür wird ein Inline-<script> über React.createElement eingefügt:

// 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 hat sein Verhalten geändert: Script-Tags in Komponenten werden jetzt explizit markiert. Vor React 19 wurde dies stillschweigend ignoriert. Das suppressHydrationWarning-Prop auf dem Script hilft nicht — es unterdrückt Hydration-Warnungen, nicht die "Script in Komponente"-Warnung.

Was wir versucht haben (und warum es scheiterte)

Wir haben systematisch jeden Ansatz ausprobiert, bevor wir die Lösung fanden:

Die Lösung: Zustand + useServerInsertedHTML

Die wichtigste Erkenntnis: useServerInsertedHTML ist ein Next.js-Hook, der HTML in den SSR-Stream außerhalb des React-Komponentenbaums einfügt. Das Script landet im HTML, aber React "sieht" es beim Client-Rendering nie — also keine Warnung. Kombiniert mit einem Zustand Store für reaktiven Theme-State ergibt sich ein vollständiger Ersatz ohne Abhängigkeiten.

Wie es funktioniert

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

Schritt 1: Zustand Store

Der Store verwaltet den Theme-State, wendet Klassen auf das DOM an, erkennt das System-Theme und synchronisiert über Tabs. Die _init()-Methode gibt eine Cleanup-Funktion für useEffect zurück:

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,
  }));
}

Schritt 2: ThemeProvider

Der Provider macht zwei Dinge: Er fügt das FOUC-Präventionsskript über useServerInsertedHTML ein und initialisiert den Zustand Store beim Mounten:

"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}</>
}

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

Schritt 4: Verwendung

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 von next-themes

Die API ist absichtlich identisch. Die Migration ist eine einzige Import-Änderung pro Datei:

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

Vergleich

Warum nicht andere Alternativen?

@wrksz/themes

Ein Drop-in-Ersatz, der ebenfalls useServerInsertedHTML verwendet. Es funktioniert, aber es ist eine weitere Abhängigkeit von einem einzelnen Maintainer. Wenn uns next-themes etwas gelehrt hat — Abhängigkeiten werden aufgegeben. Mit ~100 Zeilen Code können Sie die Lösung vollständig besitzen.

next-themes@1.0.0-beta.0

Existiert auf npm, aber ohne Veröffentlichungsdatum, ohne Changelog und ohne klaren Hinweis, dass die React-19-Warnung behoben ist. Produktionscode auf eine unbefristete Beta zu setzen, ist kein lohnenswertes Risiko.

CSS-only (prefers-color-scheme)

Funktioniert für die System-Theme-Erkennung, kann aber keine Benutzerpräferenz-Persistenz (localStorage), manuelles Theme-Wechseln oder die "system"-Option handhaben. Dafür braucht man JavaScript.

Schlussfolgerungen

1. next-themes ist effektiv aufgegeben — letztes Release März 2025, React-19-Warnung nicht behoben
2. useServerInsertedHTML ist das korrekte Next.js-Primitiv zum Einfügen von Scripts ohne React-Warnungen
3. Zustand bietet reaktiven Theme-State mit weniger Code als ein Context-Provider
4. Die gesamte Lösung umfasst ~100 Zeilen, keine neuen Abhängigkeiten, und Sie besitzen jede Zeile

Quellen

• 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

Unsere App (Promova) nutzt Next.js 16 mit einem Landing Builder — einem CMS-gesteuerten System, das Marketingseiten aus ~90 verschiedenen Sektionskomponenten zusammenstellt (Heroes, FAQs, Preise, Bewertungen etc.). Die Architektur nutzt eine sectionRegistry.tsx, die Sektionsnamen auf next/dynamic()-Aufrufe abbildet:

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

Eine einzelne Landingpage rendert nur 5-8 Sektionen. Aber Lighthouse zeigte:

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

Warum? Turbopack sieht alle 90 import()-Pfade als erreichbar und generiert <link rel="stylesheet"> für jedes SCSS-Modul. Selbst Sektionen, die nie auf der Seite gerendert werden, bekommen ihr CSS in <head> injiziert. Dies ist ein bestätigtes, erwartetes Verhalten des Next.js App Router. CSS wird für dynamic()-Imports aus Server Components nicht code-gesplittet. Die Maintainer betrachten es als bewussten Kompromiss zur Vermeidung von FOUC. Ein Fix ist nicht geplant.

Alles, was ich versucht habe (und warum es scheiterte)

Ich habe Tage damit verbracht, jeden Ansatz durchzugehen, den ich finden konnte. Hier die vollständige Liste:

Die inlineCss-Falle

Next.js hat ein experimental.inlineCss-Flag, das alle <link rel="stylesheet"> durch Inline-<style>-Tags ersetzt. Klingt perfekt, oder?

Das Problem: Es ist alles oder nichts. Man kann es nicht pro Route aktivieren. Bei SSR-(force-dynamic)-Seiten wird bei jedem Request das gesamte CSS inline neu gebaut. Wir haben es versucht — unser headless CMS konnte die Last nicht bewältigen und ging down. Damit es sicher funktioniert, müssen 100% der Seiten force-static oder ISR sein. Mit 20+ SSR-Seiten (Auth, Dashboards, dynamische Seiten) ist das eine massive Migration.

Die Entdeckung: Turbopack Import Attributes

Beim Durchstöbern der Next.js 16.2 Release Notes fand ich ein kaum dokumentiertes Feature: Turbopack Import Attributes. Es erlaubt, die eingebaute Bundler-Pipeline für einen bestimmten Import mit der TC39 with {}-Syntax zu überschreiben:

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

Dies sagt Turbopack: "Verarbeite diesen Import nicht als Stylesheet. Führe ihn durch meinen Custom Loader und behandle die Ausgabe als JavaScript."

Das ist die Schlüsselerkenntnis. Anstatt dass Turbopack ein <link rel="stylesheet"> generiert, das das Rendering blockiert, kompiliert unser Loader das SCSS und exportiert es als JS-String. Wir injizieren es dann als Inline-<style>-Tag direkt in die Komponente. Das Ergebnis: Nur das CSS für Sektionen, die tatsächlich rendern, kommt in den HTML-Code der Seite.

Die Lösung

1. Custom Turbopack Loader

Ein ~70-zeiliges Node.js-Script als 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')
}

Was es macht: styles — dieselbe Scoped-Klassennamen-Map wie Standard-CSS-Modules. cssText — das kompilierte CSS als String.

2. InlineStyle-Komponente

Nutzt React 19s eingebaute <style href precedence>-API für automatische Deduplizierung:

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

React 19 garantiert: gleicher href → nur ein <style> im DOM.

3. Migration pro Komponente (~6 Zeilen pro 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>
  )
}

Die .module.scss-Dateien bleiben exakt gleich. Kein CSS-Umschreiben. Stylelint, Prettier, IDE-Support — alles bleibt erhalten.

Warum das besser ist als inlineCss: true

Das ist der entscheidende Unterschied:

Mit inlineCss: true bekommt eine Seite immer noch ALLE 94 Stylesheets inline. Mit unserem Ansatz kommt nur das CSS, das tatsächlich gerendert wird, ins HTML.

Turbopack-Stolperfalle: Keine globalen Regeln für .module.scss

Eine Falle, in die ich getappt bin: Man könnte denken, dass man eine Turbopack-Regel in next.config.ts hinzufügen kann, um den Loader global anzuwenden:

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

Tun Sie das nicht. Turbopacks eingebaute CSS-Module-Pipeline fängt .module.scss-Dateien ab, bevor Custom-Regeln angewendet werden, was verursacht:

FATAL PANIC: inner asset should be CSS processable

with {}-Attribute funktionieren, weil sie Turbopack an der Import-Stelle anweisen, die CSS-Module-Pipeline vollständig zu umgehen.

Ergebnisse

127 Sektionskomponenten im Landing Builder migriert. Produktions-Build verifiziert.

Einschränkungen

• with {} pro Import ist ausführlich — jeder Import braucht 3 zusätzliche Zeilen.
• Nur Turbopack — with {}-Attribute werden von Webpack nicht unterstützt.
• Klassennamen-Hashing — unser Loader nutzt einen anderen Hashing-Algorithmus als Turbopacks eingebauter.
• HTML-Größe steigt — CSS ist inline im HTML statt als separate Dateien gecacht.

Wann man das nutzen sollte

Diese Technik ist am effektivsten, wenn:

1. Sie ein Registry/Barrel-Pattern haben — eine Datei importiert viele Komponenten, aber nur wenige rendern pro Seite
2. Sie Turbopack nutzen — Import Attributes sind Turbopack-spezifisch
3. Sie Kontrolle pro Komponente wollen — kein Alles-oder-Nichts-Flag
4. Ihr SCSS komplex ist — Variablen, Mixins, Breakpoints, Nesting — alles unterstützt
5. Sie experimental.inlineCss nicht nutzen können — weil Sie SSR-Seiten haben oder granulare Kontrolle wollen

Verwandte GitHub Issues

Wenn Sie von Render-blockierendem CSS im Next.js App Router betroffen sind — Sie sind nicht allein:

Das Kernproblem

• #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 Feature & Issues

• 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

Community sucht Lösungen

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

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

Gebaut bei Promova — einer Sprachlernplattform für Millionen von Nutzern.

Next.js patcht den globalen fetch und fügt eine Cache-Schicht hinzu, die Referenzen auf Response-Daten hält, nachdem sie freigegeben werden sollten. Jeder fetch-Aufruf fügt Speicher hinzu, der nie vom GC zurückgegeben wird. In Docker/Kubernetes führt dies alle paar Stunden zu OOM-Crashes. Der Bug existiert seit Next.js 14 (April 2024) und ist in 16.2.x (März 2026) noch ungelöst. Auf Vercel tritt das Problem dank ephemerer Serverless-Funktionen nicht auf.

Wie normaler Fetch funktioniert

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

Wie Fetch in Next.js funktioniert

Next.js fängt den globalen fetch ab und umhüllt ihn mit einer eigenen Cache-/Tracking-Schicht:

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

Was in Produktion passiert

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

Betroffene Versionen

Next.js — Alle Versionen mit App Router

Node.js

Getestet auf Node.js 20, 22, 24, 25 — leckt auf allen.

Was nicht funktioniert

Was funktioniert (Workarounds)

Einschränkung des Axios-Workarounds

Eigene API-Aufrufe können durch axios ersetzt werden. Aber Next.js verwendet intern den gepatchten fetch für:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• Server Components Data Fetching mit Deduplizierung
• use cache (Next.js 16)

Selbst ohne einen einzigen fetch im eigenen Code — Next.js verwendet ihn intern weiterhin.

Warum Vercel es nicht fixt

Geschäftslogik

Vercel verdient Geld mit dem Hosting von Next.js. Auf ihrer Plattform tritt das Problem nicht auf (serverless = ephemeral). Der Bug betrifft nur Self-Hosted (Docker, K8s, VPS) — also die, die nicht an Vercel zahlen.

Offizielle Position

Tim Neutkens (Vercel-Maintainer) analysierte das Problem und erklärte es zum undici-Problem (Node.js-Fetch-Bibliothek), nicht Next.js. Issue #90433 wurde geschlossen. Obwohl:

• axios und node-fetch auf demselben Node.js ohne Leaks funktionieren
• Das Leak nur auftritt, wenn fetch durch den Next.js-Wrapper geht
• Der Bug seit 2 Jahren ohne Fix offen ist

Prioritäten

In diesen 2 Jahren hat das Next.js-Team veröffentlicht:

• Turbopack (2-5x schnellere Builds) — Marketingvorteil
• Cache Components / use cache — reduziert Last auf Vercel-Servern
• proxy.ts statt Middleware — vereinfacht Edge-Deployment auf Vercel
• DevTools MCP — AI-Hype

Memory Leak bei Self-Hosted? Keine Priorität.

Lösung: AWS Lambda (SST + OpenNext)

Was ist das

OpenNext ist ein Open-Source-Adapter, der einen Next.js-Build in ein AWS-Lambda-Format konvertiert. SST ist ein Framework zur Automatisierung der Infrastruktur.

Architektur

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

Warum dies das Memory Leak löst

Lambda-Funktionen verarbeiten Anfragen und werden nach 5-15 Minuten Inaktivität recycelt. Speicher hat keine Zeit sich anzusammeln.

Deployment

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

Vergleich

Lambda-Nuancen

• Cold Starts — erste Anfrage ist langsamer (~200-500ms)
• Sicherheit — OAC (Origin Access Control) aktivieren, sonst ist die Lambda-URL öffentlich
• OpenNext — Community-Projekt, nicht offiziell von Vercel. Neue Next.js-Features können brechen
• Wallet-Attacke — bei DDoS kann Lambda-Auto-Scaling zu einer hohen Rechnung führen

Warum ein echter Fix unrealistisch ist

1. Architekturproblem

Das Leak ist kein zufälliger Bug, sondern Folge einer Design-Entscheidung: Next.js fängt den globalen fetch ab und fügt Cache/Tracking darüber hinzu. Um es zu fixen, müsste die Art, wie App Router mit fetch interagiert, neu designed werden. Das betrifft ISR, Revalidation, Data Cache, Request Deduplication — den Kern des Frameworks.

2. Interessenkonflikt

Vercel ist nicht motiviert zu fixen, was ihre Plattform nicht betrifft. Self-Hosted konkurriert mit ihrem Geschäft. Je mehr Probleme bei Self-Hosted — desto mehr Menschen migrieren zu Vercel.

3. Blame Shifting

Die offizielle Position lautet "es ist undici, nicht wir". Solange sich das nicht ändert, wird nicht an einem Fix gearbeitet.

4. Kein Community Fix

Die AGPL-3.0-Lizenz von Next.js erlaubt Forks, aber die Codebasis ist riesig und eng mit der Vercel-Infrastruktur gekoppelt. Ein Community-PR zum Fixen des Fetch-Wrappers würde tiefes Verständnis der internen Architektur und Zustimmung der Maintainer erfordern — die das Issue bereits geschlossen haben.

Schlussfolgerungen

1. Auf Vercel — kein Problem, nichts zu tun
2. Self-Hosted mit Serverless-Bedarf — SST + OpenNext auf AWS Lambda
3. Self-Hosted Docker — fetch durch axios ersetzen wo möglich, RAM überwachen, automatische Pod-Neustarts einrichten
4. Neues Projekt — SvelteKit oder Nuxt als Alternative ohne dieses Problem erwägen

Quellen

• 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