Variables de entorno

La mayor parte de OAR se configura en la interfaz web o en config.json. Las variables de entorno son para lo que hay que saber antes de que el relay esté en marcha, o para lo que quieres fijar desde fuera: dónde guarda el relay sus archivos, si puede contactar con oar.sh, dónde está el programa de un proveedor. Esta página enumera las variables que un usuario puede definir, agrupadas por área.

Dónde definirlas #

El relay lee sus variables una sola vez, al arrancar. Defínelas en el entorno del proceso que inicia el relay, y vuelve a iniciar el relay después de un cambio.

oar start sin servicio: el relay se inicia en segundo plano con el entorno de la shell en la que ejecutaste oar start. Define la variable en esa shell, o en el perfil que lee esa shell.
El servicio de usuario de systemd (oar service install, y el instalador en Linux cuando existe una sesión de usuario) no lee tu shell. El archivo de unidad que escribe define COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR (siempre el data/ propio de la instalación, aunque tu shell defina otro), COPILOT_WEB_RELAY_LOG_DIR y el PATH de la shell que ejecutó el comando, con ~/.local/bin y la carpeta de Node.js añadidas, y nada más. oar start usa este servicio siempre que la unidad existe y responde una sesión de usuario de systemd, así que una variable exportada en tu shell no llega al relay. OAR no tiene ningún ajuste para añadir más variables a la unidad, y oar service install y oar setup --start vuelven a escribir el archivo de unidad, así que una línea que le añadas no dura. Consulta Inicio automático y el servicio.
El inicio automático de Windows se configura en Settings → General → Autostart (Windows) (Ajustes → General → Inicio automático, Windows), al iniciar sesión o al encender. Ejecuta un pequeño script que define COPILOT_WEB_RELAY_CONFIG, COPILOT_WEB_RELAY_DATA_DIR y COPILOT_WEB_RELAY_LOG_DIR (el del encendido añade además la carpeta de Node.js al PATH) e inicia el relay. Tampoco copia variables de ninguna shell, y OAR no tiene ningún ajuste para añadir más.
Un reinicio con oar restart de un relay que no se ejecuta como servicio inicia el proceso nuevo con el mismo entorno que el antiguo. Para cambiar ahí una variable, ejecuta oar stop y luego oar start desde una shell que la tenga.

Las variables del instalador las lee el script de instalación, en la línea de comandos que lo ejecuta, y no el relay. Consulta Instalar OAR.

Qué variables llegan a los workers de los agentes #

Cada conversación se ejecuta en un proceso worker que inicia el relay. La mayoría de las variables de esta página las lee el propio relay. Unas pocas las lee el worker, y que el valor del relay le llegue depende de cómo se inicie el worker:

Sin tmux (Windows, y Linux o macOS donde tmux no está instalado), el worker se inicia con el entorno del relay, menos lo que el relay quita para todos los workers (ver abajo). Basta con definir la variable para el relay.
Con tmux (Linux y macOS con tmux instalado), el relay pasa al worker una lista fija de variables y nada más. Ninguna otra variable le llega. Si todavía no hay ningún servidor tmux en marcha, el que inicia un lanzamiento puede conservar el resto del entorno del relay, pero no cuentes con ello.

La lista fija, en lo que cubre esta página: 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 y OAR_MCP_SERVER. Nuevo en 0.9.17 Estas, y los valores de un lanzamiento (el tipo de worker, su modelo, su carpeta), van solo al comando propio de ese worker, ya no al entorno que un servidor tmux conserva para todas las sesiones posteriores. El comando de cada worker empieza eliminando las variables de la sesión de Claude Code del host (ver abajo) y cada variable de la lista, y cada clave de proveedor, para la que este lanzamiento no tiene valor. Un valor que haya dejado allí un lanzamiento anterior, un relay más antiguo o la shell que inició el servidor tmux no llega al worker.

Nuevo en 0.9.17 CLAUDE_CODE_OAUTH_TOKEN va solo a los workers de Claude y Claude Cloud, en todas las plataformas, y con tmux mediante un archivo que solo puede leer el usuario del relay. Consulta Claude Cloud. Nuevo en 0.9.18 La clave guardada para Claude API va solo a los workers de Claude API, de la misma manera. Consulta Claude API. ANTHROPIC_API_KEY y ANTHROPIC_AUTH_TOKEN no van a ningún worker, en ninguna plataforma; con tmux, el comando del worker además las elimina, tenga lo que tenga el servidor tmux o tu perfil de inicio de sesión. Consulta Claude.

Lo lee el worker	Con tmux
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	No se pasan. No tienen efecto en un worker que se ejecuta con tmux.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW` (lo lee Claude Code, que ejecuta el worker de Claude; el Claude Code de un chat de DeepSeek o Nuevo en 0.9.18 de Claude API nunca la recibe)	No se pasa.
`OAR_MCP_SERVER`, `CLAUDE_CONFIG_DIR`, `CLAUDE_CODE_EXECUTABLE`, `CURSOR_AGENT_STORE_DIR`, `GROK_CLI_COMMAND`, `COPILOT_PROVIDER_MAX_*`	Se pasan. El relay entrega `GROK_CLI_COMMAND`, o `GROK_COMMAND` cuando aquella no está definida, a cada worker de Grok como `GROK_CLI_COMMAND`.
`XAI_API_KEY` (la lee la CLI de Grok)	No se pasa.
`COPILOT_SDK_PATH`	Se pasa: tu valor, o la carpeta que resolvió el relay. `COPILOT_PKG_DIR` solo la lee el relay.

Un relay iniciado desde dentro de Claude Code #

Nuevo en 0.9.17 Un relay que inicias desde una shell de una sesión de Claude Code (la shell de un agente, por ejemplo) tiene las variables de esa sesión en su entorno. El relay las quita para todos los workers, con y sin tmux, para que el Claude Code de ningún worker se crea parte de esa sesión:

por nombre: 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 y CLAUDE_ENV_FILE;
por familia: cada CLAUDE_CODE_SESSION_* (entre ellas el id de sesión), cada CLAUDE_CODE_*_SESSION_ID y cada CLAUDE_CODE_MESSAGING_*.

Tus propios ajustes se mantienen: cualquier otra variable CLAUDE_CODE_* (como CLAUDE_CODE_USE_BEDROCK o CLAUDE_CODE_GIT_BASH_PATH), cualquier otra variable CLAUDE_AGENT_SDK_*, CLAUDE_CONFIG_DIR, y los dos ajustes que hay dentro de una familia, CLAUDE_CODE_SESSION_START_ANNOUNCEMENTS_BEFORE_PROMPT y CLAUDE_CODE_SESSION_LOG. El Claude Code de un chat de DeepSeek recibe todavía menos: consulta DeepSeek.

Qué gana #

Depende de la variable, y las tablas dicen cuál. En resumen:

Una variable gana a config.json para la carpeta de datos (dataDir), la lista de carpetas permitidas del workspace, los ajustes de vistas previas y el token, el binario y el modo del túnel. Las cabeceras marcadoras de túnel de ambos se combinan. No hay ninguna clave de carpeta de registros en config.json.
Un programa instalado desde el panel gana a la variable para CLAUDE_CODE_EXECUTABLE y GROK_CLI_COMMAND: el panel lo guarda en config.json y lo vuelve a fijar en cada arranque del relay.
Un valor guardado en la interfaz web gana a la variable para el token de sesión de Cursor. Con los flags de funciones es al revés: una variable gana a lo que guardó la pestaña Features (Funciones).
No hay ninguna variable para el puerto ni el token del relay. Están en config.json (consulta config.json); oar setup --port cambia el puerto.

El instalador #

Las leen oar.sh/install (macOS y Linux) y oar.sh/install.ps1 (Windows). Ponlas delante de la shell que ejecuta el 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	Valor / por defecto	Qué hace
`OAR_VERSION`	`x.y.z`; sin definir instala la más reciente	Instala esa versión. Gana a `OAR_CHANNEL`. macOS, Linux y Windows.
`OAR_CHANNEL`	`beta` (en Windows también `BETA`; allí no importan mayúsculas ni minúsculas); cualquier otro valor, o sin definir, es el canal estable	Sigue el canal beta. macOS, Linux y Windows.
`OAR_PORT`	un número de puerto; sin definir conserva el puerto de la configuración, o 3333 (el siguiente libre si ese está ocupado)	Escribe este puerto en la configuración, también encima del puerto de una existente. Un puerto en uso detiene la instalación. Solo macOS y Linux: el instalador de Windows no la tiene, y `oar setup` pregunta.
`OAR_NODE`	`private`	Usa el Node.js propio de OAR en `~/.oar/runtime/node` aunque el tuyo sirva. Solo macOS y Linux.
`OAR_DRY_RUN`	cualquier valor no vacío, por ejemplo `1`	Imprime el plan y no instala nada. Incluso `0` cuenta como definida. macOS, Linux y Windows.
`OAR_YES`	cualquier valor no vacío	Lo mismo que `--yes`: ninguna pregunta antes de instalar. Solo macOS y Linux.
`OAR_STATE_ROOT`	una carpeta; por defecto `~/.oar`	Dónde pone el instalador la configuración, los datos y sus propias carpetas (Dónde guarda OAR sus archivos). El relay y el comando `oar` también la leen: consulta más abajo. El instalador de macOS y Linux la lee; en Windows el script en sí la ignora, pero el `oar setup` que ejecuta al final sí la lee.

El relay #

Variable	Valor / por defecto	Qué hace
`OAR_STATE_ROOT`	una carpeta; por defecto `~/.oar`, `%APPDATA%\oar` en Windows	Traslada el estado de una instalación global: `config.json`, `data/` y `logs/`. Defínela en cada shell en la que ejecutes `oar`, o el comando buscará en el sitio predeterminado. Un checkout de git mantiene su propia estructura y la ignora.
`COPILOT_WEB_RELAY_CONFIG`	una ruta de archivo; por defecto `server/config.json` en el paquete	El archivo de configuración que lee el relay, cuando lo inicias tú (`node server/server.js`). `oar copilot` la usa cuando el archivo existe. `oar start` y el servicio usan el `config.json` propio de la instalación. Consulta Comando `oar`.
`COPILOT_WEB_RELAY_DATA_DIR`	una carpeta; por defecto `dataDir` de `config.json`, si no `server/data`	La carpeta de datos (base de datos, archivos subidos, almacenes de agentes de Cursor y, Nuevo en 0.9.17 en `deepseek-claude`, el estado de Claude Code de los chats de DeepSeek). Gana a `dataDir`. `oar start` y `oar copilot` se la pasan al relay; el servicio systemd y `oar status` usan el `data/` propio de la instalación.
`COPILOT_WEB_RELAY_LOG_DIR`	una carpeta	La carpeta de registros; por defecto `logs` en la carpeta de estado de una instalación global. Un relay que inicias tú guarda `relay-console.log` en `logs` dentro de `COPILOT_WEB_RELAY_DATA_DIR` cuando está definida, si no en `server/logs`, y los registros de sus workers en `server/logs`.
`COPILOT_WEB_RELAY_NODE`	una ruta a un programa `node`; por defecto el Node.js que ejecuta el relay	El Node.js con el que el relay inicia sus workers. Nuevo en 0.9.11 Sin ella, los workers se ejecutan con el propio Node.js del relay por su ruta completa en todas las plataformas, así que arrancan aunque no haya ningún `node` en el `PATH` del relay. También ejecuta el servidor MCP de OAR para el motor de extensión de Copilot.
`OAR_NO_CONSOLE_LOG`	`1` la desactiva; otros valores no hacen nada	Hace que el relay deje de guardar una copia de su consola en `relay-console.log` en la carpeta de registros.
`OAR_NO_UPDATE_CHECK`	`1`	No contacta nunca con oar.sh, ni siquiera para una comprobación manual (Actualizar OAR): las comprobaciones de actualizaciones de Settings → General responden que están desactivadas, y `oar update` sin `--to` se niega. `oar update --to X.Y.Z` sigue funcionando. Otros valores no hacen nada.
`OAR_UPDATE_MANIFEST_URL`	una URL; por defecto `https://oar.sh/latest.json`	El manifiesto de actualización que leen el relay y `oar update`.
`OAR_MCP_SERVER`	`0`, `false`, `off` o `no` lo desactiva	Mantiene el servidor MCP de OAR fuera de las sesiones de Grok y del motor de extensión de Copilot. Estos reciben entonces las instrucciones de vista previa como texto y no tienen la herramienta `relay_tool`. Los demás proveedores llevan sus herramientas dentro del proceso y no se ven afectados. Consulta Herramientas de agente.
`OAR_TURN_STALL_IDLE_MS`, `OAR_TURN_STALL_MODEL_MS`, `OAR_TURN_STALL_TOOL_MS`	milisegundos; predeterminados 120000, 300000 y 1800000	Cuánto tiempo puede estar en silencio un turn antes de fallar: sin nada en curso, durante una petición al modelo y durante una llamada a herramienta. `0` significa sin límite para esa fase. Las leen los workers, y no se pasan a un worker con tmux: consulta Qué variables llegan a los workers de los agentes y más abajo.
`COPILOT_WORKSPACE_ROOT_ALLOW_LIST`	carpetas separadas por `:` (`;` en Windows); sin definir permite cualquiera	Las carpetas en las que puede iniciarse una conversación, y sus subcarpetas. Gana a `workspaceRootAllowList`. Las carpetas que no existen se descartan con una advertencia; si no queda ninguna, se permite cualquier carpeta. Una variable vacía deja al mando la clave de la configuración. Consulta Iniciar una conversación.
`COPILOT_REMOTE_<FLAG>`	`1`, `true`, `yes`, `on` o `0`, `false`, `no`, `off`	Fija un flag de función. Consulta más abajo.
`OAR_HOST_SUSPEND_DRY_RUN`	`1`, `true`, `yes` u `on`	Suspend host (Suspender el host) (Windows) escribe la suspensión en el registro y no pone la máquina en suspensión. Para probar el flujo.

Temporizadores de inactividad del turn #

Las tres variables OAR_TURN_STALL_* las leen los workers de GitHub Copilot y OpenAI en el motor SDK, de Cursor y de Grok. Un turn que pasa más tiempo en silencio que la ventana de su fase actual falla con una nota del sistema; la tabla de Los turns y la queue muestra lo que ves.

Un valor tiene que ser un número de 0 o más. Cualquier otra cosa se ignora y se aplica el valor predeterminado.
Si defines solo OAR_TURN_STALL_IDLE_MS, las ventanas del modelo y de las herramientas mantienen su proporción con ella: fijarla en 240000 duplica ambos valores predeterminados. Defínelas también para fijarlas. Una ventana de inactividad de 0 lleva las otras dos a 0 salvo que las definas, lo que significa sin límite en las tres fases.
Claude y Nuevo en 0.9.17 DeepSeek, que se ejecuta en el worker de Claude, solo registran un turn en silencio y nunca lo terminan. Para ellos, OAR_TURN_STALL_MODEL_MS tiene un valor predeterminado de 600000, y su ventana de herramientas escala con OAR_TURN_STALL_IDLE_MS de la misma manera. Un valor ahí que esté definido pero vacío o que no sea un número da 300000 (escalado por la ventana de inactividad), no 600000.
El motor de extensión y Claude Cloud no leen estas variables.
En Grok, una ventana de inactividad de 0 no desactiva la vigilancia: las tres ventanas vuelven a sus valores predeterminados, y OAR_TURN_STALL_MODEL_MS y OAR_TURN_STALL_TOOL_MS se ignoran.
Las variables las leen los workers, así que con tmux no tienen efecto (consulta más arriba).

Flags de funciones #

La pestaña Features de los ajustes muestra los flags. Una variable fija un flag en un valor independientemente de lo que haya guardado la pestaña; el relay la lee al arrancar. Escribe el nombre del flag en mayúsculas después de COPILOT_REMOTE_. El valor es 1, true, yes u on para activado, y 0, false, no u off para desactivado, en mayúsculas o minúsculas; cualquier otra cosa se ignora y se mantiene el valor guardado. Existen estos cuatro flags:

Variable	Etiqueta de la pestaña	Predeterminado
`COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED`	Session worker routing (Enrutado de workers de sesión)	activado
`COPILOT_REMOTE_SESSION_WORKER_CONTINUATION_ROUTING_ENABLED`	Continuation answer routing (Enrutado de respuestas de continuación)	activado
`COPILOT_REMOTE_SESSION_WORKER_FALLBACK_RESTART_ENABLED`	Worker fallback restart (reserved) (Reinicio de reserva del worker, reservado)	desactivado, y no cambia nada
`COPILOT_REMOTE_IMAGE_CONVERSATION_CONTINUITY_ENABLED`	Generated-image continuity (Continuidad de imágenes generadas)	activado

Desactivar el enrutado de workers de sesión hace que el motor SDK deje de estar disponible.

Vistas previas #

Las vistas previas necesitan además un bloque previews y un nombre de host propio: consulta preview. Cada variable gana a la clave correspondiente de ese bloque.

Variable	Valor / por defecto	Qué hace
`COPILOT_PREVIEWS_ENABLED`	`1`/`true` o `0`/`false`	Activa o desactiva las vistas previas. Cualquier otro valor deja al mando `previews.enabled`.
`COPILOT_PREVIEWS_PORT`	un número de puerto	El puerto del listener de vistas previas. `0` toma un puerto libre; si no, 1024 o más, y no un puerto del relay. Un valor inutilizable deja al mando la clave `port`. Sin variable ni clave `port`, es el puerto del relay más uno.
`COPILOT_PREVIEWS_BIND_HOST`	una dirección; por defecto `127.0.0.1`	La dirección a la que se vincula el listener de vistas previas. Una dirección que no sea de loopback necesita además `previews.allowPublicBind: true` en `config.json`; si no, las vistas previas siguen desactivadas.
`COPILOT_PREVIEWS_PUBLIC_BASE_URL`	una URL `http(s)`	La dirección pública de las vistas previas. Obligatoria cuando las vistas previas están activadas, y su nombre de host debe ser distinto del del relay. Un valor que no sea una URL `http(s)` cuenta como ausente; no se usa la clave en su lugar.
`COPILOT_PREVIEWS_ALLOWED_TARGET_HOSTS`	nombres de host separados por comas	Los hosts, además de la propia máquina del relay, a los que puede apuntar una vista previa de puerto. Una variable definida pero vacía significa una lista vacía e ignora `allowedTargetHosts`.

El túnel de Cloudflare #

Para el bloque cloudflaredTunnel de config.json, y las cabeceras marcadoras de cualquier túnel. Cada variable COPILOT_CLOUDFLARED_* gana a su clave; las cabeceras marcadoras se combinan.

Variable	Valor / por defecto	Qué hace
`COPILOT_CLOUDFLARED_MODE`	`managed` o `disabled`	Anula `cloudflaredTunnel.mode` (Cloudflare Tunnel). Cualquier otro valor se ignora. `managed` necesita un token.
`COPILOT_CLOUDFLARED_TOKEN`	un token de túnel	Anula `cloudflaredTunnel.token`.
`COPILOT_CLOUDFLARED_BINARY`	un nombre o una ruta; por defecto `cloudflared` del `PATH`	Anula `cloudflaredTunnel.binary`.
`COPILOT_TUNNEL_MARKER_HEADERS`	nombres de cabecera separados por comas	Más cabeceras marcadoras, además de `cf-ray`, que hacen que una petición cuente como llegada a través de un túnel: la protección de rutas de los workers de sesión la rechaza, y sus tokens erróneos cuentan para el bloqueo de inicio de sesión. Nuevo en 0.9.11 Se suman a `tunnelMarkerHeaders` de `config.json`, no se sustituyen por ellas: `tunnelMarkerHeaders: []` ya no desactiva esta variable.

Proveedores #

GitHub Copilot #

Consulta GitHub Copilot para saber cómo se encuentra la CLI.

Variable	Valor / por defecto	Qué hace
`COPILOT_SDK_PATH`	una carpeta	La carpeta `copilot-sdk` que cargan los workers del motor SDK, en lugar de la que está junto a la CLI más reciente en la caché de paquetes. La lista de modelos propia del relay y la importación de sesiones no la leen.
`COPILOT_WEB_RELAY_CLI_EXECUTABLE`, luego `COPILOT_CLI_EXECUTABLE`, luego `COPILOT_CLI_PATH`	un programa; por defecto `copilot`	La CLI de Copilot que ejecuta el motor de extensión en Linux y macOS (Windows ejecuta siempre `gh copilot`). La primera gana a `cliPath` de `config.json`.
`COPILOT_CONFIG_HOME`	una carpeta; por defecto `~/.copilot`	Dónde escribe `oar copilot` su envoltorio de la extensión.
`COPILOT_PKG_DIR`	una carpeta	Una caché de paquetes adicional en la que buscar.
`XDG_CACHE_HOME`, `XDG_DATA_HOME`	carpetas	En Linux, dónde están las dos cachés de paquetes predeterminadas (`copilot/pkg` dentro de cada una).
`GH_TOKEN`, `GITHUB_TOKEN`	un token de GitHub	Se usa para la tarjeta de Copilot de Check Usage (Ver consumo), en lugar del resultado de `gh auth token`. `GH_TOKEN` se lee primero.
`COPILOT_SESSION_STATE_DIR`	una carpeta; por defecto `~/.copilot/session-state`	La carpeta de estado de sesión de la CLI de Copilot, si está en otro sitio. Solo se usa si esa carpeta existe.

OAR_MCP_SERVER y COPILOT_REMOTE_SESSION_WORKER_ROUTING_ENABLED se aplican también a Copilot (ver más arriba).

OpenAI #

La clave de API y la URL base se fijan en Settings → Providers → OpenAI (Ajustes → Proveedores → OpenAI) y no tienen variable. Dos variables ajustan los topes de tokens de OpenAI en el motor SDK; consulta OpenAI.

Variable	Valor / por defecto	Qué hace
`COPILOT_PROVIDER_MAX_PROMPT_TOKENS`	un número entero positivo	El tope del prompt para el modelo, en lugar de la tabla de OAR. Un valor inutilizable se registra y se ignora.
`COPILOT_PROVIDER_MAX_OUTPUT_TOKENS`	un número entero positivo	Lo mismo para la salida.

La carpeta de las imágenes generadas sigue a COPILOT_SESSION_STATE_DIR.

Claude #

Consulta Claude.

Variable	Valor / por defecto	Qué hace
`CLAUDE_CONFIG_DIR`	una carpeta; por defecto `~/.claude`	La carpeta de configuración de Claude: el inicio de sesión, y dónde se buscan las carpetas de sesión. Nuevo en 0.9.17 No para los chats de DeepSeek: su Claude Code guarda su estado en `deepseek-claude` en la carpeta de datos (DeepSeek). Nuevo en 0.9.18 Los chats de Claude API la usan como los chats de Claude.
`CLAUDE_CODE_EXECUTABLE`	una ruta de archivo	El programa Claude Code que usan los workers, en lugar de la compilación incluida con el Agent SDK. Una instalación o actualización desde el panel la fija, guarda el programa en `config.json`, y a partir de entonces ese programa gana a tu variable en cada arranque. El inicio de sesión ejecuta `claude` desde el `PATH`.
`CLAUDE_CODE_OAUTH_TOKEN`	un token de inicio de sesión de Claude	Claude Code lo lee en lugar del inicio de sesión de `CLAUDE_CONFIG_DIR`. Nuevo en 0.9.17 Los workers de Claude lo reciben también con tmux. Qué workers lo reciben: consulta Claude Cloud.
`ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`	una clave o un token de Anthropic	Nuevo en 0.9.17 No se pasan a ningún worker. Un chat de Claude funciona con el inicio de sesión de Claude del host (el archivo de inicio de sesión de la CLI, o `CLAUDE_CODE_OAUTH_TOKEN`), nunca con una clave del entorno del relay. Antes de 0.9.17 todos los workers las recibían, y Claude Code prefería cualquiera de ellas al inicio de sesión de Claude. Nuevo en 0.9.18 Un chat de Claude API funciona con la clave guardada en Settings → Providers → Claude API, no con estas.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	las fija OAR	Nuevo en 0.9.12 No se leen del entorno del relay: OAR las fija para cada sesión de Claude que inicia, y Nuevo en 0.9.17 para cada una de DeepSeek, a partir de Claude background command limit (Límite de comandos en segundo plano de Claude) (el límite, 8 h y 2 min). Consulta Límite de comandos en segundo plano.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	un número de tokens	La lee Claude Code, no OAR: fija la ventana de compactación automática. Cuando Claude Code informa de que tomó la ventana de ahí, la línea bajo el control deslizante dice from CLAUDE_CODE_AUTO_COMPACT_WINDOW (de CLAUDE_CODE_AUTO_COMPACT_WINDOW). No se pasa a un worker con tmux. Nuevo en 0.9.17 Un chat de DeepSeek la ignora (DeepSeek). Consulta Compactación.

Claude API Nuevo en 0.9.18 #

Claude API no tiene ninguna variable propia. La clave se fija en Settings → Providers → Claude API; no se usa un ANTHROPIC_API_KEY del entorno del relay. El relay da la clave guardada solo a los workers de Claude API, y su Claude Code la recibe como su ANTHROPIC_API_KEY, en su propio entorno. Consulta Claude API.

Un chat de Claude API ejecuta Claude Code en el host del relay, así que las variables de Claude se le aplican, con estas diferencias:

Variable	En un chat de Claude API
`CLAUDE_CONFIG_DIR`	Se usa, como en Claude: los chats comparten la carpeta de configuración de Claude.
`CLAUDE_CODE_EXECUTABLE`	Se usa, como en Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Las fija OAR a partir de Claude background command limit, como en Claude.
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Se ignora.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, cada `ANTHROPIC_*`	Se ignoran: OAR dirige Claude Code a `https://api.anthropic.com` con la clave guardada.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Se ignoran: OAR fija el effort y los modelos a partir del chat.
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Se ignora: haría que Claude Code saliera del modo plan y ejecutara cada comando de shell en un sandbox.

Claude Cloud #

Consulta Claude Cloud.

Variable	Valor / por defecto	Qué hace
`CLAUDE_CODE_OAUTH_TOKEN`	un token de inicio de sesión de Claude	Lo usan para Claude Cloud, en lugar del archivo de credenciales de la CLI, el relay y sus workers en la nube. Nuevo en 0.9.17 Solo llega a los workers de Claude Cloud y de Claude, en todas las plataformas: con tmux mediante un archivo que solo puede leer el usuario del relay, sin tmux en el entorno que heredan. Los workers de GitHub Copilot, OpenAI, Cursor, Grok y DeepSeek, y Nuevo en 0.9.18 los de Claude API, se inician sin él. Antes de 0.9.17 lo recibía cada worker iniciado sin tmux, y con tmux un servidor tmux que iniciaba un lanzamiento lo conservaba para todas las sesiones posteriores. Un chat de Claude en un host que inicia sesión solo con el token lo recibe ahora también con tmux.
`CLAUDE_CONFIG_DIR`	una carpeta; por defecto `~/.claude`	De dónde se lee el inicio de sesión de la CLI (`.credentials.json`).
`OAR_CLAUDE_CLOUD_BRANCH_LOOKUP`	`off`, `0`, `false` o `no` (en mayúsculas o minúsculas)	Impide que la lista de ramas de New Chat (Nuevo chat) consulte a git. Cualquier otro valor la deja activada.

DeepSeek #

Nuevo en 0.9.17 DeepSeek no tiene ninguna variable propia. La clave de API y la URL base se fijan en Settings → Providers → DeepSeek; la URL base, en Advanced (Avanzado). No se usa un DEEPSEEK_API_KEY ni un DEEPSEEK_BASE_URL del entorno del relay: el relay da a los workers de DeepSeek los valores guardados, y ningún otro worker recibe ninguno de los dos. Consulta DeepSeek.

Un chat de DeepSeek ejecuta Claude Code en el host del relay, así que las variables de Claude de más arriba importan, pero no todas:

Variable	En un chat de DeepSeek
`CLAUDE_CODE_EXECUTABLE`	Se usa, como en Claude.
`BASH_DEFAULT_TIMEOUT_MS`, `BASH_MAX_TIMEOUT_MS`, `CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS`	Las fija OAR a partir de Claude background command limit, como en Claude.
`CLAUDE_CONFIG_DIR`	Se ignora. Claude Code guarda su estado en `deepseek-claude` en la carpeta de datos (Carpeta y sesión).
`CLAUDE_CODE_AUTO_COMPACT_WINDOW`	Se ignora.
`CLAUDE_CODE_OAUTH_TOKEN`, `CLAUDE_CODE_USE_BEDROCK`, `CLAUDE_CODE_USE_VERTEX`, `CLAUDE_CODE_USE_FOUNDRY`, cada `ANTHROPIC_*`	Se ignoran: OAR dirige Claude Code al endpoint de DeepSeek con la clave guardada.
`CLAUDE_CODE_EFFORT_LEVEL`, `CLAUDE_CODE_SUBAGENT_MODEL`, `CLAUDE_CODE_SUBAGENT_MODEL_FORCE`, `CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL`	Se ignoran: OAR fija el effort y los modelos a partir del chat (Reasoning effort, Modelos).
`CLAUDE_CODE_SUBPROCESS_ENV_SCRUB`	Se ignora: haría que Claude Code saliera del modo plan hacia su modo predeterminado, de modo que el agente podría editar archivos, y ejecutara cada comando de shell en un sandbox.
`CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`	OAR la fija en `1`, diga lo que diga la tuya: el tráfico propio de Claude Code hacia Anthropic (actualizaciones, telemetría) queda desactivado.

Los ajustes del relay para su worker (el tipo de worker, las carpetas y el archivo de herramientas del relay, SESSION_ID, y cada variable COPILOT_WEB_RELAY_*, COPILOT_PROVIDER_*, DEEPSEEK_* y OAR_*) se quedan en el worker: ni Claude Code ni los comandos que ejecuta su agente los ven. La clave en sí llega a Claude Code como su token para el endpoint de DeepSeek, así que los comandos del agente pueden leerla; consulta Dónde se guarda la clave. Tus demás variables le llegan igual que a un chat de Claude.

Cursor #

La clave de API de Cursor se guarda en Settings → Providers → Cursor. No se usa un CURSOR_API_KEY del entorno del relay: el relay da a sus workers la clave guardada. Consulta Cursor.

Variable	Valor / por defecto	Qué hace
`CURSOR_SESSION_TOKEN`	un token de sesión del panel	Para las barras del plan en vivo (Check Usage). Un token guardado en el panel gana a esta variable, y esta gana al inicio de sesión de la app de Cursor.
`CURSOR_AGENT_STORE_DIR`	una carpeta; por defecto `cursor-agents` en la carpeta de datos del relay (Nuevo en 0.9.14; antes, `data/cursor-agents` en la carpeta del servidor del relay)	Dónde se guarda el estado del agente de cada conversación.

Grok #

Consulta Grok.

Variable	Valor / por defecto	Qué hace
`GROK_CLI_COMMAND`	un nombre de programa o una ruta; por defecto `grok`	El programa Grok para el inicio de sesión, la detección de modelos y los workers. Se lee `GROK_COMMAND` cuando esta no está definida; el relay pasa cualquiera de las dos a los workers como `GROK_CLI_COMMAND`, también con tmux. Una instalación o actualización desde el panel guarda el programa en `config.json`, y a partir de entonces gana a la variable en cada arranque.
`GROK_ALWAYS_APPROVE`	`0`; por defecto `1`	`0` inicia Grok sin `--always-approve`; OAR responde entonces a cada solicitud de permiso con allow-once (permitir una vez). Se pasa a los workers con tmux.
`XAI_API_KEY`	una clave de xAI	La lee la CLI de Grok, no OAR, como alternativa a su inicio de sesión. La fila de la cuenta solo conoce un inicio de sesión hecho mediante la CLI. No se pasa a un worker con tmux.

No es para ti #

En el código fuente y en los registros aparecen otros nombres. No son ajustes: los hooks de stubs y de pruebas (*_STUB_*, *_ALLOW_STUB_SPAWN, COPILOT_WEB_RELAY_DISABLE_CLI_SPAWN, OAR_PACKAGE_SPEC, OAR_CLAUDE_CLOUD_API_BASE_URL, Nuevo en 0.9.18 OAR_ANTHROPIC_API_BASE_URL, OAR_HYGIENE_DENYLIST); las variables que el relay define para sus propios procesos worker (COPILOT_WEB_RELAY_WORKER_KIND, *_RELAY_MODEL, SESSION_ID, COPILOT_WEB_RELAY_ROOT, COPILOT_WEB_RELAY_SERVER_DIR, OAR_MCP_SERVER_ATTACHED y los demás COPILOT_PROVIDER_*, que el relay rellena a partir de los ajustes de OpenAI, y Nuevo en 0.9.17 DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL y DEEPSEEK_CLAUDE_CONFIG_DIR, que rellena a partir de los ajustes de DeepSeek, y Nuevo en 0.9.18 OAR_CLAUDE_API_KEY y CLAUDE_API_RELAY_MODEL, que rellena a partir de los ajustes de Claude API; las claves llegan a un worker con tmux mediante el archivo que solo puede leer el propietario); y los parámetros de ajuste fino para desarrolladores (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, que OAR fija en 1 para Grok; y COPILOT_WORKSPACE_ROOT, que fijan los lanzadores. El menú de oar respeta NO_COLOR. Deja el resto como está.