Umgebungsvariablen

Das meiste an OAR richtest du in der Weboberfläche oder in config.json ein. Umgebungsvariablen sind für das, was feststehen muss, bevor das Relay läuft, oder was du von außen festlegen willst: wo das Relay seine Dateien ablegt, ob es oar.sh kontaktieren darf, wo das Programm eines Providers liegt. Diese Seite listet die Variablen, die du setzen darfst, nach Bereich geordnet.

Wo du sie setzt #

Das Relay liest seine Variablen einmal, beim Start. Setz sie in der Umgebung des Prozesses, der das Relay startet, und starte das Relay nach einer Änderung neu.

oar start ohne Dienst: Das Relay startet im Hintergrund mit der Umgebung der Shell, in der du oar start ausgeführt hast. Setz die Variable in dieser Shell oder im Profil, das diese Shell liest.
Der systemd-Benutzerdienst (oar service install, und der Installer unter Linux, wenn es eine Benutzersitzung gibt) liest deine Shell nicht. Die Unit-Datei, die er schreibt, setzt COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR (immer das eigene data/ der Installation, auch wenn deine Shell ein anderes setzt), COPILOT_WEB_RELAY_LOG_DIR und den PATH der Shell, die den Befehl ausgeführt hat, ergänzt um ~/.local/bin und den Ordner von Node.js, sonst nichts. oar start nutzt diesen Dienst, sobald die Unit existiert und eine systemd-Benutzersitzung antwortet, eine in deiner Shell exportierte Variable erreicht das Relay also nicht. OAR hat keine Einstellung für weitere Variablen in der Unit, und oar service install und oar setup --start schreiben die Unit-Datei neu, eine Zeile, die du hinzufügst, bleibt also nicht. Siehe Autostart und der Dienst.
Der Windows-Autostart wird in Settings → General → Autostart (Windows) (Einstellungen → Allgemein → Autostart, Windows) eingestellt, bei der Anmeldung oder beim Hochfahren. Er führt ein kleines Skript aus, das COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR und COPILOT_WEB_RELAY_LOG_DIR setzt (der Start beim Hochfahren ergänzt auch den Ordner von Node.js im PATH) und das Relay startet. Auch er übernimmt keine Variablen aus einer Shell, und OAR hat keine Einstellung für weitere.
Ein Neustart mit oar restart eines Relays, das nicht als Dienst läuft, startet den neuen Prozess mit derselben Umgebung wie den alten. Um dort eine Variable zu ändern, führ oar stop aus, dann oar start aus einer Shell, die sie hat.

Die Installer-Variablen liest das Installationsskript, auf der Befehlszeile, die es ausführt, nicht das Relay. Siehe OAR installieren.

Welche Variablen die Worker der Agents erreichen #

Jede Konversation läuft in einem Worker-Prozess, den das Relay startet. Die meisten Variablen auf dieser Seite liest das Relay selbst. Einige liest der Worker, und ob der Wert des Relays ihn erreicht, hängt davon ab, wie der Worker gestartet wird:

Ohne tmux (Windows, und Linux oder macOS ohne installiertes tmux) startet der Worker mit der Umgebung des Relays, abzüglich dessen, was das Relay für jeden Worker herausnimmt (siehe unten). Die Variable für das Relay zu setzen genügt.
Unter tmux (Linux und macOS mit installiertem tmux) gibt das Relay eine feste Liste von Variablen an den Worker weiter, sonst nichts. Jede andere Variable erreicht ihn nicht. Läuft noch kein tmux-Server, behält der, den ein Start anlegt, unter Umständen den Rest der Umgebung des Relays, aber verlass dich nicht darauf.

Die feste Liste, soweit diese Seite sie behandelt: COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_LOG_DIR, COPILOT_WEB_RELAY_DATA_DIR, COPILOT_SDK_PATH, COPILOT_PROVIDER_MAX_PROMPT_TOKENS, COPILOT_PROVIDER_MAX_OUTPUT_TOKENS, CLAUDE_CONFIG_DIR, CLAUDE_CODE_EXECUTABLE, CURSOR_AGENT_STORE_DIR, GROK_CLI_COMMAND, GROK_ALWAYS_APPROVE und OAR_MCP_SERVER. Neu in 0.9.17 Diese und die Werte eines Starts (die Art des Workers, sein Modell, sein Ordner) kommen nur noch in den eigenen Befehl dieses Workers, nicht mehr in die Umgebung, die ein tmux-Server für jede spätere Session behält. Der Befehl jedes Workers entfernt zuerst die Variablen der Claude-Code-Host-Session (siehe unten) und jede Variable der Liste und jeden Provider-Key, für die dieser Start keinen Wert hat. Ein Wert, den ein früherer Start, ein älteres Relay oder die Shell, die den tmux-Server gestartet hat, dort hinterlassen hat, erreicht den Worker nicht.

Neu in 0.9.17 CLAUDE_CODE_OAUTH_TOKEN geht nur an Claude- und Claude-Cloud-Worker, auf jeder Plattform, unter tmux über eine Datei, die nur der Benutzer des Relays lesen kann. Siehe Claude Cloud. Neu in 0.9.18 Der für Claude API gespeicherte Key geht auf dieselbe Weise nur an Claude-API-Worker. Siehe Claude API. ANTHROPIC_API_KEY und ANTHROPIC_AUTH_TOKEN gehen an überhaupt keinen Worker, auf jeder Plattform; unter tmux entfernt der Befehl des Workers sie zusätzlich, egal, was der tmux-Server oder dein Login-Profil enthält. Siehe Claude.

Vom Worker gelesen	Unter tmux
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	Nicht weitergegeben. Auf einen Worker unter tmux wirken sie nicht.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW` (gelesen von Claude Code, das der Claude-Worker ausführt; das Claude Code eines DeepSeek- oder Neu in 0.9.18 Claude-API-Chats bekommt sie nie)	Nicht weitergegeben.
`OAR_MCP_SERVER`, `CLAUDE_CONFIG_DIR`, `CLAUDE_CODE_EXECUTABLE`, `CURSOR_AGENT_STORE_DIR`, `GROK_CLI_COMMAND`, `COPILOT_PROVIDER_MAX_*`	Weitergegeben. Das Relay gibt `GROK_CLI_COMMAND`, oder `GROK_COMMAND`, wenn jene nicht gesetzt ist, jedem Grok-Worker als `GROK_CLI_COMMAND` mit.
`XAI_API_KEY` (gelesen von der Grok CLI)	Nicht weitergegeben.
`COPILOT_SDK_PATH`	Weitergegeben: dein Wert oder der Ordner, den das Relay ermittelt hat. `COPILOT_PKG_DIR` liest nur das Relay.

Ein Relay, das aus Claude Code heraus gestartet wurde #

Neu in 0.9.17 Ein Relay, das du aus einer Shell einer Claude-Code-Session startest (zum Beispiel der Shell eines Agents), hat die Variablen dieser Session in seiner Umgebung. Das Relay entfernt sie für jeden Worker, mit und ohne tmux, damit sich kein Claude Code eines Workers für einen Teil dieser Session hält:

nach Name: CLAUDECODE, CLAUDE_CODE_ENTRYPOINT, CLAUDE_CODE_EXECPATH, CLAUDE_CODE_CHILD_SESSION, CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS, CLAUDE_AGENT_SDK_VERSION, CLAUDE_AGENT_SDK_CLIENT_APP, CLAUDE_PID, CLAUDE_EFFORT, CLAUDE_PROJECT_DIR und CLAUDE_ENV_FILE;
nach Familie: jedes CLAUDE_CODE_SESSION_* (darunter die Session-ID), jedes CLAUDE_CODE_*_SESSION_ID und jedes CLAUDE_CODE_MESSAGING_*.

Deine eigenen Einstellungen bleiben: jede andere CLAUDE_CODE_*-Variable (wie CLAUDE_CODE_USE_BEDROCK oder CLAUDE_CODE_GIT_BASH_PATH), jede andere CLAUDE_AGENT_SDK_*-Variable, CLAUDE_CONFIG_DIR und die zwei Einstellungen innerhalb einer Familie, CLAUDE_CODE_SESSION_START_ANNOUNCEMENTS_BEFORE_PROMPT und CLAUDE_CODE_SESSION_LOG. Das Claude Code eines DeepSeek-Chats bekommt noch weniger: siehe DeepSeek.

Was Vorrang hat #

Das unterscheidet sich je Variable, und die Tabellen sagen es. Kurz:

Eine Variable schlägt config.json beim Datenordner (dataDir), bei der Allow-Liste der Workspaces, den Preview-Einstellungen und beim Token, Programm und Modus des Tunnels. Die Marker-Header beider werden zusammengeführt. In config.json gibt es keinen Key für den Log-Ordner.
Ein im Panel installiertes Programm schlägt die Variable bei CLAUDE_CODE_EXECUTABLE und GROK_CLI_COMMAND: Das Panel speichert es in config.json und setzt es bei jedem Start des Relays neu.
Ein in der Weboberfläche gespeicherter Wert schlägt die Variable beim Cursor-Session-Token. Bei Feature-Flags ist es umgekehrt: Eine Variable schlägt, was der Tab Features (Funktionen) gespeichert hat.
Es gibt keine Variable für Port oder Token des Relays. Sie stehen in config.json (siehe config.json); oar setup --port ändert den Port.

Der Installer #

Gelesen von oar.sh/install (macOS und Linux) und oar.sh/install.ps1 (Windows). Stell sie vor die Shell, die das Skript ausführt:

curl -fsSL oar.sh/install | OAR_VERSION=0.9.19 OAR_PORT=3400 sh

$env:OAR_VERSION = '0.9.19'; irm oar.sh/install.ps1 | iex

Variable	Wert / Standard	Was sie tut
`OAR_VERSION`	`x.y.z`; ungesetzt wird die neueste installiert	Installiert diese Version. Hat Vorrang vor `OAR_CHANNEL`. macOS, Linux und Windows.
`OAR_CHANNEL`	`beta` (unter Windows auch `BETA`; Groß- und Kleinschreibung spielen dort keine Rolle); jeder andere Wert oder ungesetzt ist der stabile Kanal	Folgt dem Beta-Kanal. macOS, Linux und Windows.
`OAR_PORT`	eine Portnummer; ungesetzt bleibt der Port der Config, sonst 3333 (der nächste freie, wenn der belegt ist)	Schreibt diesen Port in die Config, auch über den Port einer bestehenden. Ein belegter Port bricht die Installation ab. Nur macOS und Linux: Der Windows-Installer hat keine, und `oar setup` fragt.
`OAR_NODE`	`private`	Nutzt OARs eigenes Node.js in `~/.oar/runtime/node`, auch wenn deines reichen würde. Nur macOS und Linux.
`OAR_DRY_RUN`	jeder nicht leere Wert, zum Beispiel `1`	Gibt den Plan aus und installiert nichts. Auch `0` gilt als gesetzt. macOS, Linux und Windows.
`OAR_YES`	jeder nicht leere Wert	Dasselbe wie `--yes`: keine Rückfrage vor der Installation. Nur macOS und Linux.
`OAR_STATE_ROOT`	ein Ordner; Standard `~/.oar`	Wo der Installer die Config, die Daten und seine eigenen Ordner ablegt (Wo OAR seine Dateien ablegt). Das Relay und der Befehl `oar` lesen sie auch: siehe unten. Der Installer für macOS und Linux liest sie; unter Windows ignoriert das Skript selbst sie, aber das `oar setup`, das es am Ende ausführt, liest sie.

Das Relay #

Variable	Wert / Standard	Was sie tut
`OAR_STATE_ROOT`	ein Ordner; Standard `~/.oar`, unter Windows `%APPDATA%\oar`	Verschiebt den Zustand einer globalen Installation: `config.json`, `data/` und `logs/`. Setz sie in jeder Shell, in der du `oar` ausführst, sonst sucht der Befehl am Standardort. Ein git-Checkout behält sein eigenes Layout und ignoriert sie.
`COPILOT_WEB_RELAY_CONFIG`	ein Dateipfad; Standard `server/config.json` im Paket	Die Config-Datei, die das Relay liest, wenn du es selbst startest (`node server/server.js`). `oar copilot` nutzt sie, wenn die Datei existiert. `oar start` und der Dienst nutzen die eigene `config.json` der Installation. Siehe Befehl `oar`.
`COPILOT_WEB_RELAY_DATA_DIR`	ein Ordner; Standard `dataDir` aus `config.json`, sonst `server/data`	Der Datenordner (Datenbank, Uploads, Cursor-Agent-Speicher und, Neu in 0.9.17 in `deepseek-claude`, der Claude-Code-Zustand von DeepSeek-Chats). Schlägt `dataDir`. `oar start` und `oar copilot` geben sie an das Relay weiter; der systemd-Dienst und `oar status` nutzen das eigene `data/` der Installation.
`COPILOT_WEB_RELAY_LOG_DIR`	ein Ordner	Der Log-Ordner; Standard `logs` im Zustandsordner einer globalen Installation. Ein Relay, das du selbst startest, legt `relay-console.log` in `logs` von `COPILOT_WEB_RELAY_DATA_DIR` ab, wenn diese gesetzt ist, sonst in `server/logs`, und seine Worker-Logs in `server/logs`.
`COPILOT_WEB_RELAY_NODE`	ein Pfad zu einem `node`-Programm; Standard das Node.js, auf dem das Relay läuft	Das Node.js, mit dem das Relay seine Worker startet. Neu in 0.9.11 Ohne sie laufen Worker auf jeder Plattform auf dem eigenen Node.js des Relays über dessen vollen Pfad, sie starten also auch dann, wenn kein `node` im `PATH` des Relays liegt. Damit läuft auch OARs MCP-Server für die Engine der Copilot-Extension.
`OAR_NO_CONSOLE_LOG`	`1` schaltet es ab; andere Werte tun nichts	Das Relay hört auf, eine Kopie seiner Konsole in `relay-console.log` im Log-Ordner zu führen.
`OAR_NO_UPDATE_CHECK`	`1`	Kontaktiert oar.sh nie, auch nicht für eine manuelle Prüfung (OAR aktualisieren): Die Update-Prüfungen in Settings → General (Einstellungen → Allgemein) antworten, dass Prüfungen abgeschaltet sind, und `oar update` ohne `--to` verweigert. `oar update --to X.Y.Z` funktioniert weiter. Andere Werte tun nichts.
`OAR_UPDATE_MANIFEST_URL`	eine URL; Standard `https://oar.sh/latest.json`	Das Update-Manifest, das das Relay und `oar update` lesen.
`OAR_MCP_SERVER`	`0`, `false`, `off` oder `no` schaltet ihn ab	Hält OARs MCP-Server aus Grok-Sessions und der Engine der Copilot-Extension heraus. Sie bekommen dann die Anleitung für Previews als Text und haben kein Tool `relay_tool`. Die anderen Provider bringen ihre Tools im eigenen Prozess mit und sind nicht betroffen. Siehe Agent-Tools.
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	Millisekunden; Standards 120000, 300000 und 1800000	Wie lange ein Turn still sein darf, bevor er fehlschlägt: wenn nichts unterwegs ist, während einer Modellanfrage und während eines Tool-Aufrufs. `0` heißt kein Limit für diese Phase. Gelesen von den Workern und nicht an einen Worker unter tmux weitergegeben: siehe Welche Variablen die Worker der Agents erreichen und unten.
`COPILOT_WORKSPACE_ROOT_ALLOW_LIST`	Ordner, getrennt durch `:` (`;` unter Windows); ungesetzt ist jeder erlaubt	Die Ordner, in denen eine Konversation starten darf, samt Unterordnern. Schlägt `workspaceRootAllowList`. Ordner, die nicht existieren, fallen mit einer Warnung weg; bleibt keiner übrig, ist jeder Ordner erlaubt. Eine leere Variable überlässt dem Config-Key die Entscheidung. Siehe Eine Konversation starten.
`COPILOT_REMOTE_<FLAG>`	`1`, `true`, `yes`, `on` oder `0`, `false`, `no`, `off`	Legt ein Feature-Flag fest. Siehe unten.
`OAR_HOST_SUSPEND_DRY_RUN`	`1`, `true`, `yes` oder `on`	Suspend host (Host in den Ruhezustand versetzen; Windows) schreibt den Ruhezustand ins Log und schickt den Rechner nicht schlafen. Zum Ausprobieren des Ablaufs.

Timer für hängende Turns #

Die drei Variablen OAR_TURN_STALL_* lesen die Worker von GitHub Copilot und OpenAI auf der SDK-Engine, von Cursor und von Grok. Ein Turn, der länger still ist als das Fenster seiner aktuellen Phase, schlägt mit einer Systemnotiz fehl; die Tabelle in Turns und die Queue zeigt, was du siehst.

Ein Wert muss eine Zahl von 0 oder mehr sein. Alles andere wird ignoriert, und der Standard gilt.
Setzt du nur OAR_TURN_STALL_IDLE_MS, behalten das Modell- und das Tool-Fenster ihr Verhältnis dazu: 240000 verdoppelt beide Standards. Setz sie ebenfalls, um sie festzulegen. Ein Leerlauffenster von 0 bringt beide auf 0, wenn du sie nicht setzt, also kein Limit in allen drei Phasen.
Claude und Neu in 0.9.17 DeepSeek, das auf dem Claude-Worker läuft, protokollieren einen stillen Turn nur und beenden ihn nie. Für sie hat OAR_TURN_STALL_MODEL_MS den Standard 600000, und ihr Tool-Fenster skaliert auf dieselbe Weise mit OAR_TURN_STALL_IDLE_MS. Ein Wert dort, der gesetzt, aber leer oder keine Zahl ist, ergibt 300000 (skaliert mit dem Leerlauffenster), nicht 600000.
Die Extension-Engine und Claude Cloud lesen diese Variablen nicht.
Bei Grok schaltet ein Leerlauffenster von 0 die Überwachung nicht ab: Alle drei Fenster gehen auf ihre Standards zurück, und OAR_TURN_STALL_MODEL_MS und OAR_TURN_STALL_TOOL_MS werden ignoriert.
Die Worker lesen die Variablen, unter tmux wirken sie also nicht (siehe oben).

Feature-Flags #

Der Tab Features in den Einstellungen zeigt die Flags. Eine Variable legt ein Flag auf einen Wert fest, egal, was der Tab gespeichert hat; das Relay liest sie beim Start. Schreib den Namen des Flags in Großbuchstaben hinter COPILOT_REMOTE_. Der Wert ist 1, true, yes oder on für an und 0, false, no oder off für aus, in beliebiger Schreibweise; alles andere wird ignoriert, und der gespeicherte Wert bleibt. Diese vier Flags gibt es:

Variable	Beschriftung im Tab	Standard
`COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED`	Session worker routing (Session-Worker-Routing)	an
`COPILOT_REMOTE_SESSION_WORKER_CONTINUATION_ROUTING_ENABLED`	Continuation answer routing (Routing von Fortsetzungsantworten)	an
`COPILOT_REMOTE_SESSION_WORKER_FALLBACK_RESTART_ENABLED`	Worker fallback restart (reserved) (Worker-Neustart als Fallback, reserviert)	aus, und ändert nichts
`COPILOT_REMOTE_IMAGE_CONVERSATION_CONTINUITY_ENABLED`	Generated-image continuity (Kontinuität generierter Bilder)	an

Schaltest du das Session-Worker-Routing ab, ist die SDK-Engine nicht verfügbar.

Previews #

Previews brauchen außerdem einen Block previews und einen eigenen Hostnamen: siehe preview. Jede Variable schlägt denselben Key in diesem Block.

Variable	Wert / Standard	Was sie tut
`COPILOT_PREVIEWS_ENABLED`	`1`/`true` oder `0`/`false`	Schaltet Previews an oder aus. Jeder andere Wert überlässt `previews.enabled` die Entscheidung.
`COPILOT_PREVIEWS_PORT`	eine Portnummer	Der Port des Preview-Listeners. `0` nimmt einen freien Port; sonst 1024 oder höher und kein Port des Relays. Ein unbrauchbarer Wert überlässt dem Key `port` die Entscheidung. Ohne Variable und ohne Key `port` ist es der Port des Relays plus eins.
`COPILOT_PREVIEWS_BIND_HOST`	eine Adresse; Standard `127.0.0.1`	Die Adresse, an die der Preview-Listener bindet. Eine andere Adresse als Loopback braucht außerdem `previews.allowPublicBind: true` in `config.json`, sonst bleiben Previews aus.
`COPILOT_PREVIEWS_PUBLIC_BASE_URL`	eine `http(s)`-URL	Die öffentliche Adresse der Previews. Pflicht, wenn Previews an sind, und ihr Hostname muss sich von dem des Relays unterscheiden. Ein Wert, der keine `http(s)`-URL ist, gilt als fehlend; der Key wird nicht stattdessen genutzt.
`COPILOT_PREVIEWS_ALLOWED_TARGET_HOSTS`	Hostnamen, getrennt durch Kommas	Die Hosts neben dem eigenen Rechner des Relays, auf die eine Port-Preview zeigen darf. Eine gesetzte, aber leere Variable bedeutet eine leere Liste und ignoriert `allowedTargetHosts`.

Der Cloudflare-Tunnel #

Für den Block cloudflaredTunnel in config.json und die Marker-Header jedes Tunnels. Jede Variable COPILOT_CLOUDFLARED_* schlägt ihren Key; die Marker-Header werden zusammengeführt.

Variable	Wert / Standard	Was sie tut
`COPILOT_CLOUDFLARED_MODE`	`managed` oder `disabled`	Überschreibt `cloudflaredTunnel.mode` (Cloudflare Tunnel). Jeder andere Wert wird ignoriert. `managed` braucht ein Token.
`COPILOT_CLOUDFLARED_TOKEN`	ein Tunnel-Token	Überschreibt `cloudflaredTunnel.token`.
`COPILOT_CLOUDFLARED_BINARY`	ein Name oder Pfad; Standard `cloudflared` aus dem `PATH`	Überschreibt `cloudflaredTunnel.binary`.
`COPILOT_TUNNEL_MARKER_HEADERS`	Header-Namen, getrennt durch Kommas	Weitere Marker-Header neben `cf-ray`, durch die eine Anfrage als durch einen Tunnel gekommen gilt: Der Pfadschutz des Session-Workers weist sie ab, und ihre falschen Tokens zählen zur Anmeldesperre. Neu in 0.9.11 Werden zu `tunnelMarkerHeaders` in `config.json` hinzugefügt, nicht dadurch ersetzt: `tunnelMarkerHeaders: []` schaltet diese Variable nicht mehr ab.

Provider #

GitHub Copilot #

Wie die CLI gefunden wird, steht unter GitHub Copilot.

Variable	Wert / Standard	Was sie tut
`COPILOT_SDK_PATH`	ein Ordner	Der Ordner `copilot-sdk`, den die Worker der SDK-Engine laden, statt des Ordners neben der neuesten CLI im Paket-Cache. Die eigene Modellliste des Relays und der Session-Import lesen sie nicht.
`COPILOT_WEB_RELAY_CLI_EXECUTABLE`, dann `COPILOT_CLI_EXECUTABLE`, dann `COPILOT_CLI_PATH`	ein Programm; Standard `copilot`	Die Copilot CLI, die die Extension-Engine unter Linux und macOS ausführt (Windows führt immer `gh copilot` aus). Die erste schlägt `cliPath` in `config.json`.
`COPILOT_CONFIG_HOME`	ein Ordner; Standard `~/.copilot`	Wo `oar copilot` seinen Extension-Wrapper ablegt.
`COPILOT_PKG_DIR`	ein Ordner	Ein zusätzlicher Paket-Cache, der durchsucht wird.
`XDG_CACHE_HOME`, `XDG_DATA_HOME`	Ordner	Unter Linux, wo die zwei Standard-Paket-Caches liegen (jeweils `copilot/pkg` darin).
`GH_TOKEN`, `GITHUB_TOKEN`	ein GitHub-Token	Wird für die Copilot-Karte in Check Usage (Verbrauch prüfen) genutzt, statt des Ergebnisses von `gh auth token`. `GH_TOKEN` wird zuerst gelesen.
`COPILOT_SESSION_STATE_DIR`	ein Ordner; Standard `~/.copilot/session-state`	Der Session-State-Ordner der Copilot CLI, falls er woanders liegt. Wird nur genutzt, wenn dieser Ordner existiert.

OAR_MCP_SERVER und COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED gelten auch für Copilot (siehe oben).

OpenAI #

API-Key und Basis-URL stellst du in Settings → Providers → OpenAI (Einstellungen → Provider → OpenAI) ein; dafür gibt es keine Variable. Zwei Variablen passen die Token-Obergrenzen von OpenAI auf der SDK-Engine an; siehe OpenAI.

Variable	Wert / Standard	Was sie tut
`COPILOT_PROVIDER_MAX_PROMPT_TOKENS`	eine positive ganze Zahl	Die Prompt-Obergrenze für das Modell, statt OARs Tabelle. Ein unbrauchbarer Wert wird protokolliert und ignoriert.
`COPILOT_PROVIDER_MAX_OUTPUT_TOKENS`	eine positive ganze Zahl	Dasselbe für die Ausgabe.

Der Ordner für generierte Bilder folgt COPILOT_SESSION_STATE_DIR.

Claude #

Siehe Claude.

Variable	Wert / Standard	Was sie tut
`CLAUDE_CONFIG_DIR`	ein Ordner; Standard `~/.claude`	Der Claude-Konfigurationsordner: die Anmeldung und wo Session-Ordner gesucht werden. Neu in 0.9.17 Nicht für DeepSeek-Chats: Deren Claude Code hält seinen Zustand in `deepseek-claude` im Datenordner (DeepSeek). Neu in 0.9.18 Claude-API-Chats nutzen ihn wie Claude-Chats.
`CLAUDE_CODE_EXECUTABLE`	ein Dateipfad	Das Claude-Code-Programm, das die Worker nutzen, statt des mit dem Agent SDK gebündelten Builds. Eine Installation oder ein Update aus dem Panel setzt sie, speichert das Programm in `config.json`, und ab dann hat dieses Programm bei jedem Start Vorrang vor deiner Variable. Die Anmeldung führt `claude` aus dem `PATH` aus.
`CLAUDE_CODE_OAUTH_TOKEN`	ein Claude-Login-Token	Wird von Claude Code statt der Anmeldung in `CLAUDE_CONFIG_DIR` gelesen. Neu in 0.9.17 Claude-Worker bekommen es auch unter tmux. Welche Worker es bekommen: siehe Claude Cloud.
`ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`	ein Anthropic-Key oder -Token	Neu in 0.9.17 An keinen Worker weitergegeben. Ein Claude-Chat läuft auf der Claude-Anmeldung des Hosts (der Login-Datei der CLI oder `CLAUDE_CODE_OAUTH_TOKEN`), nie auf einem Key in der Umgebung des Relays. Vor 0.9.17 bekam jeder Worker sie, und Claude Code zog jede davon der Claude-Anmeldung vor. Neu in 0.9.18 Ein Claude-API-Chat läuft auf dem Key, der in Settings → Providers → Claude API (Einstellungen → Provider → Claude API) gespeichert ist, nicht auf diesen.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	von OAR gesetzt	Neu in 0.9.12 Nicht aus der Umgebung des Relays gelesen: OAR setzt sie für jede Claude-Session, die es startet, und Neu in 0.9.17 jede DeepSeek-Session, aus Claude background command limit (Limit für Claude-Hintergrundbefehle) (das Limit, 8 h und 2 Min.). Siehe Limit für Hintergrundbefehle.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	eine Token-Zahl	Gelesen von Claude Code, nicht von OAR: Sie setzt das Auto-Kompaktierungsfenster. Meldet Claude Code, dass es das Fenster von dort genommen hat, lautet die Zeile unter dem Schieberegler from CLAUDE_CODE_AUTO_COMPACT_WINDOW (aus CLAUDE_CODE_AUTO_COMPACT_WINDOW). Nicht an einen Worker unter tmux weitergegeben. Neu in 0.9.17 Ein DeepSeek-Chat ignoriert sie (DeepSeek). Siehe Kompaktieren.

Claude API Neu in 0.9.18 #

Claude API hat keine eigene Variable. Den Key stellst du in Settings → Providers → Claude API ein; ein ANTHROPIC_API_KEY in der Umgebung des Relays wird nicht genutzt. Das Relay gibt den gespeicherten Key nur an Claude-API-Worker, und deren Claude Code bekommt ihn als sein ANTHROPIC_API_KEY, in seiner eigenen Umgebung. Siehe Claude API.

Ein Claude-API-Chat führt Claude Code auf dem Relay-Host aus, die Claude-Variablen gelten also für ihn, mit diesen Unterschieden:

Variable	In einem Claude-API-Chat
`CLAUDE_CONFIG_DIR`	Genutzt, wie bei Claude: Die Chats teilen sich den Claude-Konfigurationsordner.
`CLAUDE_CODE_EXECUTABLE`	Genutzt, wie bei Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Von OAR aus Claude background command limit gesetzt, wie bei Claude.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Ignoriert.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, jedes `ANTHROPIC_*`	Ignoriert: OAR richtet Claude Code mit dem gespeicherten Key auf `https://api.anthropic.com` aus.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Ignoriert: OAR setzt den Effort und die Modelle aus dem Chat.
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Ignoriert: Sie würde Claude Code den Modus plan verlassen und jeden Shell-Befehl in einer Sandbox ausführen lassen.

Claude Cloud #

Siehe Claude Cloud.

Variable	Wert / Standard	Was sie tut
`CLAUDE_CODE_OAUTH_TOKEN`	ein Claude-Login-Token	Wird für Claude Cloud statt der Zugangsdaten-Datei der CLI genutzt, vom Relay und seinen Cloud-Workern. Neu in 0.9.17 Es erreicht nur Claude-Cloud- und Claude-Worker, auf jeder Plattform: unter tmux über eine Datei, die nur der Benutzer des Relays lesen kann, ohne tmux in der Umgebung, die sie erben. Die Worker von GitHub Copilot, OpenAI, Cursor, Grok und DeepSeek und Neu in 0.9.18 die Claude-API-Worker starten ohne es. Vor 0.9.17 bekam es jeder ohne tmux gestartete Worker, und unter tmux behielt ein tmux-Server, den ein Start angelegt hatte, es für jede spätere Session. Ein Claude-Chat auf einem Host, der sich nur mit dem Token anmeldet, bekommt es jetzt auch unter tmux.
`CLAUDE_CONFIG_DIR`	ein Ordner; Standard `~/.claude`	Woher die Anmeldung der CLI (`.credentials.json`) gelesen wird.
`OAR_CLAUDE_CLOUD_BRANCH_LOOKUP`	`off`, `0`, `false` oder `no` (beliebige Schreibweise)	Hindert die Branch-Liste in New Chat (Neuer Chat) daran, git zu fragen. Jeder andere Wert lässt sie an.

DeepSeek #

Neu in 0.9.17 DeepSeek hat keine eigene Variable. API-Key und Basis-URL stellst du in Settings → Providers → DeepSeek (Einstellungen → Provider → DeepSeek) ein, die Basis-URL unter Advanced (Erweitert). Ein DEEPSEEK_API_KEY oder DEEPSEEK_BASE_URL in der Umgebung des Relays wird nicht genutzt: Das Relay gibt DeepSeek-Workern die gespeicherten Werte, und kein anderer Worker bekommt einen davon. Siehe DeepSeek.

Ein DeepSeek-Chat führt Claude Code auf dem Relay-Host aus, die Claude-Variablen oben spielen also eine Rolle, aber nicht alle:

Variable	In einem DeepSeek-Chat
`CLAUDE_CODE_EXECUTABLE`	Genutzt, wie bei Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Von OAR aus Claude background command limit gesetzt, wie bei Claude.
`CLAUDE_CONFIG_DIR`	Ignoriert. Claude Code hält seinen Zustand in `deepseek-claude` im Datenordner (Ordner und Session).
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Ignoriert.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, jedes `ANTHROPIC_*`	Ignoriert: OAR richtet Claude Code mit dem gespeicherten Key auf den Endpunkt von DeepSeek aus.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Ignoriert: OAR setzt den Effort und die Modelle aus dem Chat (Reasoning-Effort, Modelle).
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Ignoriert: Sie würde Claude Code den Modus plan zugunsten seines Standardmodus verlassen lassen, sodass der Agent Dateien bearbeiten könnte, und jeden Shell-Befehl in einer Sandbox ausführen lassen.
`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`	Von OAR auf `1` gesetzt, egal, was deine sagt: Der eigene Verkehr von Claude Code zu Anthropic (Updates, Telemetrie) ist aus.

Die Einstellungen des Relays für seinen Worker (die Art des Workers, die Ordner und die Tools-Datei des Relays, SESSION_ID und jede Variable COPILOT_WEB_RELAY_*, COPILOT_PROVIDER_*, DEEPSEEK_* und OAR_*) bleiben beim Worker: Weder Claude Code noch die Befehle, die sein Agent ausführt, sehen sie. Der Key selbst erreicht Claude Code als dessen Token für den Endpunkt von DeepSeek, die Befehle des Agents können ihn also lesen; siehe Wo der Key liegt. Deine übrigen Variablen erreichen es so, wie sie einen Claude-Chat erreichen.

Cursor #

Der Cursor-API-Key wird in Settings → Providers → Cursor (Einstellungen → Provider → Cursor) gespeichert. Ein CURSOR_API_KEY in der Umgebung des Relays wird nicht genutzt: Das Relay gibt seinen Workern den gespeicherten Key. Siehe Cursor.

Variable	Wert / Standard	Was sie tut
`CURSOR_SESSION_TOKEN`	ein Dashboard-Session-Token	Für die Live-Planbalken (Check Usage). Ein im Panel gespeichertes Token hat Vorrang davor, und sie hat Vorrang vor der Anmeldung der Cursor-App.
`CURSOR_AGENT_STORE_DIR`	ein Ordner; Standard `cursor-agents` im Datenordner des Relays (Neu in 0.9.14; vorher `data/cursor-agents` im Server-Ordner des Relays)	Wo der Agent-Zustand je Konversation liegt.

Grok #

Siehe Grok.

Variable	Wert / Standard	Was sie tut
`GROK_CLI_COMMAND`	ein Programmname oder -pfad; Standard `grok`	Das Grok-Programm für Anmeldung, Modellerkennung und die Worker. Ist sie nicht gesetzt, wird `GROK_COMMAND` gelesen; das Relay gibt die eine oder die andere als `GROK_CLI_COMMAND` an die Worker weiter, auch unter tmux. Eine Installation oder ein Update aus dem Panel speichert das Programm in `config.json`, und ab dann hat es bei jedem Start Vorrang vor der Variable.
`GROK_ALWAYS_APPROVE`	`0`; Standard `1`	`0` startet Grok ohne `--always-approve`; OAR beantwortet dann jede Berechtigungsanfrage mit einmaligem Erlauben. Unter tmux an Worker weitergegeben.
`XAI_API_KEY`	ein xAI-Key	Gelesen von der Grok CLI, nicht von OAR, als Alternative zu ihrer Anmeldung. Die Kontozeile kennt nur eine Anmeldung über die CLI. Nicht an einen Worker unter tmux weitergegeben.

Nicht für dich #

Im Quellcode und in Logs tauchen weitere Namen auf. Sie sind keine Einstellungen: die Stub- und Test-Hooks (*_STUB_*, *_ALLOW_STUB_SPAWN, COPILOT_WEB_RELAY_DISABLE_CLI_SPAWN, OAR_PACKAGE_SPEC, OAR_CLAUDE_CLOUD_API_BASE_URL, Neu in 0.9.18 OAR_ANTHROPIC_API_BASE_URL, OAR_HYGIENE_DENYLIST); die Variablen, die das Relay für seine eigenen Worker-Prozesse setzt (COPILOT_WEB_RELAY_WORKER_KIND, *_RELAY_MODEL, SESSION_ID, COPILOT_WEB_RELAY_ROOT, COPILOT_WEB_RELAY_SERVER_DIR, OAR_MCP_SERVER_ATTACHED und die übrigen COPILOT_PROVIDER_*, die das Relay aus den OpenAI-Einstellungen füllt, und Neu in 0.9.17 DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL und DEEPSEEK_CLAUDE_CONFIG_DIR, die es aus den DeepSeek-Einstellungen füllt, und Neu in 0.9.18 OAR_CLAUDE_API_KEY und CLAUDE_API_RELAY_MODEL, die es aus den Claude-API-Einstellungen füllt; die Keys gehen an einen Worker unter tmux über die Datei, die nur der Besitzer lesen kann); und die Stellschrauben für Entwickler (COPILOT_SDK_RELAY_*, CLAUDE_RELAY_*, OAR_BOOT_REPORTING_WINDOW_MS, OAR_RELAY_RESTART_MAX_WAIT_MS, COPILOT_WEB_RELAY_CLAUDE_AUTH_BIN, COPILOT_WEB_RELAY_CLI_BIN_DIR, COPILOT_WEB_RELAY_*_WORKER_PATH); GROK_DISABLE_AUTOUPDATER, das OAR für Grok auf 1 setzt; und COPILOT_WORKSPACE_ROOT, das die Startprogramme setzen. Das Menü von oar beachtet NO_COLOR. Lass den Rest in Ruhe.