Konfiguration

Die gesamte Konfiguration befindet sich in der .env-Datei im Projektstammverzeichnis. Diese Datei ist per gitignore ausgeschlossen — sie wird niemals committet.

Umgebungsvariablen

KI-Anbieter

Der Container unterstützt zwei sich gegenseitig ausschließende Authentifizierungsmodi (in Prioritätsreihenfolge):

• LiteLLM-Proxy — setzen Sie LITELLM_BASE_URL und LITELLM_API_KEY, um über einen LiteLLM-Proxy zu routen (siehe unten).
• OAuth-Modus — setzen Sie nur CLAUDE_CODE_OAUTH_TOKEN (siehe unten).

Kombinieren Sie keine Modi — verwenden Sie genau einen.

Claude Max (OAuth)

Variable	Beschreibung	Beispiel
CLAUDE_CODE_OAUTH_TOKEN	OAuth-Token aus einem Claude Max-Abonnement	sk-ant-oat01-...

Wenn gesetzt, authentifiziert sich Claude Code direkt bei Anthropic über OAuth — kein API-Schlüssel oder Proxy erforderlich. Erhalten Sie Ihr Token in den Claude Code-Einstellungen oder der Anthropic-Konsole.

LiteLLM-Proxy

Wenn Ihr LiteLLM- (oder anderer) Proxy bereits die native Anthropic Messages API spricht — einschließlich web_search, Streaming und Tool-Nutzung — setzen Sie LITELLM_BASE_URL auf die Proxy-Domain. Der Container leitet automatisch die anbieterspezifischen URLs ab:

• Anthropic-Endpunkt → ${LITELLM_BASE_URL}/anthropic (verwendet von Claude Code)
• OpenAI-kompatibler Endpunkt → ${LITELLM_BASE_URL}/openai/v1

Variable	Beschreibung	Beispiel
LITELLM_BASE_URL	Domain Ihres LiteLLM-Proxys (ohne Pfad-Suffix)	https://litellm.example.com
LITELLM_API_KEY	API-Schlüssel für die Proxy-Authentifizierung	your-api-key oder Standard litellm-proxy

Benutzer müssen nur die Domain setzen — Anbieter-Pfad-Suffixe werden automatisch hinzugefügt. Zur Laufzeit leitet der Entrypoint ANTHROPIC_API_KEY aus LITELLM_API_KEY ab, sodass Claude Code die Proxy-Anmeldedaten verwenden kann, ohne eine separate benutzerseitige Variable zu erfordern.

Modellnamen werden in diesem Modus nicht umgemappt. Claude Code sendet seine Standard-Modellbezeichner (z. B. claude-sonnet-4-6) und LiteLLM routet sie zu Ihrem konfigurierten Backend.

TLS-Zertifikatsvalidierung

Standardmäßig validiert Node.js TLS-Zertifikate für alle HTTPS-Verbindungen. Wenn Ihr Upstream-API-Anbieter ein selbstsigniertes Zertifikat verwendet (häufig bei internen Open WebUI- oder LiteLLM-Proxys), können Sie die Validierung deaktivieren, indem Sie Folgendes zu Ihrer .env-Datei hinzufügen:

NODE_TLS_REJECT_UNAUTHORIZED=0

Dies wird für den Produktionsbetrieb nicht empfohlen. Setzen Sie dies nur, wenn Sie dem Netzwerkpfad zwischen dem Container und Ihrem API-Endpunkt vertrauen.

KI-Coding-Agenten

Der Container enthält neben Claude Code mehrere KI-Coding-Agenten:

Agent	Befehl	Anbieter
Codex	codex	OpenAI-kompatibel
Pi	pi	Multi-Anbieter (zur Laufzeit konfigurieren)
Oh-My-Pi	omp	Multi-Anbieter (zur Laufzeit konfigurieren)

Pi und Oh-My-Pi werden als globale npm-Pakete installiert. Codex ist eine eigenständige Binärdatei, die sich zur Laufzeit selbst aktualisiert.

Remote-Anzeige (noVNC)

Der Container betreibt einen virtuellen Display-Stack zum Beobachten und Interagieren mit grafischen Browsern. Siehe Remote-Anzeige (noVNC) für Verbindungsanweisungen und Umgebungsvariablen (ENABLE_VNC, VNC_RESOLUTION, DISPLAY, NOVNC_HOST_PORT).

Chrome DevTools MCP

Der Container enthält einen vorkonfigurierten Chrome DevTools MCP-Server für headless Browser-Automatisierung. Claude Code kann Webseiten navigieren, Screenshots erstellen und das DOM inspizieren, ohne zusätzliche Einrichtung. Siehe Chrome DevTools MCP für Details.

Git

Variable	Beschreibung	Einstellung
GIT_AUTHOR_NAME	Name für Git-Commits	git config user.name
GIT_AUTHOR_EMAIL	E-Mail für Git-Commits	git config user.email

Wenn Git auf Ihrem Host konfiguriert ist, füllen Sie beide Werte automatisch aus:

echo "GIT_AUTHOR_EMAIL=$(git config user.email)" >> .env
echo "GIT_AUTHOR_NAME=\"$(git config user.name)\"" >> .env

SSH

Variable	Beschreibung	Einstellung
SSH_PRIVATE_KEY	Base64-kodierter privater Schlüssel	base64 < ~/.ssh/id_ed25519

GitHub CLI

Variable	Beschreibung	Einstellung
GH_TOKEN	Persönlicher GitHub-Zugriffstoken für gh-CLI und HTTPS-Git	gh auth token (wenn gh lokal installiert ist)

Wenn GH_TOKEN in .env gesetzt ist, authentifiziert sich die gh-CLI automatisch — kein gh auth login erforderlich. Der Entrypoint führt auch gh auth setup-git aus, das den Git-Credential-Helper konfiguriert, sodass HTTPS git clone und git push ohne SSH-Schlüssel funktionieren.

Wenn gh auf Ihrem Host-Rechner installiert und authentifiziert ist, extrahieren Sie das Token direkt:

echo "GH_TOKEN=$(gh auth token)" >> .env

Andernfalls erstellen Sie einen persönlichen Zugriffstoken und fügen Sie ihn manuell hinzu. Sowohl feingranulare Tokens (empfohlen) als auch klassische Tokens funktionieren. Feingranulare Tokens ermöglichen es Ihnen, den Zugriff auf bestimmte Repositories einzuschränken. Klassische Tokens erfordern den repo-Scope für den Zugriff auf private Repositories.

Um die Authentifizierung innerhalb des Containers zu überprüfen:

gh auth status

Wie Tools installiert werden

Jede Laufzeitumgebung, CLI und jedes Tool wird direkt im Dockerfile zur Build-Zeit installiert. Das vorgefertigte Image wird bei jedem Push auf main auf ghcr.io/f5-sales-demo/devcontainer:latest veröffentlicht, sodass die meisten Benutzer nie lokal bauen müssen.

Docker

Das Ausführen von docker compose up -d zieht das vorgefertigte Image automatisch. Um nach dem Anpassen des Dockerfiles lokal zu bauen, übergeben Sie die Build-Datei explizit:

docker compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Siehe Lokale Entwicklung für Details.

Podman

Das Ausführen von podman-compose up -d zieht das vorgefertigte Image automatisch. Um nach dem Anpassen des Dockerfiles lokal zu bauen, übergeben Sie die Build-Datei explizit:

podman-compose -f docker-compose.yml -f docker-compose.build.yml up -d --build

Siehe Lokale Entwicklung für Details.

Das Dockerfile verwendet einen zweistufigen Build, der für Docker-Layer-Caching optimiert ist. Siehe Lokale Entwicklung — Zweistufige Build-Architektur für die vollständige Schichtaufschlüsselung und Build-Cache-Details.

Claude Code Tool-Erkennung

Der Container enthält eine integrierte Konfiguration, die verhindert, dass Claude Code Tool-Namen verwechselt. Die Tool-Erkennung ist auf zwei Speicherebenen für Defense-in-Depth installiert:

• Verwaltete Richtlinie (/etc/claude-code/CLAUDE.md) — wird zur Docker-Build-Zeit installiert. Dies ist die Ebene mit der höchsten Priorität in der Speicherhierarchie von Claude Code und wird immer geladen, auch wenn eine große Projekt-CLAUDE.md im Arbeitsverzeichnis existiert.
• Benutzerspeicher (~/.claude/CLAUDE.md) — wird vom Entrypoint beim ersten Start angelegt. Bietet eine Backup-Schicht und eine sichtbare, anpassbare Kopie für Benutzer.

Speicherebenen-Priorität

Claude Code lädt Anweisungen aus mehreren Speicherebenen (höchste bis niedrigste Priorität):

1. Verwaltete Richtlinie (/etc/claude-code/) — Wird immer geladen, kann nicht ausgeschlossen werden
2. Projektspeicher (./CLAUDE.md) — Wird pro Projektverzeichnis geladen
3. Benutzerspeicher (~/.claude/CLAUDE.md) — Wird global für alle Sitzungen geladen
4. Lokaler Speicher (./CLAUDE.local.md) — Persönliche projektspezifische Überschreibungen

Ohne die verwaltete Richtlinienebene kann die Tool-Erkennung im Benutzerspeicher herabgestuft werden, wenn sie mit einer großen CLAUDE.md auf Projektebene konkurriert, wodurch Claude das Bewusstsein für seine PascalCase-Tool-Namen verliert. Die verwaltete Ebene garantiert, dass die Tool-Erkennung immer mit der höchsten Priorität geladen wird.

Selbsttest

Führen Sie den integrierten Selbsttest aus, um die Konfiguration zu überprüfen:

claude-self-test

Dies prüft, ob alle Konfigurationsdateien vorhanden sind und die erwarteten Tool-Referenzen enthalten.

Tools hinzufügen

Um Tools zum Image hinzuzufügen, bearbeiten Sie das Dockerfile und bauen Sie lokal neu. Siehe Lokale Entwicklung — Tools hinzufügen für Anweisungen zum Hinzufügen von APT-Paketen, npm-Tools, pip-Tools und Binär-Downloads.

VS Code-Erweiterungen

Erweiterungen werden in .devcontainer/devcontainer.json unter customizations.vscode.extensions konfiguriert und automatisch beim Öffnen in VS Code installiert.

Datenpersistenz

Alle Daten befinden sich in benannten Volumes — es werden keine Host-Verzeichnisse eingebunden:

Volume	Einhängepunkt	Inhalt
workspace	/workspace	Ihre geklonten Repositories und Projektdateien
home	/home/vscode	Shell-Verlauf, Tool-Konfigurationen, Caches, SSH-Schlüssel

Docker

Beide bleiben über Container-Neustarts und Rebuilds erhalten. Führen Sie docker compose pull aus, um das neueste vorgefertigte Image vor dem Neustart zu laden.

Aktion	Daten
docker compose down	Erhalten
docker compose down -v	Gelöscht

Podman

Beide bleiben über Container-Neustarts und Rebuilds erhalten. Führen Sie podman-compose pull aus, um das neueste vorgefertigte Image vor dem Neustart zu laden.

Aktion	Daten
podman-compose down	Erhalten
podman-compose down -v	Gelöscht

Port-Zuordnung

Host	Container	Dienst
127.0.0.1:${NOVNC_HOST_PORT:-6080}	6080	noVNC Remote-Anzeige (nur localhost, überschreibbar mit NOVNC_HOST_PORT)

Ports sind an 127.0.0.1 gebunden, sodass sie nur von Ihrem Rechner aus zugänglich sind, nicht aus dem Netzwerk.