31| Variable | Beschreibung |31| Variable | Beschreibung |
32| :- | :- |32| :- | :- |
33| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-JWT, mit dem Präfix `sk-ant-cc-`. Sein `act`-Anspruch identifiziert den Sitzungsersteller, mit der E-Mail des Erstellers, wenn die erstellende Oberfläche diese aufgezeichnet hat. Der Wert ist das Token zum Zeitpunkt des Spawning; Aktualisierungen kommen über stdin des Kindes an, daher sieht ein Wrapper nur den Anfangswert. Siehe [Sitzungsidentität überprüfen](/docs/de/self-hosted-environments-identity). |33| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-JWT, mit dem Präfix `sk-ant-cc-`. Sein `act`-Anspruch identifiziert den Sitzungsersteller, mit der E-Mail des Erstellers, wenn die erstellende Oberfläche diese aufgezeichnet hat. Der Wert ist das Token zum Zeitpunkt des Spawning; Aktualisierungen kommen über stdin des Kindes an, daher sieht ein Wrapper nur den Anfangswert. Siehe [Sitzungsidentität überprüfen](/docs/de/self-hosted-environments-identity). |
34| `CCR_SESSION_ACCOUNT_EMAIL` | Die E-Mail des Sitzungserstellers, vom Runner aus dem `act.email`-Anspruch des Tokens ohne Signaturüberprüfung vorab extrahiert. Geeignet für Beschriftung, wie Commit-Trailer. Wenn die E-Mail die Ausstellung von Anmeldedaten steuert, überprüfen Sie das Token und lesen Sie den Anspruch stattdessen daraus; siehe [Anmeldedaten mit Bereich auf den Sitzungsersteller bereitstellen](#provision-credentials-scoped-to-the-session-creator). Nicht gesetzt, wenn das Token keine Ersteller-E-Mail enthält. Behandeln Sie als personenbezogene Informationen. |34| `CCR_SESSION_ACCOUNT_EMAIL` | Die E-Mail des Sitzungserstellers, vom Runner aus dem `act.email`-Anspruch des Tokens ohne Signaturüberprüfung vorab extrahiert. Geeignet für Beschriftung, wie Commit-Trailer. Wenn die E-Mail die Ausstellung von Anmeldedaten steuert, überprüfen Sie das Token und lesen Sie den Anspruch stattdessen daraus. Siehe [Anmeldedaten mit Bereich auf den Sitzungsersteller bereitstellen](#provision-credentials-scoped-to-the-session-creator). Nicht gesetzt, wenn das Token keine Ersteller-E-Mail enthält, zum Beispiel in Sitzungen, die die Service-Identität Ihrer Organisation erstellt. Behandeln Sie als personenbezogene Informationen. |
35| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app`, `ios`, `claude_code_cli` oder `scheduled_trigger`. Anthropic zeichnet den Wert einmal bei der Sitzungserstellung auf, daher sehen der Wrapper und jeder Lifecycle-Hook denselben Wert. Verwenden Sie ihn nur für Adoptionsanalysen und Beschriftung, nicht als Autorisierungssignal. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat, daher referenzieren Sie sie als `${CLAUDE_RUNNER_CLIENT_PLATFORM:-}` unter `set -u`. Erfordert Claude Code v2.1.229 oder später. |35| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app`, `ios`, `claude_code_cli` oder `scheduled_trigger`. Anthropic zeichnet den Wert einmal bei der Sitzungserstellung auf, daher sehen der Wrapper und jeder Lifecycle-Hook denselben Wert. Verwenden Sie ihn nur für Adoptionsanalysen und Beschriftung, nicht als Autorisierungssignal. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat. Erfordert Claude Code v2.1.229 oder später. |
36| `CLAUDE_RUNNER_CLAUDE_BIN` | Absoluter Pfad zur eigenen Claude Code-Binärdatei des Runners. Beenden Sie Ihren Wrapper mit `exec "$CLAUDE_RUNNER_CLAUDE_BIN" "$@"`, um an die angeheftete Binärdatei zu übergeben, ohne einen Installationspfad hartcodieren zu müssen. |36| `CLAUDE_RUNNER_CLAUDE_BIN` | Absoluter Pfad zur eigenen Claude Code-Binärdatei des Runners. Beenden Sie Ihren Wrapper mit `exec "$CLAUDE_RUNNER_CLAUDE_BIN" "$@"`, um an die angeheftete Binärdatei zu übergeben, ohne einen Installationspfad hartcodieren zu müssen. |
37| `CLAUDE_CODE_REMOTE_SESSION_ID` | Sitzungs-ID in der getaggten Form `cse_...`. Dies ist dieselbe Sitzung, die die [Lifecycle-Hooks](#lifecycle-hooks) als `CLAUDE_RUNNER_SESSION_ID` in der Form `session_...` sehen; die UUID-Variablen stimmen über beide überein, und das Ersetzen des Präfixes `cse_` durch `session_` ergibt die in der Sitzungs-URL angezeigte ID. |37| `CLAUDE_CODE_REMOTE_SESSION_ID` | Sitzungs-ID in der getaggten Form `cse_...`. Dies ist dieselbe Sitzung, die die [Lifecycle-Hooks](#lifecycle-hooks) als `CLAUDE_RUNNER_SESSION_ID` in der Form `session_...` sehen; die UUID-Variablen stimmen über beide überein, und das Ersetzen des Präfixes `cse_` durch `session_` ergibt die in der Sitzungs-URL angezeigte ID. |
38| `CLAUDE_CODE_REMOTE_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form, für Systeme, die auf UUIDs basieren. |38| `CLAUDE_CODE_REMOTE_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form, für Systeme, die auf UUIDs basieren. |
39| `CLAUDE_CODE_REMOTE_SLACK_THREAD_URL` | Für eine [Claude Tag](https://claude.com/docs/claude-tag/overview)-Sitzung, die zu einem Slack-Thread gehört, der Link zu diesem Thread. Für andere Sitzungen nicht gesetzt; kann auch bei einer Thread-Sitzung nicht gesetzt sein. |
40| `CLAUDE_CODE_REMOTE_SLACK_THREAD_TS` | Für eine Claude Tag-Sitzung, die zu einem Slack-Thread gehört, der Slack-Zeitstempel dieses Threads, etwa `1700000000.000100`. Kann nicht gesetzt sein und kann gesetzt sein, wenn `CLAUDE_CODE_REMOTE_SLACK_THREAD_URL` es nicht ist; prüfen Sie daher jede Variable einzeln. |
39| `CLAUDE_SESSION_INGRESS_TOKEN_FILE` | Absoluter Pfad zu einer pro-Sitzungs-Datei, die das aktuelle Sitzungs-JWT enthält, das über Token-Aktualisierungen hinweg aktuell gehalten wird. Shell-Unterprozesse lesen es für ihren `Authorization`-Header beim Herunterladen von Anhängen, die der Benutzer zur Sitzung hinzugefügt hat. `exec` bewahrt die Variable automatisch; ein Wrapper, der die Umgebung des Kindes neu erstellt, muss die Variable übertragen, oder Anhang-Downloads funktionieren stillschweigend nicht mehr. |41| `CLAUDE_SESSION_INGRESS_TOKEN_FILE` | Absoluter Pfad zu einer pro-Sitzungs-Datei, die das aktuelle Sitzungs-JWT enthält, das über Token-Aktualisierungen hinweg aktuell gehalten wird. Shell-Unterprozesse lesen es für ihren `Authorization`-Header beim Herunterladen von Anhängen, die der Benutzer zur Sitzung hinzugefügt hat. `exec` bewahrt die Variable automatisch; ein Wrapper, der die Umgebung des Kindes neu erstellt, muss die Variable übertragen, oder Anhang-Downloads funktionieren stillschweigend nicht mehr. |
40| `CLAUDE_CONFIG_DIR` | Pro-Sitzungs-Claude-Konfigurationsverzeichnis, geschrieben beim Sitzungsstart aus dem Snapshot der Konfiguration des Runner-Hosts, den der Runner beim Startup erfasst; siehe [Berechtigungen und Tool-Genehmigung](#permissions-and-tool-approval). Schreibvorgänge hier sind auf diese Sitzung isoliert. Das Verzeichnis bleibt unter `<base-dir>/_sessions/` nach dem Sitzungsende, es sei denn, Sie starten den Runner mit [`--remove-session-state`](/docs/de/self-hosted-environments-reference#runner-cli-flags); siehe [Einen vorgewärmten Checkout wiederverwenden](/docs/de/self-hosted-environments-deploy#reuse-a-pre-warmed-checkout). |42| `CLAUDE_CONFIG_DIR` | Pro-Sitzungs-Claude-Konfigurationsverzeichnis, geschrieben beim Sitzungsstart aus dem Snapshot der Konfiguration des Runner-Hosts, den der Runner beim Startup erfasst; siehe [Berechtigungen und Tool-Genehmigung](#permissions-and-tool-approval). Schreibvorgänge hier sind auf diese Sitzung isoliert. Das Verzeichnis bleibt unter `<base-dir>/_sessions/` nach dem Sitzungsende, es sei denn, Sie starten den Runner mit [`--remove-session-state`](/docs/de/self-hosted-environments-reference#runner-cli-flags); siehe [Einen vorgewärmten Checkout wiederverwenden](/docs/de/self-hosted-environments-deploy#reuse-a-pre-warmed-checkout). |
41| `ANTHROPIC_BASE_URL` | Die API-Basis-URL, die das Kind verwendet, bereitgestellt von der Kontrollebene pro Sitzung und normalerweise `https://api.anthropic.com`. Überschreiben Sie sie nicht: Die Inferenz-Anmeldedaten der Sitzung sind ein von Anthropic ausgegebenes OAuth-Token, das andere Anbieter nicht akzeptieren. |43| `ANTHROPIC_BASE_URL` | Die API-Basis-URL, die das Kind verwendet, bereitgestellt von der Kontrollebene pro Sitzung und normalerweise `https://api.anthropic.com`. Überschreiben Sie sie nicht: Die Inferenz-Anmeldedaten der Sitzung sind ein von Anthropic ausgegebenes OAuth-Token, das andere Anbieter nicht akzeptieren. |
43 45
44Der Wrapper erbt auch den Rest der verwalteten Umgebung des Kindes, einschließlich aller vom Server bereitgestellten Umgebungsvariablen. `exec` propagiert alles automatisch; wenn Ihr Wrapper das Kind auf andere Weise startet, leiten Sie die vollständige Umgebung weiter.46Der Wrapper erbt auch den Rest der verwalteten Umgebung des Kindes, einschließlich aller vom Server bereitgestellten Umgebungsvariablen. `exec` propagiert alles automatisch; wenn Ihr Wrapper das Kind auf andere Weise startet, leiten Sie die vollständige Umgebung weiter.
45 47
48`CLAUDE_CODE_REMOTE_SLACK_THREAD_URL` und `CLAUDE_CODE_REMOTE_SLACK_THREAD_TS` erreichen Ihren Wrapper oder [`command`-Hook](#command). Sie erreichen auch das, was die Sitzung ausführt, etwa Shell-Befehle, Git-Hooks und Claude Code-Hooks. Die Hooks `checkout`, `post-session` und `spawn-runner` erhalten sie nicht.
49
50<h3 id="give-a-default-to-variables-that-can-be-unset">
51 Variablen, die nicht gesetzt sein können, mit einem Standardwert versehen
52</h3>
53
54`CCR_SESSION_ACCOUNT_EMAIL`, `CLAUDE_RUNNER_CLIENT_PLATFORM`, `CLAUDE_CODE_REMOTE_SLACK_THREAD_URL` und `CLAUDE_CODE_REMOTE_SLACK_THREAD_TS` können jeweils nicht gesetzt sein. Wenn Ihr Skript `set -u` verwendet, bricht Bash mit `unbound variable` ab, sobald es eine nicht gesetzte Variable expandiert. Expandieren Sie sie daher mit einem Standardwert, etwa `${CCR_SESSION_ACCOUNT_EMAIL:-}`.
55
56Treffen Sie überall dort, wo eine Shell den Slack-Thread-Link expandiert, diese Vorkehrungen:
57
58* **Setzen Sie ihn in Anführungszeichen**: Der Link kann Zeichen enthalten, auf die eine Shell reagiert, etwa `?` und `&`. Setzen Sie die Variable daher in Anführungszeichen, wie in `"${CLAUDE_CODE_REMOTE_SLACK_THREAD_URL:-}"`.
59* **Halten Sie seinen Wert aus `eval`- und `sh -c`-Zeichenfolgen heraus**: Setzen Sie seinen Wert nicht in eine Zeichenfolge ein, die `eval` oder `sh -c` ausführt, auch nicht in Anführungszeichen. Lassen Sie diese Zeichenfolge stattdessen auf die Variable verweisen.
60
46<h3 id="keep-stdin-and-file-descriptor-3-attached">61<h3 id="keep-stdin-and-file-descriptor-3-attached">
47 Halten Sie stdin und Dateideskriptor 3 angehängt62 Halten Sie stdin und Dateideskriptor 3 angehängt
48</h3>63</h3>
49 64
50Stdin des Kindes ist der Steuerkanal des Runners. Token-Rotationen und Sitzungsend-Signale kommen darauf an. Der Runner öffnet auch eine Pipe auf Dateideskriptor 3 und liest die Aktivitätssignale des Kindes daraus, um Idle- und Startup-Timeouts zu steuern. Ein einfaches `exec "$CLAUDE_RUNNER_CLAUDE_BIN" "$@"` bewahrt beide automatisch.65Stdin des Kindes ist der Steuerkanal des Runners. Token-Rotationen und Sitzungsend-Signale kommen darauf an. Der Runner öffnet auch eine Pipe auf Dateideskriptor 3 und liest die Aktivitätssignale des Kindes daraus, um Idle- und Startup-Timeouts zu steuern. Ein einfaches `exec "$CLAUDE_RUNNER_CLAUDE_BIN" "$@"` bewahrt beide automatisch.
51 66
52Wenn Ihr Wrapper das Kind mit einem bloßen `&` in den Hintergrund versetzt, trennt es stdin des Kindes: Die Sitzung sieht gesund aus, bis die Lebensdauer des anfänglichen OAuth-Tokens von etwa 30 Minuten abläuft, dann schlagen alle API-Aufrufe mit `401 authentication_error` fehl. Wenn Ihr Wrapper das Kind in den Hintergrund versetzen muss, zum Beispiel um eine Teardown-Falle am Leben zu erhalten, speichern Sie stdin auf Dateideskriptor 4 oder höher und hängen Sie ihn explizit wieder an:67Wenn Ihr Wrapper das Kind mit einem bloßen `&` in den Hintergrund versetzt, trennt es stdin des Kindes. Die Sitzung sieht gesund aus, bis die Lebensdauer des anfänglichen OAuth-Tokens von etwa 30 Minuten abläuft, und dann schlägt jeder API-Aufruf, der das Token verwendet, mit `401 authentication_error` fehl. Wenn Ihr Wrapper das Kind in den Hintergrund versetzen muss, zum Beispiel um eine Teardown-Falle am Leben zu erhalten, speichern Sie stdin auf Dateideskriptor 4 oder höher und hängen Sie ihn explizit wieder an:
53 68
54```bash theme={null}69```bash theme={null}
55exec 4<&070exec 4<&0
59wait "$CHILD"74wait "$CHILD"
60```75```
61 76
62Schließen oder verwenden Sie Dateideskriptor 3 im Wrapper nicht erneut. Das Umleiten von stdout und stderr des Kindes ist in Ordnung.77Sie können stdout des Kindes umleiten. Halten Sie Dateideskriptor 3 und stderr mit dem Runner verbunden:
78
79* **Dateideskriptor 3**: überträgt die Aktivitätssignale des Kindes an den Runner. Schließen oder verwenden Sie ihn im Wrapper nicht erneut.
80* **stderr**: Wenn der Wrapper oder das Kind mit einem Wert ungleich Null endet, sendet der Runner die letzten Zeilen von stderr an die Sitzung und gibt sie in seinem eigenen Log aus. Der Benutzer der Sitzung sieht diese Zeilen, geben Sie daher keine Geheimnisse auf stderr aus und entfernen Sie `set -x`, bevor Sie den Wrapper bereitstellen. Wenn Sie stderr umleiten, laufen Sitzungen weiterhin, aber der Runner meldet einen Fehler nur mit dem Exit-Code.
63 81
64<h3 id="pass-the-system-prompt-flags-through">82<h3 id="pass-the-system-prompt-flags-through">
65 System-Prompt-Flags durchreichen83 System-Prompt-Flags durchreichen
108 checkout126 checkout
109</h3>127</h3>
110 128
111Wird einmal pro Repository anstelle des integrierten Klons und Abrufs des Runners ausgeführt. Verwenden Sie den Hook, um von einem Read-Through-Mirror zu klonen, einen Arbeitsbaum aus einem Archiv zu seeden oder Pro-Sitzungs-Git-Authentifizierung anzuwenden. Der Runner setzt diese Variablen und kann weitere `CLAUDE_RUNNER_`-Variablen setzen, die die Tabelle nicht aufführt:129Wird einmal pro Repository anstelle des integrierten Klons und Abrufs des Runners ausgeführt. Verwenden Sie den Hook, um von einem Read-Through-Mirror zu klonen, den Sie über HTTPS oder SSH erreichen, einen Working Tree aus einem Archiv zu seeden oder Pro-Sitzungs-Git-Authentifizierung anzuwenden. Der Runner setzt diese Variablen und kann weitere `CLAUDE_RUNNER_`-Variablen setzen, die die Tabelle nicht aufführt:
112 130
113| Variable | Beschreibung |131| Variable | Beschreibung |
114| :- | :- |132| :- | :- |
115| `CLAUDE_RUNNER_REPO_URL` | Repository-URL zum Klonen, nachdem alle `--git-host-rewrite` und `--git-ssh-rewrite` angewendet wurden |133| `CLAUDE_RUNNER_REPO_URL` | Repository-URL zum Klonen, nachdem alle `--git-host-rewrite` und `--git-ssh-rewrite` angewendet wurden |
116| `CLAUDE_RUNNER_REPO_REF` | Revision zum Auschecken: Branch, Tag oder Commit-SHA, wie die Sitzung sie angefordert hat. Leer bedeutet den Standard-Branch des Repositorys. |134| `CLAUDE_RUNNER_REPO_REF` | Revision zum Auschecken, wie die Sitzung sie angefordert hat: ein Branch, Tag, Commit-SHA oder vollständiger Referenzname wie `refs/pull/<number>/head`. Leer bedeutet den Standard-Branch des Repositorys. |
117| `CLAUDE_RUNNER_CHECKOUT_PATH` | Absoluter Pfad, wo der Arbeitsbaum hinterlassen werden muss |135| `CLAUDE_RUNNER_CHECKOUT_PATH` | Absoluter Pfad, wo der Arbeitsbaum hinterlassen werden muss |
118| `CLAUDE_RUNNER_SESSION_ID` | Sitzungs-ID in der getaggten Form `session_...`, für Protokollierung und Korrelation |136| `CLAUDE_RUNNER_SESSION_ID` | Sitzungs-ID in der getaggten Form `session_...`, für Protokollierung und Korrelation |
119| `CLAUDE_RUNNER_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form |137| `CLAUDE_RUNNER_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form |
120| `CLAUDE_RUNNER_API_BASE_URL` | Anthropic-API-Basis-URL für Sitzungs-bezogene Aufrufe |138| `CLAUDE_RUNNER_API_BASE_URL` | Anthropic-API-Basis-URL für Sitzungs-bezogene Aufrufe |
121| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app` oder `ios`. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat. |139| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app` oder `ios`. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat, referenzieren Sie sie daher unter `set -u` als `${CLAUDE_RUNNER_CLIENT_PLATFORM:-}`. Erfordert Claude Code v2.1.229 oder später. |
122| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-Zugangstoken für Sitzungs-bezogene API-Aufrufe |140| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-Zugangstoken für Sitzungs-bezogene API-Aufrufe |
123| `GIT_CONFIG_COUNT`, `GIT_CONFIG_KEY_n`, `GIT_CONFIG_VALUE_n` | Git-Einstellungen, die der Runner für das Git festlegt, das Ihr Hook ausführt. [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks) beschreibt sie. Erfordert Claude Code v2.1.280 oder später. |141| `GIT_CONFIG_COUNT`, `GIT_CONFIG_KEY_n`, `GIT_CONFIG_VALUE_n` | Git-Einstellungen, die der Runner für das Git festlegt, das Ihr Hook ausführt. [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks) beschreibt sie. Erfordert Claude Code v2.1.280 oder später. |
124 142
125Das Skript muss einen Arbeitsbaum bei `CLAUDE_RUNNER_CHECKOUT_PATH` hinterlassen, der bei der angeforderten Revision ausgecheckt ist. Detached HEAD ist in Ordnung; der Runner erstellt den Arbeitsbranch der Sitzung darauf. Der Runner überprüft danach, ob der Pfad eine `.git` enthält; wenn Ihr Hook eine Nicht-Git-Quelle wie Perforce oder ein entpacktes Tarball materialisiert, setzen Sie `CLAUDE_RUNNER_SKIP_GIT_VERIFY=1` in der Umgebung des Runners, um diese Überprüfung zu überspringen. Git-basierte Flows wie Arbeitsbranch-Erstellung und Pushing-Ergebnisse erfordern einen Git-Checkout, daher exportieren Sie Ergebnisse aus Nicht-Git-Bäumen mit einem [`post-session`-Hook](#post-session).143Das Skript muss einen Working Tree bei `CLAUDE_RUNNER_CHECKOUT_PATH` hinterlassen, der bei der angeforderten Revision ausgecheckt ist. Ein Detached HEAD funktioniert, weil der Runner den Arbeits-Branch der Sitzung darauf erstellt.
126 144
127Der Runner übergibt keine Git-Anmeldedaten an den Hook. Stattdessen prägen Sie eine Pro-Sitzungs-Klone-Anmeldedaten aus der Identität der Sitzung: Überprüfen Sie `CLAUDE_CODE_SESSION_ACCESS_TOKEN` mit einer Standard-JWT-Bibliothek gegen den JWKS-Endpunkt unter `CLAUDE_RUNNER_API_BASE_URL`, wie in [Token von Ihrem Dienst überprüfen](/docs/de/self-hosted-environments-identity#verify-the-token-from-your-service) beschrieben, dann lassen Sie Ihren Anmeldedatendienst eine kurzlebige Klone-Anmeldedaten für die Identität im `act`-Anspruch des Tokens ausstellen. `CLAUDE_RUNNER_CLAUDE_BIN` ist nicht in der Checkout-Hook-Umgebung gesetzt, daher ist der Unterbefehl `decode-token` hier nicht verfügbar. Das Zurückfallen auf die Git-Authentifizierung, die der Host bereits hat, wie einen SSH-Agent, Anmeldedaten-Helper oder `.netrc`, ist auch eine Option.145Nachdem Ihr Hook zurückkehrt, überprüft der Runner, ob `CLAUDE_RUNNER_CHECKOUT_PATH` eine `.git` enthält. Wenn Ihr Hook eine Nicht-Git-Quelle wie Perforce oder ein entpacktes Tarball materialisiert, setzen Sie `CLAUDE_RUNNER_SKIP_GIT_VERIFY=1` in der Umgebung des Runners, um diese Überprüfung zu überspringen. Git-basierte Abläufe wie die Erstellung des Arbeits-Branches und das Pushen von Ergebnissen erfordern einen Git-Checkout, daher exportieren Sie Ergebnisse aus Nicht-Git-Bäumen mit einem [`post-session`-Hook](#post-session).
128 146
129Wenn der Hook mit ungleich Null endet oder mit 0 endet, ohne einen verwendbaren Checkout hinterlassen zu haben, hängt das, was der Runner tut, vom Repository ab:147<h4 id="get-git-credentials-in-the-hook">
148 Git-Anmeldedaten im Hook beziehen
149</h4>
130 150
131* **Ein Repository, zu dem die Sitzung Ergebnisse pusht**: Der Runner schlägt die Sitzung fehl, und bei einem Nicht-Null-Exit zeigt er das Ende des Stderr des Skripts dem Benutzer an.151Der Runner übergibt keine Git-Anmeldedaten an den Hook. Auch der Unterbefehl `decode-token` ist hier nicht verfügbar, weil `CLAUDE_RUNNER_CLAUDE_BIN` in der Checkout-Hook-Umgebung nicht gesetzt ist. Erzeugen Sie stattdessen Pro-Sitzungs-Klon-Anmeldedaten aus der Identität der Sitzung, oder greifen Sie auf die eigene Git-Authentifizierung des Hosts zurück:
132* **Ein Repository, das die Sitzung nur liest**, wie ein Repository, das zu einer laufenden Sitzung hinzugefügt wird: Der Runner protokolliert eine `[runner:warn]`-Zeile mit dem Fehlerdetail, postet einen `Skipped`-Schritt zur Sitzung, entfernt, was der Hook bei dem Checkout-Pfad hinterlassen hat, und fährt mit den verbleibenden Repositories fort. Wenn der Runner den Pfad nicht sofort entfernen kann, versucht er die Entfernung beim Sitzungsende erneut. Wenn das Überspringen die Sitzung ohne Repository verlässt, schlägt der Runner die Sitzung trotzdem fehl.
133 152
134Vor v2.1.228 schlägt der Runner die Sitzung bei einem Hook-Fehler für jedes Repository fehl, daher schlägt ein Read-Only-Repository, das der Hook nicht bedienen konnte, die Sitzung erneut auf jedem frischen Runner fehl, auf dem die Sitzung fortgesetzt wurde.153* **Pro-Sitzungs-Klon-Anmeldedaten**: Überprüfen Sie `CLAUDE_CODE_SESSION_ACCESS_TOKEN` mit einer Standard-JWT-Bibliothek gegen den JWKS-Endpunkt unter `CLAUDE_RUNNER_API_BASE_URL`, wie in [Token von Ihrem Dienst überprüfen](/docs/de/self-hosted-environments-identity#verify-the-token-from-your-service) beschrieben. Lassen Sie dann Ihren Anmeldedatendienst kurzlebige Klon-Anmeldedaten für die Identität im `act`-Claim des Tokens ausstellen. Verknüpfen Sie diese Anmeldedaten mit `act.sub`, und setzen Sie `act.email` nicht voraus.
154* **Git-Authentifizierung des Hosts**: Verwenden Sie die Git-Authentifizierung, die der Host bereits hat, wie einen SSH-Agent, einen Anmeldedaten-Helper oder `.netrc`.
135 155
136Der Runner entfernt den Checkout-Pfad nach dem Sitzungsende.156<h4 id="when-the-hook-fails">
157 Wenn der Hook fehlschlägt
158</h4>
159
160Der Hook schlägt fehl, wenn er mit einem Wert ungleich Null endet oder mit 0 endet, ohne einen verwendbaren Checkout hinterlassen zu haben:
161
162* **Ein Repository, zu dem die Sitzung Ergebnisse pusht**: Der Runner schlägt die Sitzung fehl, und bei einem Nicht-Null-Exit zeigt er das Ende des Stderr des Skripts dem Benutzer an.
163* **Ein Repository, aus dem die Sitzung nur liest**, wie ein Repository, das zu einer laufenden Sitzung hinzugefügt wird: Der Runner protokolliert eine `[runner:warn]`-Zeile mit dem Fehlerdetail, postet einen `Skipped`-Schritt an die Sitzung, entfernt, was der Hook am Checkout-Pfad hinterlassen hat, und fährt mit den verbleibenden Repositorys fort. Wenn die Sitzung durch das Überspringen überhaupt kein Repository mehr hat, lässt der Runner die Sitzung trotzdem fehlschlagen.
164
165Wenn der Hook erfolgreich ist, entfernt der Runner den Checkout-Pfad nach dem Sitzungsende.
137 166
138<h3 id="post-session">167<h3 id="post-session">
139 post-session168 post-session
151| `CLAUDE_RUNNER_WORKSPACE_PATHS` | Doppelpunkt-getrennte absolute Pfade der Arbeitsbäume der Sitzung. Leer für Null-Repo-Sitzungen. |180| `CLAUDE_RUNNER_WORKSPACE_PATHS` | Doppelpunkt-getrennte absolute Pfade der Arbeitsbäume der Sitzung. Leer für Null-Repo-Sitzungen. |
152| `CLAUDE_RUNNER_DEBUG_LOG_PATH` | Pfad zum Debug-Protokoll der Sitzung, noch auf der Festplatte während der Hook-Ausführung |181| `CLAUDE_RUNNER_DEBUG_LOG_PATH` | Pfad zum Debug-Protokoll der Sitzung, noch auf der Festplatte während der Hook-Ausführung |
153| `CLAUDE_RUNNER_API_BASE_URL` | Anthropic-API-Basis-URL für Sitzungs-bezogene Aufrufe |182| `CLAUDE_RUNNER_API_BASE_URL` | Anthropic-API-Basis-URL für Sitzungs-bezogene Aufrufe |
154| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app` oder `ios`. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat. Erfordert Claude Code v2.1.229 oder später. |183| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app` oder `ios`. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat, referenzieren Sie sie daher unter `set -u` als `${CLAUDE_RUNNER_CLIENT_PLATFORM:-}`. Erfordert Claude Code v2.1.229 oder später. |
155| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-Zugangstoken für Sitzungs-bezogene API-Aufrufe |184| `CLAUDE_CODE_SESSION_ACCESS_TOKEN` | Das Sitzungs-Zugangstoken für Sitzungs-bezogene API-Aufrufe |
156| `GIT_CONFIG_COUNT`, `GIT_CONFIG_KEY_n`, `GIT_CONFIG_VALUE_n` | Git-Einstellungen, die der Runner für das Git festlegt, das Ihr Hook ausführt. [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks) beschreibt sie. Erfordert Claude Code v2.1.280 oder später. |185| `GIT_CONFIG_COUNT`, `GIT_CONFIG_KEY_n`, `GIT_CONFIG_VALUE_n` | Git-Einstellungen, die der Runner für das Git festlegt, das Ihr Hook ausführt. [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks) beschreibt sie. Erfordert Claude Code v2.1.280 oder später. |
157 186
158`CLAUDE_RUNNER_EXIT_REASON` nimmt einen von vier Werten an:187`CLAUDE_RUNNER_EXIT_REASON` nimmt einen von vier Werten an:
159 188
160* `completed`: die Sitzung endete sauber. Der Claude Code-Prozess wurde normal beendet, oder die Sitzung wurde archiviert oder gelöscht, während sie noch lief.189* `completed`: Die Sitzung endete sauber. Der Claude Code-Prozess wurde normal beendet oder hat sich selbst beendet, nachdem die Sitzung archiviert oder gelöscht wurde.
161* `failed`: Der Claude Code-Prozess ist abgestürzt, oder das Setup ist nach dem Start fehlgeschlagen.190* `failed`: Der Claude Code-Prozess ist abgestürzt, oder das Setup ist nach dem Start fehlgeschlagen.
162* `interrupted`: Der Runner hat die Sitzung gestoppt. Er gab die Sitzung frei, um den Slot freizugeben, die Sitzung ist beim Startup abgelaufen, der Server hat die Sitzung von diesem Runner verschoben, der Runner wurde geleert, oder die Sitzung hat sein [`--kill-session-after-min`](/docs/de/self-hosted-environments-reference#runner-cli-flags)-Limit überschritten.191* `interrupted`: Der Runner hat die Sitzung gestoppt, in einem dieser Fälle:
192 * Der Runner hat die Sitzung freigegeben, um den Slot freizumachen.
193 * Die Sitzung ist beim Start in ein Timeout gelaufen.
194 * Der Server hat die Sitzung von diesem Runner wegverschoben.
195 * Die Abfrage des Runners hat eine Archivierung oder Löschung bemerkt, bevor der Prozess beendet wurde.
196 * Der Runner wurde geleert.
197 * Die Sitzung hat ihr [`--kill-session-after-min`](/docs/de/self-hosted-environments-reference#runner-cli-flags)-Limit überschritten.
163* `abandoned`: reserviert für eine Sitzung, die ein anderer Runner beansprucht hat. Der Hook wird derzeit in diesem Fall nicht ausgelöst.198* `abandoned`: reserviert für eine Sitzung, die ein anderer Runner beansprucht hat. Der Hook wird derzeit in diesem Fall nicht ausgelöst.
164 199
165Die [Sitzungs-Lifecycle-Zähler](/docs/de/self-hosted-environments-reference#session-lifecycle-counter-semantics) zählen eine Freigabe, ein Startup-Timeout und einen Server-Umzug als `completed` statt `interrupted`, weil der Runner den Slot sauber zurückgegeben hat. Erwarten Sie diesen Unterschied, wenn Sie Hook-Quittungen mit den Zählern vergleichen.200Wenn Sie Hook-Quittungen mit den [Sitzungs-Lifecycle-Zählern](/docs/de/self-hosted-environments-reference#session-lifecycle-counter-semantics) vergleichen, rechnen Sie damit, dass einige `interrupted`-Quittungen dort als `completed` gezählt werden. Die Zähler zählen eine Freigabe, ein Start-Timeout, eine Verschiebung durch den Server sowie eine Archivierung oder Löschung, die die Abfrage des Runners zuerst bemerkt hat, als `completed`, weil der Runner den Slot sauber zurückgegeben hat.
166 201
167Der Exit-Status des Hooks beeinflusst niemals das Sitzungsergebnis; ein Fehler wird protokolliert und ignoriert. Der Runner wartet bis zu `--post-session-hook-timeout-sec`, standardmäßig 60 Sekunden, bei jedem Sitzungsende einschließlich Runner-Shutdown. Dieses Beispiel speichert ungespeicherte Arbeit in einem Rettungs-Branch:202Der Exit-Status des Hooks beeinflusst niemals das Sitzungsergebnis; ein Fehler wird protokolliert und ignoriert. Der Runner wartet bis zu `--post-session-hook-timeout-sec`, standardmäßig 60 Sekunden, bei jedem Sitzungsende einschließlich Runner-Shutdown. Dieses Beispiel speichert ungespeicherte Arbeit in einem Rettungs-Branch:
168 203
169```bash theme={null}204```bash theme={null}
170#!/usr/bin/env bash205#!/usr/bin/env bash
171set -u206set -u
207export GIT_ALLOW_PROTOCOL=${GIT_ALLOW_PROTOCOL:-https:http:ssh}
172IFS=':'208IFS=':'
173# -c-Überschreibungen schlagen Repo-lokale Einstellungen und verhindern, dass von der Sitzung209# -c-Überschreibungen schlagen Repo-lokale Einstellungen und verhindern, dass von der Sitzung
174# geschriebene fsmonitor-, Hook-Pfad- und gpg-program-Konfiguration Code mit den Berechtigungen210# geschriebene fsmonitor-, Hook-Pfad- und gpg-program-Konfiguration Code mit den Berechtigungen
175# des Hooks ausführt. -c commit.gpgsign=false lässt diese Rettungs-Commits unter211# des Hooks ausführt. -c commit.gpgsign=false lässt diese Rettungs-Commits unter
176# --configure-git außerdem unsigniert.212# --configure-git außerdem unsigniert.
177# Repo-lokale credential.helper und pushurl gelten weiterhin, und auf einem Runner213# Repo-lokale credential.helper und pushurl gelten weiterhin, und auf einem Runner
178# vor v2.1.280 auch core.sshCommand; wenn der Hook Anmeldedaten hält, die die214# vor v2.1.280 auch core.sshCommand; lesen Sie die Notiz unter dem Skript,
179# Sitzung nicht hatte, siehe die Notiz unter dem Skript.215# bevor Sie diesem Push Anmeldedaten geben.
180g() { git -c core.fsmonitor=false -c core.hooksPath=/dev/null \216g() { git -c core.fsmonitor=false -c core.hooksPath=/dev/null \
181 -c commit.gpgsign=false "$@"; }217 -c commit.gpgsign=false "$@"; }
182for ws in $CLAUDE_RUNNER_WORKSPACE_PATHS; do218for ws in $CLAUDE_RUNNER_WORKSPACE_PATHS; do
188done224done
189```225```
190 226
191Der Hook pusht mit den Git-Anmeldedaten, die in seiner eigenen Umgebung auf dem Runner-Host verfügbar sind. Unter der [Keine-Anmeldedaten-im-Image-Haltung](/docs/de/self-hosted-environments-deploy#configure-git), einschließlich wenn der integrierte Klon durch den Anthropic-Git-Proxy geht, gibt es keine, daher erzeugen Sie kurzlebige Push-Anmeldedaten innerhalb des Hooks, bevor Sie pushen: Tauschen Sie das Sitzungs-Token, das der Hook in `CLAUDE_CODE_SESSION_ACCESS_TOKEN` erhält, mit Ihrem eigenen Token-Dienst aus, und überprüfen Sie es, wie [Sitzungsidentität überprüfen](/docs/de/self-hosted-environments-identity) beschreibt. Wenn der Hook Anmeldedaten hält, die die Sitzung nicht hatte, ersetzen Sie `origin` durch eine vom Operator bereitgestellte URL und übergeben Sie `-c credential.helper=` plus Ihren eigenen Helper. [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks) beschreibt, was von der Sitzung geschriebene Konfiguration weiterhin beeinflussen kann.227Die Zeile `GIT_ALLOW_PROTOCOL` im Skript beschränkt Git auf HTTPS-, HTTP- und SSH-Remotes. Wenn die Umgebung des Runners bereits eine eigene, nicht leere `GIT_ALLOW_PROTOCOL`-Liste setzt, behält das Skript diese Liste bei.
228
229Der Hook pusht mit den Git-Anmeldedaten, die in seiner eigenen Umgebung auf dem Runner-Host verfügbar sind. Unter der [Keine-Anmeldedaten-im-Image-Haltung](/docs/de/self-hosted-environments-deploy#configure-git), einschließlich wenn der integrierte Klon durch den Anthropic-Git-Proxy geht, gibt es keine, daher erzeugen Sie kurzlebige Push-Anmeldedaten innerhalb des Hooks, bevor Sie pushen: Tauschen Sie das Sitzungs-Token, das der Hook in `CLAUDE_CODE_SESSION_ACCESS_TOKEN` erhält, mit Ihrem eigenen Token-Dienst aus, und überprüfen Sie es, wie [Sitzungsidentität überprüfen](/docs/de/self-hosted-environments-identity) beschreibt.
230
231Behandeln Sie alle Anmeldedaten, die Ihr Hook an Git übergibt, als Anmeldedaten, die eine Sitzung erlangen kann, und erzeugen Sie sie so, dass sie nicht mehr als diesen Push ausführen können. Git in Ihrem Hook liest Konfigurationsdateien, die eine Sitzung schreiben kann, und ein Anmeldedaten-Helper oder Filtertreiber, der in einer davon benannt ist, läuft mit den Berechtigungen Ihres Hooks. Einstellungen in diesen Dateien können außerdem ändern, wohin ein Push geht, unabhängig davon, welches Remote Sie angeben. Welche Git-Einstellungen der Runner in Ihrem Hook festlegt und welche er diesen Dateien überlässt, beschreibt [Git-Konfiguration innerhalb von Lifecycle-Hooks](#git-configuration-inside-lifecycle-hooks).
192 232
193<h4 id="hook-timing-when-the-runner-releases-a-session">233<h4 id="hook-timing-when-the-runner-releases-a-session">
194 Hook-Timing, wenn der Runner eine Sitzung freigibt234 Hook-Timing, wenn der Runner eine Sitzung freigibt
232 272
233Wird einmal pro Sitzung nach dem Checkout anstelle des integrierten Kind-Spawns ausgeführt. Der Hook erhält dieselbe Umgebung wie ein [Wrapper-Skript](#wrapper-scripts) und sollte auf dieselbe Weise in `"$CLAUDE_RUNNER_CLAUDE_BIN"` `exec` ausführen. Verwenden Sie den `command`-Hook, um alle Anpassungen in einem Hooks-Verzeichnis zu halten; verwenden Sie `--exec-path`, wenn der Wrapper anderswo lebt. Wenn `--exec-path` auch gesetzt ist, hat das Flag Vorrang und der `command`-Hook wird ignoriert.273Wird einmal pro Sitzung nach dem Checkout anstelle des integrierten Kind-Spawns ausgeführt. Der Hook erhält dieselbe Umgebung wie ein [Wrapper-Skript](#wrapper-scripts) und sollte auf dieselbe Weise in `"$CLAUDE_RUNNER_CLAUDE_BIN"` `exec` ausführen. Verwenden Sie den `command`-Hook, um alle Anpassungen in einem Hooks-Verzeichnis zu halten; verwenden Sie `--exec-path`, wenn der Wrapper anderswo lebt. Wenn `--exec-path` auch gesetzt ist, hat das Flag Vorrang und der `command`-Hook wird ignoriert.
234 274
235Führen Sie immer die eigene Binärdatei des Runners aus, anstatt ein PATH-aufgelöstes `claude`; andernfalls besiegen Sie [Versions-Pinning](/docs/de/self-hosted-environments-deploy#pin-the-version).275Führen Sie immer mit `exec` die eigene Binärdatei des Runners aus, anstatt ein PATH-aufgelöstes `claude`; andernfalls umgehen Sie das [Versions-Pinning](/docs/de/self-hosted-environments-deploy#pin-the-version).
236 276
237<h2 id="on-demand-runners">277<h2 id="on-demand-runners">
238 On-Demand-Runner278 On-Demand-Runner
264| `CLAUDE_RUNNER_ORDER_ID` | Undurchsichtiger Idempotenz-Schlüssel, eindeutig pro Spawn-Anfrage und sicher für Kubernetes-Ressourcennamen. Verwenden Sie nur die Order-ID als Dedup-Schlüssel Ihres Provisioners. |304| `CLAUDE_RUNNER_ORDER_ID` | Undurchsichtiger Idempotenz-Schlüssel, eindeutig pro Spawn-Anfrage und sicher für Kubernetes-Ressourcennamen. Verwenden Sie nur die Order-ID als Dedup-Schlüssel Ihres Provisioners. |
265| `CLAUDE_RUNNER_SESSION_ID` | Die Sitzung, für die diese Anfrage bestimmt ist. Sie wiederholt sich bei jeder Neuanfrage für die Sitzung, daher verwenden Sie sie für Protokollierung und Routing, nicht als Dedup-Schlüssel. Leer für Pre-Warming-Anfragen, die einen Standby-Runner im Voraus starten, bevor eine bestimmte Sitzung, wenn [`--min-idle`](/docs/de/self-hosted-environments-reference#orchestrator-cli-flags) gesetzt ist, daher nehmen Sie nicht an, dass die Variable gesetzt ist. |305| `CLAUDE_RUNNER_SESSION_ID` | Die Sitzung, für die diese Anfrage bestimmt ist. Sie wiederholt sich bei jeder Neuanfrage für die Sitzung, daher verwenden Sie sie für Protokollierung und Routing, nicht als Dedup-Schlüssel. Leer für Pre-Warming-Anfragen, die einen Standby-Runner im Voraus starten, bevor eine bestimmte Sitzung, wenn [`--min-idle`](/docs/de/self-hosted-environments-reference#orchestrator-cli-flags) gesetzt ist, daher nehmen Sie nicht an, dass die Variable gesetzt ist. |
266| `CLAUDE_RUNNER_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form. Leer für Pre-Warming-Anfragen. |306| `CLAUDE_RUNNER_SESSION_UUID` | Dieselbe Sitzungs-ID in kanonischer UUID-Form. Leer für Pre-Warming-Anfragen. |
267| `CLAUDE_RUNNER_ATTEMPT` | Wie viele Spawn-Anfragen diese Sitzung hatte. `0` für Pre-Warming-Anfragen. |307| `CLAUDE_RUNNER_ATTEMPT` | Ein Zähler pro Sitzung zur Verwendung in Logs. Er ist weder eine Anzahl von Wiederholungsversuchen noch eine Anzahl von Anfragen. `0` für Pre-Warming-Anfragen, wobei auch eine Anfrage für eine Sitzung `0` enthalten kann. |
268| `CLAUDE_RUNNER_ORDER_SERVER_TIME` | Server-Zeit aus dem HTTP-`Date`-Header der Poll-Antwort. Wenn der Hook das Arbeitsorder-JWT `exp` überprüft, vergleichen Sie gegen diesen Wert anstelle der lokalen Uhr, um Skew zu tolerieren. Leer, wenn das Gateway den Header weggelassen hat. |308| `CLAUDE_RUNNER_ORDER_SERVER_TIME` | Server-Zeit aus dem HTTP-`Date`-Header der Poll-Antwort. Wenn der Hook das Arbeitsorder-JWT `exp` überprüft, vergleichen Sie gegen diesen Wert anstelle der lokalen Uhr, um Skew zu tolerieren. Leer, wenn das Gateway den Header weggelassen hat. |
269| `CLAUDE_RUNNER_POOL_ID` | Die ID der Umgebung, der der neue Runner beitreten sollte, in der Form `ccpool_...` |309| `CLAUDE_RUNNER_POOL_ID` | Die ID der Umgebung, der der neue Runner beitreten sollte, in der Form `ccpool_...` |
270| `CLAUDE_RUNNER_ACCOUNT_ID` | Getaggte ID des Kontos, das die Sitzung in die Warteschlange eingereiht hat, für Pro-Konto-Routing, Kontingent oder Chargeback. Leer, wenn nicht verfügbar, und immer leer für Claude Tag-Kanal-Sitzungen, die kein Konto einreiht. |310| `CLAUDE_RUNNER_ACCOUNT_ID` | Getaggte ID des Kontos, das die Sitzung in die Warteschlange eingereiht hat, für Pro-Konto-Routing, Kontingent oder Chargeback. Leer, wenn nicht verfügbar, und immer leer für Claude Tag-Kanal-Sitzungen, die kein Konto einreiht. |
271| `CLAUDE_RUNNER_ACCOUNT_EMAIL` | E-Mail des Kontos, das die Sitzung in die Warteschlange eingereiht hat. Leer, wenn nicht verfügbar. Behandeln Sie die E-Mail als personenbezogene Informationen und protokollieren Sie sie nicht. |311| `CLAUDE_RUNNER_ACCOUNT_EMAIL` | E-Mail des Kontos, das die Sitzung in die Warteschlange eingereiht hat. Leer, wenn nicht verfügbar. Behandeln Sie die E-Mail als personenbezogene Informationen und protokollieren Sie sie nicht. |
272| `CLAUDE_RUNNER_PRIMARY_REPO_URL` | URL der ersten Git-Quelle der Sitzung, für Routing zu einem Runner mit diesem Repository pre-warmed. Leer, wenn die Sitzung keine Git-Quellen hat. |312| `CLAUDE_RUNNER_PRIMARY_REPO_URL` | URL der ersten Git-Quelle der Sitzung, für Routing zu einem Runner mit diesem Repository pre-warmed. Leer, wenn die Sitzung keine Git-Quellen hat. |
273| `CLAUDE_RUNNER_PRIMARY_REPO_REVISION` | Revision der ersten Git-Quelle der Sitzung: Branch, SHA oder Tag. Leer, wenn nicht angegeben. |313| `CLAUDE_RUNNER_PRIMARY_REPO_REVISION` | Revision der ersten Git-Quelle der Sitzung: Branch, SHA, Tag oder vollständiger Referenzname. Leer, wenn nicht angegeben. |
274| `CLAUDE_RUNNER_REPO_SOURCES` | JSON-Array von `{url, revision}` für alle Git-Quellen der Sitzung, für Hooks, die auf einem sekundären Repository routen. Leer, wenn es keine Quellen gibt. |314| `CLAUDE_RUNNER_REPO_SOURCES` | JSON-Array von `{url, revision}` für alle Git-Quellen der Sitzung, für Hooks, die auf einem sekundären Repository routen. Leer, wenn es keine Quellen gibt. |
275| `CLAUDE_RUNNER_CORRELATION_ID` | Die Korrelations-ID, die bei der Sitzungserstellung bereitgestellt wurde, echoed zurück, damit der Hook diese Arbeitsorder der Anfrage zuordnen kann, die die Sitzung erstellt hat. Leer, wenn die Sitzung keine hat. |315| `CLAUDE_RUNNER_CORRELATION_ID` | Die Korrelations-ID, die bei der Sitzungserstellung bereitgestellt wurde, echoed zurück, damit der Hook diese Arbeitsorder der Anfrage zuordnen kann, die die Sitzung erstellt hat. Leer, wenn die Sitzung keine hat. |
276| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app`, `ios` oder `scheduled_trigger`, für Adoptionsanalysen. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat, und für Pre-Warming-Anfragen; überprüfen Sie sie mit `[ -n "${CLAUDE_RUNNER_CLIENT_PLATFORM:-}" ]`, was unter `set -u` sicher bleibt. |316| `CLAUDE_RUNNER_CLIENT_PLATFORM` | Die Client-Oberfläche, die die Sitzung erstellt hat, wie `web_claude_ai`, `desktop_app`, `ios` oder `scheduled_trigger`, für Adoptionsanalysen. Nicht gesetzt, wenn die Sitzung keine aufgezeichnete oder erkannte Oberfläche hat, und für Pre-Warming-Anfragen; überprüfen Sie sie mit `[ -n "${CLAUDE_RUNNER_CLIENT_PLATFORM:-}" ]`, was unter `set -u` sicher bleibt. |
282* **Verwenden Sie `--capacity 1` auf gespawten Runnern**: Eine Sitzungs-gebundene Arbeitsorder registriert genau einen Runner, der an diese Sitzung gebunden ist, daher fügt eine höhere Kapazität Slots hinzu, die niemals Arbeit erhalten, und der Runner protokolliert eine Warnung beim Startup.322* **Verwenden Sie `--capacity 1` auf gespawten Runnern**: Eine Sitzungs-gebundene Arbeitsorder registriert genau einen Runner, der an diese Sitzung gebunden ist, daher fügt eine höhere Kapazität Slots hinzu, die niemals Arbeit erhalten, und der Runner protokolliert eine Warnung beim Startup.
283* **Pre-Warming-Arbeitsorder registrieren ungebunden**: Der Standby-Runner ist nicht an eine Sitzung gebunden und beansprucht in der Warteschlange befindliche Arbeit wie ein Fixed-Fleet-Runner.323* **Pre-Warming-Arbeitsorder registrieren ungebunden**: Der Standby-Runner ist nicht an eine Sitzung gebunden und beansprucht in der Warteschlange befindliche Arbeit wie ein Fixed-Fleet-Runner.
284 324
285Der Vertrag hat vier Provisioner-agnostische Regeln:325Der Vertrag hat vier Regeln, unabhängig davon, auf welcher Plattform Ihr Hook provisioniert:
286 326
2871. **Seien Sie idempotent auf `CLAUDE_RUNNER_ORDER_ID`.** Neulieferung derselben Anfrage muss höchstens einen Runner spawnen. Leiten Sie einen deterministischen Ressourcennamen von der Order-ID ab und lassen Sie Ihre Plattform das Duplikat ablehnen. Keying Sie nicht auf `CLAUDE_RUNNER_SESSION_ID` stattdessen. Jede Neuanfrage für eine Sitzung trägt dieselbe Sitzungs-ID mit einer neuen Order-ID, daher wird eine Workload, die nach der Sitzungs-ID benannt oder dedupliziert ist, einmal erstellt und nie wieder für diese Sitzung.3271. **Seien Sie idempotent auf `CLAUDE_RUNNER_ORDER_ID`.** Neulieferung derselben Anfrage muss höchstens einen Runner spawnen. Leiten Sie einen deterministischen Ressourcennamen von der Order-ID ab und lassen Sie Ihre Plattform das Duplikat ablehnen. Keying Sie nicht auf `CLAUDE_RUNNER_SESSION_ID` stattdessen. Jede Neuanfrage für eine Sitzung trägt dieselbe Sitzungs-ID mit einer neuen Order-ID, daher wird eine Workload, die nach der Sitzungs-ID benannt oder dedupliziert ist, einmal erstellt und nie wieder für diese Sitzung.
2882. **Versuchen Sie nicht, die Workload erneut zu versuchen.** Eine Order-ID bedeutet höchstens eine erstellte Workload. Wenn sich der Runner nie registriert, fordert Anthropic nach `--expected-spawn-seconds` mit einer frischen Order-ID erneut an.3282. **Versuchen Sie nicht, die Workload erneut zu versuchen.** Eine Order-ID bedeutet höchstens eine erstellte Workload. Wenn sich der Runner nie registriert, fordert Anthropic nach `--expected-spawn-seconds` mit einer frischen Order-ID erneut an.
2893. **Verwenden Sie den Exit-Code-Vertrag.** Exit 0 bedeutet eingereicht. Exit 1 bedeutet wiederholbarer Fehler; die Sitzung sichert sich ab und wird erneut angeboten. Exit 2 oder höher bedeutet nicht wiederholbar; die Sitzung wird blockiert, bis ein [Owner](/docs/de/cloud-environments#organization-shared-environments) auf der Registerkarte **Aktivität** der Umgebung **Erneut versuchen** auswählt. Bei Nicht-Null-Exit erscheint das Ende des Stderr des Hooks dort als Fehlergrund, daher schreiben Sie den umsetzbaren Fehler auf stderr und niemals Geheimnisse. Für eine Pre-Warming-Anfrage gibt es keine Sitzung zum Fehlschlag: Der Orchestrator protokolliert einen Nicht-Null-Exit lokal nur, und der Server fordert den Spawn nach dem Lease erneut an.3293. **Verwenden Sie den Exit-Code-Vertrag.** Beenden Sie den Hook mit dem Status, der dem Ergebnis entspricht:
2904. **Setzen Sie `--expected-spawn-seconds` auf mindestens Ihre p99-Boot-Zeit.** Dies ist das serverseitige Lease. Alle Orchestrator-Replikas müssen denselben Wert verwenden.330
331 * **Exit 0**: eingereicht.
332 * **Exit 1**: wiederholbarer Fehler. Die Sitzung wartet mit Backoff und wird erneut angeboten.
333 * **Exit 2 oder höher**: nicht wiederholbarer Fehler. Die Sitzung wird für weitere Spawns blockiert, bis ein Benutzer ihr eine neue Nachricht sendet oder ein [Owner](/docs/de/cloud-environments#organization-shared-environments) auf der Registerkarte **Aktivität** der Umgebung **Erneut versuchen** auswählt.
334
335 Bei einem Exit ungleich null erscheint das Ende der stderr-Ausgabe des Hooks auf der Registerkarte **Aktivität** als Fehlergrund; schreiben Sie daher den umsetzbaren Fehler auf stderr und schreiben Sie dort niemals Geheimnisse. In einem Shell-Hook [halten Sie vorübergehende Fehler wiederholbar](#keep-transient-failures-retryable-in-a-shell-hook).
336
337 Eine Pre-Warming-Anfrage hat keine Sitzung, die fehlschlagen kann: Der Orchestrator protokolliert einen Exit ungleich null nur lokal, und der Server fordert den Spawn erneut an, nachdem das Lease von `--expected-spawn-seconds` abgelaufen ist.
3384. **Setzen Sie `--expected-spawn-seconds` auf mindestens Ihre p99-Zeit von der Spawn-Anfrage bis zur Runner-Registrierung.** Messen Sie ab dem Zeitpunkt, an dem der Orchestrator die Spawn-Anfrage erhält, und beziehen Sie jede Wartezeit auf Kapazität auf Ihrer Plattform sowie die Boot-Zeit ein. Dieser Wert ist das serverseitige Lease, und die Arbeitsorder läuft mit ihm ab, sodass sich ein Runner, dessen Workload länger braucht, nicht registrieren kann. Alle Orchestrator-Replikas müssen denselben Wert verwenden.
291 339
292Alles, was der Hook auf stdout oder stderr schreibt, erscheint im Protokoll des Orchestrators mit automatisch redigierten Anmeldedaten. Wenn Sitzungen in der Warteschlange bleiben, überprüfen Sie den `/healthz`-Body des Orchestrators auf Warteschlangen-Zählungen, öffnen Sie dann die Registerkarte **Aktivität** Ihrer Umgebung auf der [**Cloud-Umgebungen**-Administratorseite](https://claude.ai/admin-settings/cloud-environments): Erweitern Sie eine fehlgeschlagene Sitzung dort für ihren Spawn-Fehler und wählen Sie **Erneut versuchen**, um sie erneut anzufordern.340Alles, was der Hook auf stdout oder stderr schreibt, erscheint im Protokoll des Orchestrators mit automatisch redigierten Anmeldedaten. Wenn Sitzungen in der Warteschlange bleiben, überprüfen Sie den `/healthz`-Body des Orchestrators auf Warteschlangen-Zählungen, öffnen Sie dann die Registerkarte **Aktivität** Ihrer Umgebung auf der [**Cloud-Umgebungen**-Administratorseite](https://claude.ai/admin-settings/cloud-environments): Erweitern Sie eine fehlgeschlagene Sitzung dort für ihren Spawn-Fehler und wählen Sie **Erneut versuchen**, um sie erneut anzufordern.
293 341
294Eine Sitzung, die in der Warteschlange bleibt, ohne dass ein Spawn-Fehler auf der Registerkarte **Aktivität** vorhanden ist, kann bedeuten, dass der Hook nach der Sitzungs-ID keyed ist. Um dies zu bestätigen, überprüfen Sie, ob Ihre Plattform eine Workload für die erste Spawn-Anfrage dieser Sitzung hat und keine für die Neuanfragen. Wenn ja, keying Sie die Workload auf `CLAUDE_RUNNER_ORDER_ID` stattdessen.342Eine Sitzung, die in der Warteschlange bleibt, ohne dass ein Spawn-Fehler auf der Registerkarte **Aktivität** vorhanden ist, kann bedeuten, dass der Hook nach der Sitzungs-ID keyed ist. Um dies zu bestätigen, überprüfen Sie, ob Ihre Plattform eine Workload für die erste Spawn-Anfrage dieser Sitzung hat und keine für die Neuanfragen. Wenn ja, keying Sie die Workload auf `CLAUDE_RUNNER_ORDER_ID` stattdessen.
295 343
344<h4 id="keep-transient-failures-retryable-in-a-shell-hook">
345 Vorübergehende Fehler in einem Shell-Hook wiederholbar halten
346</h4>
347
348In einem Shell-Hook, der `set -e` verwendet, kann ein Fehler, den ein Wiederholungsversuch hätte beheben können, die Sitzung blockieren. Der Hook stoppt beim fehlschlagenden Befehl und endet mit dem eigenen Status dieses Befehls, und der Orchestrator wendet den Exit-Code-Vertrag auf diesen Status an. Viele Fehler geben einen Status von 2 oder höher zurück, etwa `127`, wenn ein Befehl nicht installiert ist, und `22` von `curl --fail` bei einem HTTP-Fehler, sodass sie die Sitzung bereits beim ersten Fehler blockieren.
349
350Eine Sitzung, die der Hook bereits blockiert hat, bleibt blockiert, bis ein Benutzer ihr eine neue Nachricht sendet oder ein [Owner](/docs/de/cloud-environments#organization-shared-environments) auf der Registerkarte **Aktivität** der Umgebung **Erneut versuchen** auswählt.
351
352Um einen solchen Fehler stattdessen in Exit 1 umzuwandeln, fügen Sie diese Zeilen direkt unter der `#!`-Zeile des Hooks ein, oberhalb von allem, was fehlschlagen kann:
353
354```bash theme={null}
355set -e
356PERMANENT=; permanent() { printf '%s\n' "$*" >&2; PERMANENT=1; exit 2; }
357trap 'rc=$?; [ "$rc" -eq 0 ] || [ -n "${PERMANENT:-}" ] || exit 1' EXIT
358```
359
360Diese Zeilen ändern das Verhalten des restlichen Hooks; prüfen Sie ihn daher nach dem Einfügen auf jedes dieser Muster:
361
362* **Einfaches `exit 2` oder höher**: Mit gesetztem Trap wird daraus Exit 1. Rufen Sie für einen Fehler, den kein Wiederholungsversuch beheben kann, stattdessen `permanent` mit dem Grund auf, etwa `permanent "namespace claude-runners does not exist"`. Rufen Sie es in der Haupt-Shell auf, nicht innerhalb von `$( )`, `( )` oder einer Pipe.
363* **`exec`**: Beginnen Sie den letzten Befehl des Hooks nicht mit `exec`, da `exec` die Shell ersetzt und der Trap nicht ausgeführt wird.
364* **Zweiter `EXIT`-Trap**: Ein zweiter `trap ... EXIT` ersetzt den ersten; führen Sie die beiden daher zu einem einzigen Trap zusammen. Setzen Sie Ihre Bereinigungsbefehle direkt hinter `rc=$?;` und beenden Sie jeden mit `|| true;`. Die Bereinigung läuft dann sowohl bei Fehlern als auch bei Erfolg, und ein fehlschlagender Bereinigungsbefehl setzt nicht den Exit-Status des Hooks. Dieser zusammengeführte Trap zeigt die Form, wobei `your-cleanup-command` für Ihren eigenen Befehl steht:
365
366 ```bash theme={null}
367 trap 'rc=$?; your-cleanup-command || true; [ "$rc" -eq 0 ] || [ -n "${PERMANENT:-}" ] || exit 1' EXIT
368 ```
369* **Befehle, die fehlschlagen dürfen**: Wenn der Hook zuvor kein `set -e` verwendet hat, stoppt er jetzt beim ersten Befehl, der einen Wert ungleich null zurückgibt, etwa bei einer Suche ohne Ergebnis oder einer doppelten Einreichung, die Ihre Plattform ablehnt. Wenn der Hook auf das Ergebnis reagiert, machen Sie diesen Befehl zur Bedingung eines `if`. Wenn er das Ergebnis ignoriert, hängen Sie `|| true` an den Befehl an.
370
371Um zu bestätigen, dass der Trap funktioniert, fügen Sie direkt unter der `trap`-Zeile eine Zeile ein, die einen nicht existierenden Befehl aufruft, etwa `no-such-command`. Führen Sie die Hook-Datei aus Ihrer Shell aus und prüfen Sie, dass `echo $?` den Wert `1` ausgibt; entfernen Sie die Zeile anschließend.
372
296<h2 id="send-model-requests-to-bedrock-or-agent-platform">373<h2 id="send-model-requests-to-bedrock-or-agent-platform">
297 Modellanfragen an Bedrock oder Agent Platform senden374 Modellanfragen an Bedrock oder Agent Platform senden
298</h2>375</h2>
381Eine Sitzung, die Modellanfragen an Amazon Bedrock oder Google Cloud's Agent Platform sendet, unterscheidet sich auf folgende Weise von einer Sitzung über die Anthropic API:458Eine Sitzung, die Modellanfragen an Amazon Bedrock oder Google Cloud's Agent Platform sendet, unterscheidet sich auf folgende Weise von einer Sitzung über die Anthropic API:
382 459
383* **Richtlinien aus claude.ai**: [Serververwaltete Einstellungen](/docs/de/server-managed-settings) erreichen diese Sitzungen nicht. Ebenso wenig die Organisationsrichtlinien, die ein Owner in den Claude Code Admin-Einstellungen festlegt, daher setzt Claude Code sie innerhalb der Sitzung nicht durch. Legen Sie die Regeln, auf die Sie sich verlassen, in der [Datei für verwaltete Einstellungen](/docs/de/managed-settings#delivery-mechanisms) des Runner-Images ab.460* **Richtlinien aus claude.ai**: [Serververwaltete Einstellungen](/docs/de/server-managed-settings) erreichen diese Sitzungen nicht. Ebenso wenig die Organisationsrichtlinien, die ein Owner in den Claude Code Admin-Einstellungen festlegt, daher setzt Claude Code sie innerhalb der Sitzung nicht durch. Legen Sie die Regeln, auf die Sie sich verlassen, in der [Datei für verwaltete Einstellungen](/docs/de/managed-settings#delivery-mechanisms) des Runner-Images ab.
461* **Konto-Skills**: Diese Sitzungen laden die Skills, die für das claude.ai-Konto einer Person aktiviert sind, nicht herunter. Siehe [Wie die Konfiguration jeder Sitzung zusammengestellt wird](#how-each-session’s-config-is-assembled).
384* **Dateien**: Dateien, die Personen in claude.ai oder der mobilen oder Desktop-App an eine Sitzung anhängen, erreichen diese nicht, und Claude kann mit dem [`SendUserFile`-Tool](/docs/de/tools-reference) keine Dateien zurücksenden. Legen Sie Eingabedateien stattdessen im Repository oder auf dem Runner ab.462* **Dateien**: Dateien, die Personen in claude.ai oder der mobilen oder Desktop-App an eine Sitzung anhängen, erreichen diese nicht, und Claude kann mit dem [`SendUserFile`-Tool](/docs/de/tools-reference) keine Dateien zurücksenden. Legen Sie Eingabedateien stattdessen im Repository oder auf dem Runner ab.
385* **Modellauswahl**: Die Control Plane von Anthropic sendet das Modell jeder Sitzung, und wenn eine Sitzung ohne Modell startet, verwendet Claude Code seinen Standard für den Anbieter. Der Runner entfernt `ANTHROPIC_MODEL` und `ANTHROPIC_DEFAULT_MODEL` aus der Umgebung, die er an Sitzungen übergibt. Die Beispiele auf den Anbieterseiten setzen `ANTHROPIC_MODEL`, aber in der Umgebung des Runners hat keine der beiden Variablen eine Wirkung. Die familienspezifischen Variablen unter „Modellversionen festlegen“ für [Amazon Bedrock](/docs/de/amazon-bedrock#4-pin-model-versions) und [Agent Platform](/docs/de/google-vertex-ai#5-pin-model-versions) erreichen Sitzungen hingegen. Sie bestimmen, worauf ein Alias wie `opus` aufgelöst wird, nicht, worauf eine vollständige Modell-ID aufgelöst wird.463* **Modellauswahl**: Die Control Plane von Anthropic sendet das Modell jeder Sitzung, und wenn eine Sitzung ohne Modell startet, verwendet Claude Code seinen Standard für den Anbieter. Sie können das Modell nicht mit `ANTHROPIC_MODEL` oder `ANTHROPIC_DEFAULT_MODEL` in der Umgebung des Runners auswählen, aber Sie können festlegen, worauf ein Alias aufgelöst wird:
464 * **`ANTHROPIC_MODEL` und `ANTHROPIC_DEFAULT_MODEL`**: Der Runner entfernt sie aus der Umgebung, die er an Sitzungen übergibt, obwohl die Beispiele auf den Anbieterseiten `ANTHROPIC_MODEL` setzen.
465 * **Familienspezifische Variablen zum Festlegen von Versionen**: Die Variablen unter „Modellversionen festlegen“ für [Amazon Bedrock](/docs/de/amazon-bedrock#4-pin-model-versions) und [Agent Platform](/docs/de/google-vertex-ai#5-pin-model-versions) erreichen Sitzungen hingegen. Sie bestimmen, worauf ein Alias wie `opus` aufgelöst wird, nicht, worauf eine vollständige Modell-ID aufgelöst wird.
386* **Modelle, die Ihr Konto nicht bereitstellt**: Eine Sitzung kann bei einer Nachricht mit einem Fehler fehlschlagen, der das Modell nennt. Aktivieren Sie die Modelle, die Ihre Entwickler auswählen können, das unter „Modellversionen festlegen“ beschriebene Hintergrundmodell sowie das Klassifikatormodell, das der [Auto-Modus](/docs/de/permission-modes#enable-auto-mode-on-bedrock-agent-platform-or-foundry) verwendet. Lassen Sie bei Amazon Bedrock jedes davon in Ihrer Richtlinie zu.466* **Modelle, die Ihr Konto nicht bereitstellt**: Eine Sitzung kann bei einer Nachricht mit einem Fehler fehlschlagen, der das Modell nennt. Aktivieren Sie die Modelle, die Ihre Entwickler auswählen können, das unter „Modellversionen festlegen“ beschriebene Hintergrundmodell sowie das Klassifikatormodell, das der [Auto-Modus](/docs/de/permission-modes#enable-auto-mode-on-bedrock-agent-platform-or-foundry) verwendet. Lassen Sie bei Amazon Bedrock jedes davon in Ihrer Richtlinie zu.
387* **Websuche und Fast-Modus**: Die [Websuche](/docs/de/tools-reference#websearch-tool-behavior) ist auf Amazon Bedrock nicht verfügbar, und der [Fast-Modus](/docs/de/fast-mode) ist bei keinem der beiden Anbieter verfügbar. Weitere Funktionen, die sich je nach Anbieter unterscheiden, finden Sie unter [CLI-Funktionen, die je nach Anbieter variieren](/docs/de/feature-availability#cli-capabilities-that-vary-by-provider).467* **Websuche und Fast-Modus**: Die [Websuche](/docs/de/tools-reference#websearch-tool-behavior) ist auf Amazon Bedrock nicht verfügbar, und der [Fast-Modus](/docs/de/fast-mode) ist bei keinem der beiden Anbieter verfügbar. Weitere Funktionen, die sich je nach Anbieter unterscheiden, finden Sie unter [CLI-Funktionen, die je nach Anbieter variieren](/docs/de/feature-availability#cli-capabilities-that-vary-by-provider).
388 468
411 491
412Sitzungen erben die Umgebung des Runners. Setzen Sie daher [`ENABLE_TOOL_SEARCH`](/docs/de/mcp#scale-with-mcp-tool-search) dort, um MCP Tool Search für jede Sitzung zu steuern, die ein Runner startet; die MCP-Seite beschreibt die möglichen Werte.492Sitzungen erben die Umgebung des Runners. Setzen Sie daher [`ENABLE_TOOL_SEARCH`](/docs/de/mcp#scale-with-mcp-tool-search) dort, um MCP Tool Search für jede Sitzung zu steuern, die ein Runner startet; die MCP-Seite beschreibt die möglichen Werte.
413 493
494<a id="connection-timing" />
495
496<h3 id="wait-for-mcp-servers-before-the-first-turn">
497 Vor dem ersten Turn auf MCP-Server warten
498</h3>
499
500Eine selbst gehostete Sitzung wartet an zwei separaten Stellen kurz auf MCP-Server, die noch eine Verbindung herstellen. Bei einem Server, der eine Wartezeit verpasst, fehlen die Tools, wenn der erste Turn beginnt; sie werden später ohne Ihr Zutun verfügbar. Die beiden Wartezeiten sind:
501
502* **Sitzungsstart**: Bevor die Tool-Liste zum ersten Mal erfasst wird, wartet die Sitzung standardmäßig bis zu 5 Sekunden auf einen HTTP- oder SSE-Server, dessen Eintrag [`alwaysLoad: true`](/docs/de/mcp#exempt-a-server-from-deferral) setzt, oder auf alle Server, wenn Sie [`MCP_CONNECTION_NONBLOCKING=0`](/docs/de/env-vars) in der Umgebung des Runners setzen. HTTP- und SSE-Server stellen die Verbindung ansonsten im Hintergrund her. Während die Sitzung hier wartet, dauert ihre Initialisierung länger. [`MCP_CONNECT_TIMEOUT_MS`](/docs/de/env-vars) ändert den Standardwert von 5 Sekunden.
503* **Erster Turn**: Nachdem die Nachricht eingetroffen ist, wartet der erste Turn bis zu 2 Sekunden auf stdio-Server, die noch eine Verbindung herstellen. Während die Sitzung hier wartet, kommt die erste Antwort langsamer. Um die Dauer dieser Wartezeit zu ändern, setzen Sie [`CLAUDE_CODE_MCP_STARTUP_WAIT_MS`](/docs/de/env-vars) in der Umgebung des Runners. Dies ändert nicht, welche Server die Wartezeit abdeckt. Erfordert Claude Code v2.1.274 oder neuer.
504
505`claude mcp add` hat kein Flag `alwaysLoad`. Um den Schlüssel zu setzen, fügen Sie den Server stattdessen mit `claude mcp add-json` hinzu; dieser Befehl übernimmt den Schlüssel im JSON des Servers und schreibt ihn in `.claude.json`. In Ihrem Dockerfile:
506
507```dockerfile theme={null}
508RUN claude mcp add-json core '{"type":"http","url":"https://mcp.example.com/mcp","alwaysLoad":true}' --scope user
509```
510
511Wenn die Tools eines Servers auch in späteren Turns nicht erscheinen, prüfen Sie, ob der Server die Sitzung überhaupt erreicht hat, wie unter [MCP-Server](#mcp-servers) beschrieben.
512
414<h3 id="turn-off-built-in-session-tools">513<h3 id="turn-off-built-in-session-tools">
415 Integrierte Sitzungstools ausschalten514 Integrierte Sitzungstools ausschalten
416</h3>515</h3>
571 670
572Setzen Sie `SELF_HOSTED_RUNNER_HOST_CONFIG_DIR`, um von einem anderen Pfad zu befüllen, oder lassen Sie die Variable auf ein leeres Verzeichnis zeigen, um das Befüllen zu deaktivieren.671Setzen Sie `SELF_HOSTED_RUNNER_HOST_CONFIG_DIR`, um von einem anderen Pfad zu befüllen, oder lassen Sie die Variable auf ein leeres Verzeichnis zeigen, um das Befüllen zu deaktivieren.
573 672
574Eine im Repository committete `.claude/settings.json` wird als Projekteinstellungen darübergelegt. In einer Sitzung mit mehreren Repositorys [wird höchstens die Datei eines einzigen Repositorys wirksam](#repository-settings-in-sessions-with-several-repositories). Sitzungen lesen außerdem [`managed-settings.json`](/docs/de/settings#where-settings-live) aus dem standardmäßigen Systempfad in Ihrem Runner-Image. Ob deren Schlüssel neben [serververwalteten Einstellungen](/docs/de/server-managed-settings) gelten, richtet sich danach, [wie Claude Code verwaltete Quellen kombiniert](/docs/de/managed-settings#how-claude-code-combines-managed-sources): Wenn Ihre Organisation serververwaltete Schlüssel bereitstellt, ignorieren Sitzungen standardmäßig die Datei des Runner-Images, abgesehen von den [Schlüsseln, die Claude Code aus jeder Admin-Quelle liest](/docs/de/managed-settings#keys-read-from-every-admin-source), etwa dem `env`-Block, den Sandbox-Sperren, den Pfaden zu den Sandbox-Binärdateien und `forceRemoteSettingsRefresh`. Siehe [Vorrang der Einstellungen](/docs/de/settings#settings-precedence).673Sitzungen lesen außerdem diese Einstellungsdateien:
674
675* **Projekteinstellungen**: Eine im Repository committete `.claude/settings.json` wird über die Basis auf Benutzerebene gelegt. In einer Sitzung mit mehreren Repositorys [wird höchstens die Datei eines einzigen Repositorys wirksam](#repository-settings-in-sessions-with-several-repositories).
676* **Verwaltete Einstellungen**: Sitzungen lesen [`managed-settings.json`](/docs/de/settings#where-settings-live) aus dem standardmäßigen Systempfad in Ihrem Runner-Image. Ob deren Schlüssel neben [serververwalteten Einstellungen](/docs/de/server-managed-settings) gelten, erfahren Sie unter [wie Claude Code verwaltete Quellen kombiniert](/docs/de/managed-settings#how-claude-code-combines-managed-sources).
677
678In welcher Reihenfolge diese Quellen angewendet werden, erfahren Sie unter [Vorrang der Einstellungen](/docs/de/settings#settings-precedence).
575 679
576Wenn die Steuerungsebene von Anthropic eine Sitzung mit [Claude Code-Hooks](/docs/de/hooks) versorgt, installiert der Runner diese neben Ihrer eigenen Konfiguration, nicht an deren Stelle. Erfordert Claude Code v2.1.229 oder höher.680Wenn die Steuerungsebene von Anthropic eine Sitzung mit [Claude Code-Hooks](/docs/de/hooks) versorgt, installiert der Runner diese neben Ihrer eigenen Konfiguration, nicht an deren Stelle. Erfordert Claude Code v2.1.229 oder höher.
577 681
579* **Wer sie erstellt**: Die Steuerungsebene füllt die Skripte aus festen Konstanten in ihrem eigenen Deployment, niemals aus sitzungsspezifischen Eingaben oder Eingaben von Drittanbietern.683* **Wer sie erstellt**: Die Steuerungsebene füllt die Skripte aus festen Konstanten in ihrem eigenen Deployment, niemals aus sitzungsspezifischen Eingaben oder Eingaben von Drittanbietern.
580* **Was weiterhin für sie gilt**: Hooks, die über `--settings` bereitgestellt werden, gehen in die gewöhnliche zusammengeführte Hook-Konfiguration ein, nicht in die verwaltete Ebene, sodass Ihre verwalteten Einstellungen weiterhin gelten. `disableAllHooks` deaktiviert sie, und sie gehören nicht zu den Kategorien, die [`allowManagedHooksOnly`](/docs/de/settings-reference#allowmanagedhooksonly) geladen lässt.684* **Was weiterhin für sie gilt**: Hooks, die über `--settings` bereitgestellt werden, gehen in die gewöhnliche zusammengeführte Hook-Konfiguration ein, nicht in die verwaltete Ebene, sodass Ihre verwalteten Einstellungen weiterhin gelten. `disableAllHooks` deaktiviert sie, und sie gehören nicht zu den Kategorien, die [`allowManagedHooksOnly`](/docs/de/settings-reference#allowmanagedhooksonly) geladen lässt.
581 685
686Wenn eine Person ihre eigene Sitzung startet, lädt Claude Code außerdem die [für ihr claude.ai-Konto aktivierten Skills](/docs/de/skills#skills-in-cowork-and-cloud-sessions) in das Konfigurationsverzeichnis dieser Sitzung herunter. Die Ausführung einer [Routine](/docs/de/routines) erhält nicht die Skills ihres Eigentümers, und eine Sitzung, die [Modellanfragen an Bedrock oder Agent Platform sendet](#send-model-requests-to-bedrock-or-agent-platform), lädt keine herunter. Für einen Skill, den diese Sitzungen benötigen, committen Sie ihn in das Verzeichnis `.claude/skills/` des Repositorys oder fügen Sie ihn Ihrem Runner-Image hinzu.
687
582Außerhalb von [Claude Tag](https://claude.com/docs/claude-tag/overview)-Sitzungen läuft eine Sitzung in einer selbstgehosteten Umgebung standardmäßig mit ausgeschaltetem [Auto-Memory](/docs/de/memory#auto-memory). Für Anweisungen, die über Sitzungen hinweg erhalten bleiben sollen, verwenden Sie die `CLAUDE.md` in Ihrem Runner-Image oder im Repository.688Außerhalb von [Claude Tag](https://claude.com/docs/claude-tag/overview)-Sitzungen läuft eine Sitzung in einer selbstgehosteten Umgebung standardmäßig mit ausgeschaltetem [Auto-Memory](/docs/de/memory#auto-memory). Für Anweisungen, die über Sitzungen hinweg erhalten bleiben sollen, verwenden Sie die `CLAUDE.md` in Ihrem Runner-Image oder im Repository.
583 689
584Der Snapshot, den der Runner vom `~/.claude/` des Hosts erstellt, lässt das Verzeichnis `projects/` aus. Der standardmäßige Speicherort von Auto-Memory liegt unterhalb dieses Verzeichnisses. Wenn Sie dort Memory-Dateien ablegen, übernimmt der Runner sie nicht in Sitzungen, und sie schalten Auto-Memory nicht ein.690Der Snapshot, den der Runner vom `~/.claude/` des Hosts erstellt, lässt das Verzeichnis `projects/` aus. Der standardmäßige Speicherort von Auto-Memory liegt unterhalb dieses Verzeichnisses. Wenn Sie dort Memory-Dateien ablegen, übernimmt der Runner sie nicht in Sitzungen, und sie schalten Auto-Memory nicht ein.
