Variables d’environnement

La plupart des réglages d’OAR se font dans l’interface web ou dans config.json. Les variables d’environnement servent à ce qui doit être connu avant que le relais démarre, ou à ce que vous voulez fixer de l’extérieur : où le relais garde ses fichiers, s’il peut contacter oar.sh, où se trouve le programme d’un fournisseur. Cette page liste les variables qu’un utilisateur peut définir, regroupées par domaine.

Où les définir #

Le relais lit ses variables une seule fois, à son démarrage. Définissez-les dans l’environnement du processus qui démarre le relais, et redémarrez le relais après une modification.

oar start sans service : le relais est démarré en arrière-plan avec l’environnement du shell dans lequel vous avez lancé oar start. Définissez la variable dans ce shell, ou dans le profil que ce shell lit.
Le service utilisateur systemd (oar service install, et l’installateur sous Linux là où une session utilisateur existe) ne lit pas votre shell. Le fichier d’unité qu’il écrit définit COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR (toujours le data/ propre à l’installation, même quand votre shell en définit un autre), COPILOT_WEB_RELAY_LOG_DIR, et le PATH du shell qui a lancé la commande, complété de ~/.local/bin et du dossier de Node.js, et rien d’autre. oar start utilise ce service dès que l’unité existe et qu’une session utilisateur systemd répond ; une variable exportée dans votre shell n’atteint donc pas le relais. OAR n’a aucun réglage pour ajouter des variables à l’unité, et oar service install et oar setup --start réécrivent le fichier d’unité ; une ligne que vous y ajoutez ne dure donc pas. Voir Démarrage automatique et le service.
Le démarrage automatique Windows se règle dans Settings → General → Autostart (Windows) (Réglages → Général → Démarrage automatique sous Windows), à l’ouverture de session ou au démarrage. Il exécute un petit script qui définit COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR et COPILOT_WEB_RELAY_LOG_DIR (celui du démarrage système ajoute aussi le dossier de Node.js au PATH) et démarre le relais. Lui non plus ne copie pas de variables depuis un shell, et OAR n’a aucun réglage pour en ajouter.
Un redémarrage avec oar restart d’un relais qui ne tourne pas en tant que service démarre le nouveau processus avec le même environnement que l’ancien. Pour y changer une variable, lancez oar stop, puis oar start depuis un shell qui la contient.

Les variables de l’installateur sont lues par le script d’installation, sur la ligne de commande qui l’exécute, et non par le relais. Voir Installation.

Quelles variables atteignent les workers des agents #

Chaque conversation tourne dans un processus worker que le relais démarre. La plupart des variables de cette page sont lues par le relais lui-même. Quelques-unes sont lues par le worker, et le fait que la valeur du relais l’atteigne dépend de la façon dont le worker est démarré :

Sans tmux (Windows, et Linux ou macOS où tmux n’est pas installé), le worker est démarré avec l’environnement du relais, moins ce que le relais retire pour chaque worker (voir plus bas). Il suffit de définir la variable pour le relais.
Sous tmux (Linux et macOS avec tmux installé), le relais transmet au worker une liste fixe de variables et rien d’autre. Toute autre variable ne l’atteint pas. Si aucun serveur tmux ne tourne encore, celui qu’un lancement démarre peut garder le reste de l’environnement du relais, mais ne comptez pas dessus.

La liste fixe, pour ce que couvre cette page : 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 et OAR_MCP_SERVER. Ajouté en 0.9.17 Ces variables, et les valeurs d’un lancement (le type de worker, son modèle, son dossier), vont uniquement dans la commande de ce worker, et non plus dans l’environnement qu’un serveur tmux garde pour toutes les sessions suivantes. La commande de chaque worker commence par retirer les variables de la session Claude Code hôte (voir plus bas), ainsi que chaque variable de la liste et chaque clé de fournisseur pour lesquelles ce lancement n’a pas de valeur. Une valeur laissée là par un lancement antérieur, par un relais plus ancien ou par le shell qui a démarré le serveur tmux n’atteint pas le worker.

Ajouté en 0.9.17 CLAUDE_CODE_OAUTH_TOKEN va uniquement aux workers Claude et Claude Cloud, sur toutes les plateformes, sous tmux par un fichier que seul l’utilisateur du relais peut lire. Voir Claude Cloud. Ajouté en 0.9.18 La clé enregistrée pour Claude API va aux seuls workers Claude API, de la même façon. Voir Claude API. ANTHROPIC_API_KEY et ANTHROPIC_AUTH_TOKEN ne vont à aucun worker, sur toutes les plateformes ; sous tmux, la commande du worker les retire aussi, quoi que contiennent le serveur tmux ou votre profil de connexion. Voir Claude.

Lue par le worker	Sous tmux
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	Non transmises. Elles n’ont aucun effet sur un worker qui tourne sous tmux.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW` (lue par Claude Code, que le worker Claude exécute ; le Claude Code d’un chat DeepSeek ou Ajouté en 0.9.18 Claude API ne la reçoit jamais)	Non transmise.
`OAR_MCP_SERVER`, `CLAUDE_CONFIG_DIR`, `CLAUDE_CODE_EXECUTABLE`, `CURSOR_AGENT_STORE_DIR`, `GROK_CLI_COMMAND`, `COPILOT_PROVIDER_MAX_*`	Transmises. Le relais passe `GROK_CLI_COMMAND`, ou `GROK_COMMAND` quand celle-ci n’est pas définie, à chaque worker Grok sous le nom `GROK_CLI_COMMAND`.
`XAI_API_KEY` (lue par la Grok CLI)	Non transmise.
`COPILOT_SDK_PATH`	Transmise : votre valeur, ou le dossier que le relais a résolu. `COPILOT_PKG_DIR` n’est lue que par le relais.

Un relais démarré depuis Claude Code #

Ajouté en 0.9.17 Un relais que vous démarrez depuis un shell d’une session Claude Code (le shell d’un agent, par exemple) a les variables de cette session dans son environnement. Le relais les retire pour chaque worker, avec et sans tmux, afin que le Claude Code d’aucun worker ne se prenne pour une partie de cette session :

par nom : 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 et CLAUDE_ENV_FILE ;
par famille : toutes les CLAUDE_CODE_SESSION_* (dont l’id de session), toutes les CLAUDE_CODE_*_SESSION_ID et toutes les CLAUDE_CODE_MESSAGING_*.

Vos propres réglages sont conservés : toutes les autres variables CLAUDE_CODE_* (comme CLAUDE_CODE_USE_BEDROCK ou CLAUDE_CODE_GIT_BASH_PATH), toutes les autres variables CLAUDE_AGENT_SDK_*, CLAUDE_CONFIG_DIR, et les deux réglages à l’intérieur d’une famille, CLAUDE_CODE_SESSION_START_ANNOUNCEMENTS_BEFORE_PROMPT et CLAUDE_CODE_SESSION_LOG. Le Claude Code d’un chat DeepSeek en reçoit encore moins : voir DeepSeek.

Ce qui l’emporte #

Cela dépend de la variable, et les tableaux le précisent. En bref :

Une variable l’emporte sur config.json pour le dossier de données (dataDir), la liste d’autorisation du workspace, les réglages des aperçus et le token, le binaire et le mode du tunnel. Les en-têtes marqueurs de tunnel des deux sont fusionnés. config.json n’a pas de clé pour le dossier des journaux.
Un programme installé depuis le panneau l’emporte sur la variable pour CLAUDE_CODE_EXECUTABLE et GROK_CLI_COMMAND : le panneau l’enregistre dans config.json et le redéfinit à chaque démarrage du relais.
Une valeur enregistrée dans l’interface web l’emporte sur la variable pour le token de session Cursor. Pour les flags de fonctionnalité, c’est l’inverse : une variable l’emporte sur ce que l’onglet Features (Fonctionnalités) a enregistré.
Il n’y a pas de variable pour le port ni pour le token du relais. Ils se trouvent dans config.json (voir config.json) ; oar setup --port change le port.

L’installateur #

Lues par oar.sh/install (macOS et Linux) et oar.sh/install.ps1 (Windows). Placez-les devant le shell qui exécute le script :

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	Valeur / défaut	Ce qu’elle fait
`OAR_VERSION`	`x.y.z` ; non définie, installe la dernière	Installe cette version. L’emporte sur `OAR_CHANNEL`. macOS, Linux et Windows.
`OAR_CHANNEL`	`beta` (sous Windows aussi `BETA` ; la casse n’y compte pas) ; toute autre valeur, ou non définie, donne le canal stable	Suit le canal beta. macOS, Linux et Windows.
`OAR_PORT`	un numéro de port ; non définie, garde le port de la config, ou 3333 (le suivant libre s’il est pris)	Écrit ce port dans la config, y compris par-dessus le port d’une config existante. Un port occupé arrête l’installation. macOS et Linux uniquement : l’installateur Windows n’en a pas, et `oar setup` pose la question.
`OAR_NODE`	`private`	Utilise le Node.js propre à OAR dans `~/.oar/runtime/node` même quand le vôtre conviendrait. macOS et Linux uniquement.
`OAR_DRY_RUN`	toute valeur non vide, par exemple `1`	Affiche le plan et n’installe rien. Même `0` compte comme définie. macOS, Linux et Windows.
`OAR_YES`	toute valeur non vide	Comme `--yes` : aucune question avant l’installation. macOS et Linux uniquement.
`OAR_STATE_ROOT`	un dossier ; par défaut `~/.oar`	Où l’installateur place la config, les données et ses propres dossiers (Où OAR garde ses fichiers). Le relais et la commande `oar` la lisent aussi : voir plus bas. L’installateur macOS et Linux la lit ; sous Windows, le script lui-même l’ignore, mais le `oar setup` qu’il exécute à la fin la lit.

Le relais #

Variable	Valeur / défaut	Ce qu’elle fait
`OAR_STATE_ROOT`	un dossier ; par défaut `~/.oar`, `%APPDATA%\oar` sous Windows	Déplace l’état d’une installation globale : `config.json`, `data/` et `logs/`. Définissez-la dans chaque shell où vous lancez `oar`, sinon la commande cherche à l’emplacement par défaut. Un checkout git garde sa propre organisation et l’ignore.
`COPILOT_WEB_RELAY_CONFIG`	un chemin de fichier ; par défaut `server/config.json` dans le paquet	Le fichier de config que lit le relais quand vous le démarrez vous-même (`node server/server.js`). `oar copilot` l’utilise quand le fichier existe. `oar start` et le service utilisent le `config.json` propre à l’installation. Voir la commande `oar`.
`COPILOT_WEB_RELAY_DATA_DIR`	un dossier ; par défaut `dataDir` de `config.json`, sinon `server/data`	Le dossier de données (base de données, fichiers envoyés, états des agents Cursor et, Ajouté en 0.9.17 dans `deepseek-claude`, l’état Claude Code des chats DeepSeek). L’emporte sur `dataDir`. `oar start` et `oar copilot` la transmettent au relais ; le service systemd et `oar status` utilisent le `data/` propre à l’installation.
`COPILOT_WEB_RELAY_LOG_DIR`	un dossier	Le dossier des journaux ; par défaut `logs` dans le dossier d’état d’une installation globale. Un relais que vous démarrez vous-même garde `relay-console.log` dans le `logs` de `COPILOT_WEB_RELAY_DATA_DIR` quand celle-ci est définie, sinon dans `server/logs`, et les journaux de ses workers dans `server/logs`.
`COPILOT_WEB_RELAY_NODE`	un chemin vers un programme `node` ; par défaut le Node.js qui fait tourner le relais	Le Node.js avec lequel le relais démarre ses workers. Ajouté en 0.9.11 Sans elle, les workers tournent sur le Node.js du relais lui-même, appelé par son chemin complet sur toutes les plateformes ; ils démarrent donc même quand aucun `node` ne se trouve dans le `PATH` du relais. Ce Node.js exécute aussi le serveur MCP d’OAR pour le moteur d’extension Copilot.
`OAR_NO_CONSOLE_LOG`	`1` désactive la copie ; les autres valeurs ne font rien	Empêche le relais de garder une copie de sa console dans `relay-console.log` dans le dossier des journaux.
`OAR_NO_UPDATE_CHECK`	`1`	Ne contacte jamais oar.sh, même pas pour une vérification manuelle (Mettre à jour OAR) : les vérifications de mise à jour dans Settings → General répondent qu’elles sont désactivées, et `oar update` sans `--to` refuse. `oar update --to X.Y.Z` fonctionne toujours. Les autres valeurs ne font rien.
`OAR_UPDATE_MANIFEST_URL`	une URL ; par défaut `https://oar.sh/latest.json`	Le manifeste de mise à jour que lisent le relais et `oar update`.
`OAR_MCP_SERVER`	`0`, `false`, `off` ou `no` le désactive	Tient le serveur MCP d’OAR à l’écart des sessions Grok et du moteur d’extension Copilot. Ils reçoivent alors les instructions des aperçus sous forme de texte et n’ont pas d’outil `relay_tool`. Les autres fournisseurs embarquent leurs outils dans leur propre processus et ne sont pas concernés. Voir Outils d’agent.
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	millisecondes ; par défaut 120 000, 300 000 et 1 800 000	Combien de temps un turn peut rester silencieux avant d’échouer : sans rien en cours, pendant une requête au modèle et pendant un appel d’outil. `0` signifie aucune limite pour cette phase. Lues par les workers, et non transmises à un worker sous tmux : voir Quelles variables atteignent les workers des agents et plus bas.
`COPILOT_WORKSPACE_ROOT_ALLOW_LIST`	dossiers séparés par `:` (`;` sous Windows) ; non définie, tout est autorisé	Les dossiers dans lesquels une conversation peut démarrer, avec leurs sous-dossiers. L’emporte sur `workspaceRootAllowList`. Les dossiers qui n’existent pas sont écartés avec un avertissement ; s’il n’en reste aucun, tout dossier est autorisé. Une variable vide laisse la clé de config décider. Voir Démarrer une conversation.
`COPILOT_REMOTE_<FLAG>`	`1`, `true`, `yes`, `on` ou `0`, `false`, `no`, `off`	Fixe un flag de fonctionnalité. Voir plus bas.
`OAR_HOST_SUSPEND_DRY_RUN`	`1`, `true`, `yes` ou `on`	Suspend host (Mettre l’hôte en veille) (Windows) écrit la mise en veille dans le journal et ne met pas la machine en veille. Pour essayer le déroulement.

Minuteurs des turns bloqués #

Les trois variables OAR_TURN_STALL_* sont lues par les workers de GitHub Copilot et d’OpenAI sur le moteur SDK, de Cursor et de Grok. Un turn qui reste silencieux plus longtemps que la fenêtre de sa phase en cours échoue avec une note système ; le tableau de la page Les turns et la queue montre ce que vous voyez.

Une valeur doit être un nombre supérieur ou égal à 0. Toute autre valeur est ignorée et la valeur par défaut s’applique.
Si vous ne définissez que OAR_TURN_STALL_IDLE_MS, les fenêtres du modèle et des outils gardent leur proportion avec elle : la régler sur 240000 double les deux valeurs par défaut. Définissez-les aussi pour les fixer. Une fenêtre d’inactivité de 0 met les deux à 0, sauf si vous les définissez, ce qui revient à aucune limite dans les trois phases.
Claude, et Ajouté en 0.9.17 DeepSeek, qui tourne sur le worker Claude, se contentent de journaliser un turn silencieux et ne l’arrêtent jamais. Pour eux, OAR_TURN_STALL_MODEL_MS a une valeur par défaut de 600 000, et leur fenêtre des outils suit OAR_TURN_STALL_IDLE_MS de la même façon. Une valeur définie mais vide ou non numérique y donne 300 000 (mis à l’échelle par la fenêtre d’inactivité), et non 600 000.
Le moteur d’extension et Claude Cloud ne lisent pas ces variables.
Sur Grok, une fenêtre d’inactivité de 0 ne désactive pas la surveillance : les trois fenêtres reviennent à leurs valeurs par défaut, et OAR_TURN_STALL_MODEL_MS et OAR_TURN_STALL_TOOL_MS sont ignorées.
Ce sont les workers qui lisent les variables ; sous tmux, elles n’ont donc aucun effet (voir plus haut).

Flags de fonctionnalité #

L’onglet Features des réglages affiche les flags. Une variable fixe un flag sur une valeur, quoi qu’ait enregistré l’onglet ; le relais la lit au démarrage. Écrivez le nom du flag en majuscules après COPILOT_REMOTE_. La valeur est 1, true, yes ou on pour activé, et 0, false, no ou off pour désactivé, dans n’importe quelle casse ; toute autre valeur est ignorée et la valeur enregistrée reste. Ces quatre flags existent :

Variable	Libellé dans l’onglet	Par défaut
`COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED`	Session worker routing (Routage des workers de session)	activé
`COPILOT_REMOTE_SESSION_WORKER_CONTINUATION_ROUTING_ENABLED`	Continuation answer routing (Routage des réponses de suite)	activé
`COPILOT_REMOTE_SESSION_WORKER_FALLBACK_RESTART_ENABLED`	Worker fallback restart (reserved) (Redémarrage de secours du worker, réservé)	désactivé, et ne change rien
`COPILOT_REMOTE_IMAGE_CONVERSATION_CONTINUITY_ENABLED`	Generated-image continuity (Continuité des images générées)	activé

Désactiver le routage des workers de session rend le moteur SDK indisponible.

Aperçus #

Les aperçus ont aussi besoin d’un bloc previews et d’un nom d’hôte à eux : voir preview. Chaque variable l’emporte sur la même clé de ce bloc.

Variable	Valeur / défaut	Ce qu’elle fait
`COPILOT_PREVIEWS_ENABLED`	`1`/`true` ou `0`/`false`	Active ou désactive les aperçus. Toute autre valeur laisse `previews.enabled` décider.
`COPILOT_PREVIEWS_PORT`	un numéro de port	Le port de l’écouteur des aperçus. `0` prend un port libre ; sinon 1024 ou plus, et pas un port du relais. Une valeur inutilisable laisse la clé `port` décider. Sans variable ni clé `port`, c’est le port du relais plus un.
`COPILOT_PREVIEWS_BIND_HOST`	une adresse ; par défaut `127.0.0.1`	L’adresse sur laquelle l’écouteur des aperçus se lie. Une adresse autre que l’adresse de bouclage exige aussi `previews.allowPublicBind: true` dans `config.json`, sinon les aperçus restent désactivés.
`COPILOT_PREVIEWS_PUBLIC_BASE_URL`	une URL `http(s)`	L’adresse publique des aperçus. Obligatoire quand les aperçus sont activés, et son nom d’hôte doit différer de celui du relais. Une valeur qui n’est pas une URL `http(s)` compte comme absente ; la clé n’est pas utilisée à la place.
`COPILOT_PREVIEWS_ALLOWED_TARGET_HOSTS`	noms d’hôte séparés par des virgules	Les hôtes, en plus de la machine du relais, vers lesquels un aperçu de port peut pointer. Une variable définie mais vide signifie une liste vide et ignore `allowedTargetHosts`.

Le tunnel Cloudflare #

Pour le bloc cloudflaredTunnel de config.json, et les en-têtes marqueurs de tout tunnel. Chaque variable COPILOT_CLOUDFLARED_* l’emporte sur sa clé ; les en-têtes marqueurs sont fusionnés.

Variable	Valeur / défaut	Ce qu’elle fait
`COPILOT_CLOUDFLARED_MODE`	`managed` ou `disabled`	Remplace `cloudflaredTunnel.mode` (Cloudflare Tunnel). Toute autre valeur est ignorée. `managed` exige un token.
`COPILOT_CLOUDFLARED_TOKEN`	un token de tunnel	Remplace `cloudflaredTunnel.token`.
`COPILOT_CLOUDFLARED_BINARY`	un nom ou un chemin ; par défaut `cloudflared` depuis le `PATH`	Remplace `cloudflaredTunnel.binary`.
`COPILOT_TUNNEL_MARKER_HEADERS`	noms d’en-têtes séparés par des virgules	D’autres en-têtes marqueurs, en plus de `cf-ray`, qui font qu’une requête compte comme passée par un tunnel : le garde-fou des chemins des workers de session la refuse, et ses tokens erronés comptent pour le verrouillage de connexion. Ajouté en 0.9.11 Ajoutés à `tunnelMarkerHeaders` dans `config.json`, et non remplacés par celle-ci : `tunnelMarkerHeaders: []` ne désactive plus cette variable.

Fournisseurs #

GitHub Copilot #

Voir GitHub Copilot pour savoir comment la CLI est trouvée.

Variable	Valeur / défaut	Ce qu’elle fait
`COPILOT_SDK_PATH`	un dossier	Le dossier `copilot-sdk` que chargent les workers du moteur SDK, à la place de celui qui se trouve à côté de la CLI la plus récente dans le cache des paquets. La liste de modèles propre au relais et l’import de sessions ne la lisent pas.
`COPILOT_WEB_RELAY_CLI_EXECUTABLE`, puis `COPILOT_CLI_EXECUTABLE`, puis `COPILOT_CLI_PATH`	un programme ; par défaut `copilot`	La CLI Copilot qu’exécute le moteur d’extension sous Linux et macOS (Windows exécute toujours `gh copilot`). La première l’emporte sur `cliPath` dans `config.json`.
`COPILOT_CONFIG_HOME`	un dossier ; par défaut `~/.copilot`	Où `oar copilot` écrit son wrapper d’extension.
`COPILOT_PKG_DIR`	un dossier	Un cache de paquets supplémentaire à explorer.
`XDG_CACHE_HOME`, `XDG_DATA_HOME`	dossiers	Sous Linux, l’emplacement des deux caches de paquets par défaut (`copilot/pkg` dans chacun).
`GH_TOKEN`, `GITHUB_TOKEN`	un token GitHub	Utilisé pour la carte Copilot de Check Usage (Vérifier la consommation), à la place du résultat de `gh auth token`. `GH_TOKEN` est lue en premier.
`COPILOT_SESSION_STATE_DIR`	un dossier ; par défaut `~/.copilot/session-state`	Le dossier d’état des sessions de la CLI Copilot, s’il se trouve ailleurs. Utilisé seulement si ce dossier existe.

OAR_MCP_SERVER et COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED s’appliquent aussi à Copilot (voir plus haut).

OpenAI #

La clé d’API et l’URL de base se règlent dans Settings → Providers → OpenAI (Réglages → Fournisseurs → OpenAI) et n’ont pas de variable. Deux variables ajustent les plafonds de tokens d’OpenAI sur le moteur SDK ; voir OpenAI.

Variable	Valeur / défaut	Ce qu’elle fait
`COPILOT_PROVIDER_MAX_PROMPT_TOKENS`	un entier positif	Le plafond du prompt pour le modèle, à la place du tableau d’OAR. Une valeur inutilisable est journalisée et ignorée.
`COPILOT_PROVIDER_MAX_OUTPUT_TOKENS`	un entier positif	La même chose pour la sortie.

Le dossier des images générées suit COPILOT_SESSION_STATE_DIR.

Claude #

Voir Claude.

Variable	Valeur / défaut	Ce qu’elle fait
`CLAUDE_CONFIG_DIR`	un dossier ; par défaut `~/.claude`	Le dossier de configuration de Claude : la connexion, et l’endroit où sont cherchés les dossiers de session. Ajouté en 0.9.17 Pas pour les chats DeepSeek : leur Claude Code garde son état dans `deepseek-claude` dans le dossier de données (DeepSeek). Ajouté en 0.9.18 Les chats Claude API l’utilisent comme les chats Claude.
`CLAUDE_CODE_EXECUTABLE`	un chemin de fichier	Le programme Claude Code qu’utilisent les workers, à la place de la version fournie avec l’Agent SDK. Une installation ou une mise à jour depuis le panneau la définit, enregistre le programme dans `config.json`, et dès lors ce programme l’emporte sur votre variable à chaque démarrage. La connexion exécute `claude` depuis le `PATH`.
`CLAUDE_CODE_OAUTH_TOKEN`	un token de connexion Claude	Lu par Claude Code à la place de la connexion de `CLAUDE_CONFIG_DIR`. Ajouté en 0.9.17 Les workers Claude le reçoivent aussi sous tmux. Quels workers le reçoivent : voir Claude Cloud.
`ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`	une clé ou un token Anthropic	Ajouté en 0.9.17 Ne sont transmises à aucun worker. Un chat Claude tourne sur la connexion Claude de l’hôte (le fichier de connexion de la CLI, ou `CLAUDE_CODE_OAUTH_TOKEN`), jamais sur une clé présente dans l’environnement du relais. Avant 0.9.17, chaque worker les recevait, et Claude Code préférait l’une ou l’autre à la connexion Claude. Ajouté en 0.9.18 Un chat Claude API tourne sur la clé enregistrée dans Settings → Providers → Claude API (Réglages → Fournisseurs → Claude API), pas sur celles-ci.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	définies par OAR	Ajouté en 0.9.12 Pas lues dans l’environnement du relais : OAR les définit pour chaque session Claude qu’il démarre, et Ajouté en 0.9.17 pour chaque session DeepSeek, à partir de Claude background command limit (Limite des commandes de fond Claude) (la limite, 8 h et 2 min). Voir Limite des commandes de fond.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	un nombre de tokens	Lue par Claude Code, pas par OAR : elle fixe la fenêtre de compactage auto. Quand Claude Code indique qu’il a pris la fenêtre de là, la ligne sous le curseur affiche from CLAUDE_CODE_AUTO_COMPACT_WINDOW (depuis CLAUDE_CODE_AUTO_COMPACT_WINDOW). Non transmise à un worker sous tmux. Ajouté en 0.9.17 Un chat DeepSeek l’ignore (DeepSeek). Voir Compacter une conversation.

Claude API Ajouté en 0.9.18 #

Claude API n’a pas de variable à lui. La clé se règle dans Settings → Providers → Claude API ; une ANTHROPIC_API_KEY présente dans l’environnement du relais n’est pas utilisée. Le relais ne donne la clé enregistrée qu’aux workers Claude API, et leur Claude Code la reçoit comme son ANTHROPIC_API_KEY, dans son propre environnement. Voir Claude API.

Un chat Claude API exécute Claude Code sur l’hôte du relais ; les variables de Claude s’y appliquent donc, avec ces différences :

Variable	Dans un chat Claude API
`CLAUDE_CONFIG_DIR`	Utilisée, comme pour Claude : les chats partagent le dossier de configuration de Claude.
`CLAUDE_CODE_EXECUTABLE`	Utilisée, comme pour Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Définies par OAR à partir de Claude background command limit, comme pour Claude.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Ignorée.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, toutes les `ANTHROPIC_*`	Ignorées : OAR dirige Claude Code vers `https://api.anthropic.com` avec la clé enregistrée.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Ignorées : OAR fixe l’effort et les modèles d’après le chat.
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Ignorée : elle ferait quitter le mode plan à Claude Code et exécuterait chaque commande shell dans un bac à sable.

Claude Cloud #

Voir Claude Cloud.

Variable	Valeur / défaut	Ce qu’elle fait
`CLAUDE_CODE_OAUTH_TOKEN`	un token de connexion Claude	Utilisé pour Claude Cloud à la place du fichier d’identifiants de la CLI, par le relais et ses workers cloud. Ajouté en 0.9.17 Il n’atteint que les workers Claude Cloud et Claude, sur toutes les plateformes : sous tmux par un fichier que seul l’utilisateur du relais peut lire, sans tmux par l’environnement dont ils héritent. Les workers GitHub Copilot, OpenAI, Cursor, Grok et DeepSeek, et Ajouté en 0.9.18 les workers Claude API, sont démarrés sans lui. Avant 0.9.17, chaque worker démarré sans tmux le recevait, et sous tmux, un serveur tmux démarré par un lancement le gardait pour toutes les sessions suivantes. Un chat Claude sur un hôte qui se connecte avec le seul token le reçoit désormais aussi sous tmux.
`CLAUDE_CONFIG_DIR`	un dossier ; par défaut `~/.claude`	L’endroit où est lue la connexion de la CLI (`.credentials.json`).
`OAR_CLAUDE_CLOUD_BRANCH_LOOKUP`	`off`, `0`, `false` ou `no` (toute casse)	Empêche la liste des branches de New Chat (Nouveau chat) d’interroger git. Toute autre valeur la laisse active.

DeepSeek #

Ajouté en 0.9.17 DeepSeek n’a pas de variable à lui. La clé d’API et l’URL de base se règlent dans Settings → Providers → DeepSeek (Réglages → Fournisseurs → DeepSeek), l’URL de base sous Advanced (Avancé). Une DEEPSEEK_API_KEY ou une DEEPSEEK_BASE_URL dans l’environnement du relais n’est pas utilisée : le relais donne aux workers DeepSeek les valeurs enregistrées, et aucun autre worker ne reçoit l’une ou l’autre. Voir DeepSeek.

Un chat DeepSeek exécute Claude Code sur l’hôte du relais ; les variables de Claude ci-dessus comptent donc, mais pas toutes :

Variable	Dans un chat DeepSeek
`CLAUDE_CODE_EXECUTABLE`	Utilisée, comme pour Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Définies par OAR à partir de Claude background command limit, comme pour Claude.
`CLAUDE_CONFIG_DIR`	Ignorée. Claude Code garde son état dans `deepseek-claude` dans le dossier de données (Dossier et session).
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Ignorée.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, toutes les `ANTHROPIC_*`	Ignorées : OAR dirige Claude Code vers l’endpoint de DeepSeek avec la clé enregistrée.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Ignorées : OAR fixe l’effort et les modèles d’après le chat (Effort de raisonnement, Modèles).
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Ignorée : elle ferait passer Claude Code du mode plan à son mode par défaut, si bien que l’agent pourrait modifier des fichiers, et exécuterait chaque commande shell dans un bac à sable.
`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`	Mise à `1` par OAR, quelle que soit votre valeur : le trafic propre de Claude Code vers Anthropic (mises à jour, télémétrie) est coupé.

Les réglages du relais pour son worker (le type de worker, les dossiers du relais et son fichier d’outils, SESSION_ID, et toutes les variables COPILOT_WEB_RELAY_*, COPILOT_PROVIDER_*, DEEPSEEK_* et OAR_*) restent dans le worker : ni Claude Code ni les commandes que lance son agent ne les voient. La clé elle-même atteint Claude Code comme son token pour l’endpoint de DeepSeek ; les commandes de l’agent peuvent donc la lire ; voir Où la clé est conservée. Vos autres variables l’atteignent comme elles atteignent un chat Claude.

Cursor #

La clé d’API Cursor est enregistrée dans Settings → Providers → Cursor (Réglages → Fournisseurs → Cursor). Une CURSOR_API_KEY dans l’environnement du relais n’est pas utilisée : le relais donne à ses workers la clé enregistrée. Voir Cursor.

Variable	Valeur / défaut	Ce qu’elle fait
`CURSOR_SESSION_TOKEN`	un token de session du tableau de bord	Pour les barres du forfait en direct (Check Usage). Un token enregistré dans le panneau l’emporte sur elle, et elle l’emporte sur la connexion de l’app Cursor.
`CURSOR_AGENT_STORE_DIR`	un dossier ; par défaut `cursor-agents` dans le dossier de données du relais (Ajouté en 0.9.14 ; avant, `data/cursor-agents` dans le dossier server du relais)	Où est conservé l’état des agents par conversation.

Grok #

Voir Grok.

Variable	Valeur / défaut	Ce qu’elle fait
`GROK_CLI_COMMAND`	un nom ou un chemin de programme ; par défaut `grok`	Le programme Grok pour la connexion, la découverte des modèles et les workers. `GROK_COMMAND` est lue quand elle n’est pas définie ; le relais passe l’une ou l’autre aux workers sous le nom `GROK_CLI_COMMAND`, sous tmux aussi. Une installation ou une mise à jour depuis le panneau enregistre le programme dans `config.json`, et dès lors il l’emporte sur la variable à chaque démarrage.
`GROK_ALWAYS_APPROVE`	`0` ; par défaut `1`	`0` démarre Grok sans `--always-approve` ; OAR répond alors à chaque demande de permission par allow-once (autoriser une fois). Transmise aux workers sous tmux.
`XAI_API_KEY`	une clé xAI	Lue par la Grok CLI, pas par OAR, comme alternative à sa connexion. La ligne du compte ne connaît qu’une connexion faite par la CLI. Non transmise à un worker sous tmux.

Pas pour vous #

D’autres noms apparaissent dans le code source et dans les journaux. Ce ne sont pas des réglages : les points d’accroche de stub et de test (*_STUB_*, *_ALLOW_STUB_SPAWN, COPILOT_WEB_RELAY_DISABLE_CLI_SPAWN, OAR_PACKAGE_SPEC, OAR_CLAUDE_CLOUD_API_BASE_URL, Ajouté en 0.9.18 OAR_ANTHROPIC_API_BASE_URL, OAR_HYGIENE_DENYLIST) ; les variables que le relais définit pour ses propres processus worker (COPILOT_WEB_RELAY_WORKER_KIND, *_RELAY_MODEL, SESSION_ID, COPILOT_WEB_RELAY_ROOT, COPILOT_WEB_RELAY_SERVER_DIR, OAR_MCP_SERVER_ATTACHED et les autres COPILOT_PROVIDER_*, que le relais remplit à partir des réglages OpenAI, ainsi que Ajouté en 0.9.17 DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL et DEEPSEEK_CLAUDE_CONFIG_DIR, qu’il remplit à partir des réglages DeepSeek, et Ajouté en 0.9.18 OAR_CLAUDE_API_KEY et CLAUDE_API_RELAY_MODEL, qu’il remplit à partir des réglages Claude API ; les clés vont à un worker sous tmux par le fichier réservé au propriétaire) ; les paramètres de réglage fin pour les développeurs (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, qu’OAR met à 1 pour Grok ; et COPILOT_WORKSPACE_ROOT, que définissent les lanceurs. Le menu oar respecte NO_COLOR. Ne touchez pas au reste.