Actualizar OAR Nuevo en 0.9.2

OAR no se actualiza solo en segundo plano. Un relay puede buscar una versión más reciente, avisarte en Settings (Ajustes) e instalarla cuando pulsas Update (Actualizar) o ejecutas oar update. Nada se instala sin ti, y la comprobación que encuentra una versión está desactivada hasta que la activas.

La comprobación de actualizaciones #

La comprobación está desactivada por defecto. Un relay al que nunca se le ha dicho lo contrario no envía nada a oar.sh.

1. Abre Settings → General (Ajustes → General).
2. Activa Check for updates automatically (Buscar actualizaciones automáticamente).

Con ella activada, el relay pregunta a oar.sh por la versión más reciente unas dos veces al día: cada 12 horas, con una variación de hasta una hora para que no pregunten muchos relays a la vez. También pregunta una vez cuando activas el interruptor y una vez cada vez que el relay arranca con el interruptor activado. Desactivar el interruptor detiene las preguntas.

El botón Check for updates (Buscar actualizaciones) comprueba una vez, diga lo que diga el interruptor. La línea de al lado dice Last checked <date and time>, o Never checked.

Qué pide la comprobación #

El relay solicita un archivo, el manifiesto https://oar.sh/latest.json: un simple GET con una cabecera Accept: application/json, y una cabecera If-None-Match con la etiqueta de la última respuesta en cuanto hay una, para que un manifiesto sin cambios no cueste ninguna descarga. La solicitud no lleva ninguna información de versión, token, cuenta ni máquina. Espera como máximo 5 segundos. No hay ningún otro contacto con oar.sh. Instalar una actualización habla con el registro de npm, no con oar.sh.

El manifiesto tiene una entrada por canal con la versión más reciente, su fecha de publicación, un enlace a sus notas de la versión y un indicador critical:

{
  "schemaVersion": 1,
  "channels": {
    "stable": {
      "version": "0.9.19",
      "publishedAt": "2026-10-27T06:23:15.940Z",
      "notesUrl": "https://github.com/oar-sh/oar/releases/tag/v0.9.19",
      "minNode": "22.13",
      "critical": false
    }
  }
}

El relay lee la entrada de su propio canal (consulta Canales), o la entrada estable cuando su canal no tiene ninguna. minNode nombra el Node.js más antiguo con el que funciona la versión; ni el relay ni los instaladores lo leen.

Una comprobación automática que falla (sin red, un tiempo de espera agotado, una respuesta incorrecta) no dice nada y vuelve a intentarlo en el siguiente intervalo. Un clic en Check for updates que no obtiene ninguna respuesta utilizable muestra el aviso Update check failed — the update server could not be reached. Un manifiesto con un schemaVersion distinto de 1 detiene las comprobaciones hasta que el relay se reinicia y añade The relay could not read the update feed — try updating manually. a la línea junto al botón.

Cuando se encuentra una versión #

Una versión más reciente aparece como una fila bajo Check for updates en Settings → General:

OAR 0.9.19 available

con un enlace release notes (notas de la versión), y los botones Update y Dismiss (Descartar). No hay ningún banner ni ninguna insignia en otro lugar, y con la comprobación desactivada no aparece nada, porque no se conoce ninguna versión más reciente. Dismiss oculta esa versión hasta que aparece otra todavía más reciente. Una versión marcada como critical dice OAR 0.9.19 available — critical update, no se puede descartar, y aun así nunca se instala sola. En un checkout de git la fila no tiene botón Update; dice This relay runs from a git checkout — pull and restart to update.

Desactivar la comprobación para siempre #

Define OAR_NO_UPDATE_CHECK=1 en el entorno del relay. Entonces el relay no hace ninguna solicitud, ni siquiera cuando pulsas Check for updates: el interruptor y el botón quedan desactivados y una línea dice Update checks are disabled by OAR_NO_UPDATE_CHECK in this relay's environment. oar update sin --to también se niega. OAR_UPDATE_MANIFEST_URL dirige el relay y oar update a otro manifiesto. Consulta Variables de entorno.

Actualizar desde la interfaz web #

Pulsa Update en Settings → General. Funciona en una instalación global, la que hacen el instalador y npm install -g.

1. El relay ejecuta npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar@<version> (Nuevo en 0.9.14 con @oar-sh/oar en la lista; consulta Instalar con npm). En macOS y Linux usa el npm que está junto al Node.js que ejecuta el relay, e instala en la carpeta en la que ya está el paquete. Eso cubre las tres disposiciones del instalador: tu propia carpeta global de npm, ~/.oar/npm cuando tu carpeta de npm necesitaba root, y ~/.oar/npm con el Node.js propio de OAR. En Windows ejecuta npm.cmd desde el PATH. npm tiene 10 minutos.
2. La línea de estado dice Updating to <version>…, y se despliega un Update log (Registro de actualización) con la salida de npm. Cancel update (Cancelar la actualización) detiene npm.
3. Cuando npm ha terminado, la línea dice npm finished — the relay restarts once the running turns finish. El relay se pide a sí mismo reiniciarse. Espera a los turns que están en curso; los mensajes que envías mientras tanto esperan en la queue y se ejecutan tras el reinicio. Un banner en cada dispositivo conectado muestra la espera, con Restart now (Reiniciar ahora) y Cancel restart (Cancelar el reinicio). Nuevo en 0.9.13 Tras Ask after a queued relay restart has waited (Preguntar cuando un reinicio del relay en cola lleve esperando) (30 minutos por defecto) pregunta si reiniciar ahora, seguir esperando o cancelar. Consulta Reinicios y reanudación.
4. El relay se reinicia y la página se reconecta sola. El reinicio no pasa por systemd ni por ningún otro gestor de servicios; consulta Inicio automático.

Si npm falla, la línea dice Update failed: <reason> y el registro muestra por qué. El relay sigue ejecutando la versión antigua.

Cómo comprueba el relay el resultado #

Antes de reiniciarse, el relay anota qué versión intentó instalar. En el siguiente arranque la compara con la versión que ejecuta. Si coinciden, muestra Updated to <version>. Si no coinciden, por ejemplo porque npm no reemplazó el paquete, muestra Update to <version> did not apply. con el final del registro de npm. Una nota de más de 7 días se descarta sin mensaje. Dismiss, junto a la línea, la borra.

Actualizar desde un terminal #

oar update

Busca en el manifiesto la versión más reciente de tu canal, la instala con npm install -g, y pide a un relay en marcha que se reinicie cuando su queue esté inactiva. Muestra Already up to date (<version>). cuando no hay nada más reciente. Las opciones y los códigos de salida están en oar update.

Para instalar una versión exacta, también una más antigua, nómbrala con un espacio tras la opción:

oar update --to 0.9.9

--to lee el registro de npm y se salta el manifiesto, así que también funciona con OAR_NO_UPDATE_CHECK=1. Escribe --to 0.9.9, no --to=0.9.9: la segunda forma se ignora e instala la versión más reciente de tu canal.

El instalador es otra forma. Vuelve a instalar el paquete, así que ejecutarlo de nuevo actualiza; consulta Instalación.

Canales #

Hay dos canales, stable (estable) y beta. Una versión beta tiene el aspecto 0.9.19-beta.1 y se ordena por debajo de la versión estable con el mismo número.

Un relay no tiene ningún ajuste de canal. Sigue el canal de la versión que ejecuta: una versión beta sigue beta, cualquier otra sigue stable. Eso vale para su propia comprobación y para oar update.

A un relay beta se le ofrece la versión que el manifiesto liste bajo beta, siempre que sea más reciente que la que está en marcha. Cuando la entrada beta lista una versión estable, como hacen ambas entradas para 0.9.19, un relay beta pasa a ella y sigue stable a partir de entonces. Pasar a una versión más antigua necesita --to.

Lo que una actualización no toca #

Sesiones que estaban en marcha #

El reinicio espera hasta que no haya ningún turn en curso, y luego el relay vuelve a arrancar con el código nuevo. Los procesos de agente que se iniciaron antes de la actualización tienen el código antiguo hasta que vuelven a arrancar. El agente de una sesión conoce sus herramientas cuando arranca. La versión 0.9.10 es un ejemplo: una sesión que ya estaba en marcha antes de la actualización no ofrece ni subscribe ni usage de remote_relay (ahora relay_tool) hasta que su agente se reinicia. En 0.9.11, un worker iniciado antes de la actualización no puede informar de sus tareas en segundo plano al relay reiniciado. En 0.9.12, la consola de un comando necesita un agente iniciado tras la actualización, y lo mismo los terminales de Grok en el panel de tareas. En 0.9.13, la marca de un comando canalizado a tail necesita un agente iniciado tras la actualización, porque es el agente el que informa de la línea de comandos. Kill session (Matar la sesión) en una sesión inactiva la reinicia, y el siguiente mensaje arranca un agente nuevo. Consulta Reinicios y reanudación.

CLI de proveedores #

OAR solo se actualiza a sí mismo. Las herramientas de línea de comandos de Claude, Grok y GitHub Copilot son programas aparte; consulta Instalar o actualizar la CLI de un proveedor.

Conviene saber #

• Cursor en una instalación global. Nuevo en 0.9.14 Los almacenes de agentes de Cursor viven en cursor-agents, en la carpeta de datos del relay, así que una actualización ya no los reemplaza. Antes de 0.9.14 estaban por defecto dentro de la carpeta del paquete, y una conversación cuyo almacén eliminaba una actualización recibía un agente nuevo. Consulta Archivos y carpetas y Cursor.
• Windows. Una instalación global ejecuta el relay desde la carpeta de estado de OAR (%APPDATA%\oar), no desde la carpeta del paquete, así que una actualización puede reemplazar el paquete mientras el relay está en marcha. Las entradas de inicio automático arrancan el paquete instalado; consulta Inicio automático.

Un checkout de git #

Un checkout nunca se actualiza solo, y ni Update ni oar update funcionan en él. Haz pull, instala y luego reinicia el relay con 🌄 Restart web relay (Reiniciar el relay web) en el menú ⋯ de una conversación:

git pull
npm install

Consulta Instalación.

Notas de actualización #

Los pasos que una actualización necesita de ti, empezando por la versión más reciente. Las versiones que no aparecen no necesitan ninguno.

0.9.19 Nuevo en 0.9.19 #

• Sin migraciones. Volver a 0.9.18 no requiere ningún paso: 0.9.18 ignora heapLimitMb, y la carpeta diagnostics se queda como está.
• El relay tiene ahora un límite de heap y escribe una instantánea del heap en diagnostics, dentro de la carpeta de datos, cuando se acerca a él. Una instantánea contiene el token de acceso y las claves de API: nunca compartas una tal cual.
• Detén oar y vuelve a iniciarlo una vez tras la actualización. El proceso que inicia y vigila el relay conserva el código con el que arrancó: un reinicio por la actualización, desde la interfaz web o con oar restart sin el servicio de systemd solo reinicia el relay que lleva dentro. Hasta que ese proceso arranque con 0.9.19, el relay funciona sin el límite de heap, sin heapLimitMb y sin la instantánea del heap, y un relay que se queda sin memoria sigue quedándose caído. Con el servicio de systemd de Linux, ejecuta oar restart; si no, oar stop y después oar start. Para un relay iniciado por oar copilot, termina esa sesión e iníciala de nuevo.
• Las sesiones de agentes iniciadas antes de 0.9.19 conservan su lista de proveedores. Sus workers siguen funcionando durante la actualización, con el relay_tool con el que arrancaron. Esa lista es la de 0.9.19, así que ahora no cambia nada; le faltan los proveedores que añada una actualización posterior hasta que el worker de la sesión se reinicie, por ejemplo tras ☠️ Kill session en el menú ⋯.
• Node.js 22.13 o posterior sigue bastando.

0.9.18 Nuevo en 0.9.18 #

• Las migraciones 0031 a 0034 se ejecutan solas en el primer arranque: 0031 marca cada mensaje en cola con su proveedor, 0032 añade las columnas del selector de facturación, y 0033 y 0034 añaden las tablas de la tarjeta de consumo de Claude API. Una versión anterior ignora las columnas y tablas nuevas. Los dos triggers que 0031 pone en la tabla de la queue siguen marcando su columna nueva allí, lo que no causa ningún daño.
• La herramienta de agente ahora se llama relay_tool. Si tus propias instrucciones, reglas de permisos o hooks nombran remote_relay o mcp__relay__remote_relay, cámbialos a relay_tool o mcp__relay__relay_tool. Consulta El nombre.
• Antes de volver a 0.9.17, vuelve a pasar a Subscription (Suscripción) los chats de Claude que usan la clave de Claude API. 0.9.17 no conoce Claude API: vincula a Copilot un chat de un proveedor que no conoce, así que un chat que se quedó en la clave se ejecuta allí como chat de Copilot. Eso incluye un chat que empezó con la suscripción y se pasó a la clave.
• Volver a 0.9.17 reactiva los hooks en los chats de DeepSeek. Vuelven a ejecutar los hooks y la línea de estado de sus carpetas de ajustes; consulta Los ajustes de carpeta no pueden desviar DeepSeek.
• Node.js 22.13 o posterior sigue bastando.

0.9.17 Nuevo en 0.9.17 #

• Las migraciones 0024 a 0030 añaden las tablas de la tarjeta de consumo de DeepSeek: el gasto por modelo y por día, el saldo con el que se mide y, en 0030, las cifras de una exportación de consumo importada. Se ejecutan solas en el primer arranque, también en un relay que nunca usa DeepSeek, y no tocan ninguna tabla que use una versión anterior. Una versión anterior las ignora.
• Un token de inicio de sesión de Claude en el entorno del relay (CLAUDE_CODE_OAUTH_TOKEN) solo llega a los workers de Claude y Claude Cloud. Los workers de Copilot, OpenAI, Cursor, Grok y DeepSeek se arrancan sin él, con o sin tmux. Consulta Qué variables llegan a los agentes.
• ANTHROPIC_API_KEY y ANTHROPIC_AUTH_TOKEN en el entorno del relay no llegan a ningún worker. Los chats de Claude que se ejecutaban con una clave así ahora se ejecutan con el inicio de sesión de Claude del host. Si el host no tiene ninguno, inicia sesión con Relogin (Volver a iniciar sesión) en Settings → Providers → Claude (Ajustes → Proveedores → Claude). Consulta Variables de entorno.
• Un relay arrancado desde dentro de una sesión de Claude Code ya no pasa esa sesión a sus workers. Sus variables se descartan para todos los workers, también con un servidor tmux que todavía las lleva. Tus propios ajustes CLAUDE_CODE_* se quedan. Consulta Qué variables llegan a los agentes.
• Una sesión que se une a un grupo que ordenaste a mano va la primera en el grupo, ya no la última. Consulta Grupos de sesiones.
• Node.js 22.13 o posterior sigue bastando, y no hace falta cambiar ningún ajuste ni ninguna clave de config.json.

0.9.16 Nuevo en 0.9.16 #

• Tres migraciones de la base de datos se ejecutan solas en el primer arranque: 0019 (las opciones de suscripción y los prompts propios del agente que vigila), 0020, el interruptor Agents in this conversation may start sessions (Los agentes de esta conversación pueden iniciar sesiones), y 0021 (qué grupos de sesiones creó un agente, y qué grupos tuyos vació un agente). Solo añaden columnas y una tabla. Volver a una versión anterior no necesita ningún cambio de datos: las ignora, mantiene la regla de un solo nivel y elimina un grupo vacío al arrancar, como antes.
• La migración 0022 añade la tabla de los prompts programados, con de dónde vienen los mensajes de cada programación (origin_json, con sus saltos) y cuándo se retuvo un disparo para ti (held_since). Se ejecuta sola en el primer arranque, junto con 0019 a 0021.
• La migración 0023 añade la tabla de las preguntas que no bloquean (relay_asks). También se ejecuta sola en el primer arranque. Una versión anterior la ignora.
• Las suscripciones que reciben question_asked también reciben a partir de ahora question_answered, tu respuesta a una pregunta.
• La protección contra bucles solo cuenta como tuyos tus propios mensajes. Antes de 0.9.16 un evento del relay, el seguimiento tras un límite de uso o la nota tras un reinicio ponían a cero el recuento de prompts que un agente puede enviar a otros agentes antes de que se te pregunte, así que dos agentes que se vigilaban mutuamente podían seguir sin ti. Ahora solo lo pone a cero un mensaje que escribes tú, y los agentes en un bucle así te preguntan antes. Consulta las reglas.
• Agentes que pasan argumentos que una acción no admite: create_session y update_session ahora rechazan la llamada y no cambian nada; las demás acciones siguen ejecutándose y los nombran en ignored. Consulta Acciones.
• Un agente que vigila y que esperó la respuesta a su propio prompt ya no recibe además el turn_end de ese turn como evento.
• Node.js 22.13 o posterior sigue bastando, y no hace falta cambiar ningún ajuste ni ninguna clave de config.json.

0.9.15 #

• Desde 0.9.14 con una tarea de inicio automático creada a mano en Windows: cambiar al modo de arranque en 0.9.14 podía eliminar sin copia una tarea existente con el mismo nombre (oar-relay, o la de antes del cambio de nombre). 0.9.15 conserva esa tarea y pide --replace, que primero guarda una copia. Si una tarea tuya ya ha desaparecido, OAR no tiene ninguna copia de ella.
• Cambiar el inicio automático ya no reemplaza nada que OAR no haya creado. Una tarea de arranque o un lanzador editado a mano, una tarea que creó otra persona, la tarea de arranque de antes del cambio de nombre y una entrada de Inicio creada a mano detienen ahora el cambio, tanto en la interfaz web como en oar autostart, donde 0.9.14 los reemplazaba. oar autostart <mode> --replace los reemplaza, guardando una copia de cada uno. Consulta Entradas que OAR no creó.
• Comandos nuevos: oar autostart y oar uninstall, y oar setup pregunta por el modo de inicio automático en Windows. Consulta El comando oar.
• El paquete es más pequeño: los README para desarrolladores, server/README.md con la API HTTP y el de la extensión del relay web, ya no están en él. Están en el repositorio en GitHub.
• Node.js 22.13 o posterior sigue bastando, y no hace falta cambiar ningún ajuste ni ninguna clave de config.json.

0.9.14 #

0.9.14 copia primero esos datos, mientras se instala, a rescued-package-data/<time>/ en la carpeta de datos de OAR (%APPDATA%\oar\data, ~/.oar/data), y el relay adopta la copia en su siguiente arranque. npm 10 y 11 ejecutan esa copia (11.21 con un aviso), y si falla vuelven a poner la versión antigua con sus datos. npm 12 se la salta salvo que se permita @oar-sh/oar: entonces la instalación tiene éxito y los datos antiguos desaparecen. Con strict-allow-scripts, npm 11 y 12 rechazan la instalación y no cambian nada. Una entrada allow-scripts en .npmrc no ayuda al botón Update ni a oar update de 0.9.13, porque su propio --allow-scripts la reemplaza. Para ir sobre seguro, haz esta actualización a mano:

1. Cierra todas las sesiones de gh copilot (su extensión vuelve a arrancar el relay), luego ejecuta oar stop y espera hasta que oar status diga que no está en marcha. Si el oar stop de 0.9.13 no detiene un relay que arrancó el lanzador de inicio del sistema, termina el relay antes de instalar: finaliza los procesos del relay en el Administrador de tareas (node.exe ejecutando OAR).
2. Ejecuta npm root -g y abre <that folder>/@oar-sh/oar/server (normalmente %APPDATA%\npm\node_modules\@oar-sh\oar\server). Copia ambas carpetas, data y uploads, con todos sus archivos, a un lugar seguro.
3. Actualiza con los scripts de instalación de npm permitidos: npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar. Nunca actualices con --ignore-scripts: se salta la copia y los módulos nativos (better-sqlite3, koffi), así que después el relay no puede arrancar.
4. Antes de arrancar el relay, vuelve a copiar las dos carpetas en la misma carpeta server.
5. Ejecuta oar start. En relay-console.log, en la carpeta logs de OAR, busca [data] Brought over the database …: tus conversaciones deberían haber vuelto. Una base de datos que ya estaba en la carpeta de datos de OAR se guarda en backups/<time>/ en la carpeta de OAR (%APPDATA%\oar, ~/.oar). La carpeta adoptada conserva su base de datos como copilot.db.adopted-<time>; las demás examinadas conservan la suya como copilot.db.older-<time>. No se elimina nada.
6. Si el relay se detiene con [data] Not starting: each database has changes newer than the other's, las dos contienen trabajo. La línea nombra ambas carpetas; una puede estar bajo rescued-package-data/<time>/data. Elige la que quieres conservar, mueve los copilot.db, copilot.db-wal y copilot.db-shm de la otra a una carpeta tuya (no los elimines), y luego vuelve a ejecutar oar start.
7. Si ya actualizaste sin guardar y no se copió nada, OAR no puede recuperar la base de datos del paquete.

También en 0.9.14:

• Un relay que no puede ejecutarse con sus datos se detiene con el código de salida 78: cuando otro relay tiene su bloqueo, cuando dos bases de datos contienen trabajo más reciente, o cuando no se puede crear su carpeta de datos o de archivos subidos. La línea anterior a la salida dice cuál es el caso y qué hacer. Una unidad de systemd escrita por oar service install de 0.9.14 no lo reinicia; vuelve a ejecutar oar service install para obtener esa unidad. Consulta Un relay por carpeta de datos.
• Adoptar una base de datos grande lleva minutos. El relay registra su tamaño, el progreso al menos una vez por minuto y el tiempo de cada paso, y oar start indica mientras tanto que todavía la está adoptando. No arranques un segundo relay.
• El inicio automático de Windows ahora espera hasta 5 minutos a %TEMP% y a la unidad de datos, y el primer arranque tras la actualización pone al día una entrada o un lanzador generados. Consulta Inicio automático.
• Los almacenes de agentes de Cursor pasan a cursor-agents en la carpeta de datos, y los archivos subidos siguen a dataDir; los archivos subidos que una versión anterior dejó en server/uploads o en uploads/ de la carpeta de estado se siguen leyendo donde están. Consulta Archivos y carpetas.
• Node.js 22.13 o posterior sigue bastando.

0.9.13 #

• La migración 0018 añade la tabla que conserva las consolas de tareas tras un reinicio del relay, y se ejecuta sola en el primer arranque. Las filas terminadas que el relay anterior a esta actualización guardaba en memoria se pierden una última vez en el reinicio hacia ella. Node.js 22.13 o posterior sigue bastando.
• Ajustes nuevos en Settings → General: Ask after a queued relay restart has waited (30 minutos por defecto) y After a relay restart, tell interrupted sessions to carry on (Tras reiniciar el relay, pedir a las sesiones interrumpidas que continúen) (desactivado por defecto). Una notificación nueva, Queued relay restart waited its maximum time (El reinicio del relay en cola esperó el tiempo máximo), está activada por defecto. Consulta Ajustes y Cuando la espera es larga.
• Agentes que vigilan: una suscripción que no nombraba eventos ahora omite los comandos de shell que terminaron bien; los subagents terminados y los fallos lo siguen despertando. Una que nombraba sus eventos los conserva. Nombra task_finished para recibir cada final de tarea. Consulta Los eventos predeterminados.
• Los scripts que publican un mensaje sin modelo en una conversación existente ahora reciben el modelo, el effort y el modo propios de la conversación en lugar del primer modelo del relay, o un 409 con el código CONVERSATION_MODEL_UNAVAILABLE cuando ese modelo ha salido del catálogo. Consulta Modelos y razonamiento.
• Los agentes que pasan un modelo a relay_tool deben usar un id que liste el destino; uno desconocido ahora se rechaza con REMOTE_RELAY_UNKNOWN_MODEL. Consulta Qué modelos se aceptan.

0.9.12 #

• La migración 0017 añade dos índices para el historial de las conversaciones largas y se ejecuta sola en el primer arranque. Node.js 22.13 o posterior sigue bastando, y no hace falta cambiar ningún ajuste ni ninguna clave de config.json.
• Dos ajustes nuevos en Settings → General: Mark a background task as quiet after (Marcar una tarea en segundo plano como silenciosa tras) (10 minutos por defecto, para el relay) y Messages kept per conversation for switching back (Mensajes guardados por conversación para volver) (200 por defecto, en cada navegador). Consulta Ajustes.
• Los comandos en segundo plano de Claude pueden ejecutarse 2 horas por defecto y hasta 8 cuando Claude lo pide: Settings → Providers → Claude → Claude background command limit (Ajustes → Proveedores → Claude → Límite de comandos en segundo plano de Claude). OAR ahora define BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS y CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS para sus sesiones de Claude, así que los valores de estas variables en el entorno del relay ya no se aplican. Consulta Límite de comandos en segundo plano.
• Las sesiones que están en marcha mientras actualizas conservan su agente hasta que vuelve a arrancar, y hasta entonces no muestran salida en la consola de un comando. Consulta Sesiones que estaban en marcha.

0.9.11 #

• Detrás de un proxy inverso en otra máquina, define trustProxy y allowedOrigins. 0.9.11 es la primera versión que comprueba el origen de la conexión en vivo y lee la dirección del cliente, el host y el esquema de las cabeceras X-Forwarded-* solo cuando el proxy es de confianza. Un proxy o un túnel en la propia máquina del relay ya es de confianza. Para uno en otra máquina, o uno que reescribe la cabecera Host, añade las dos claves a config.json y reinicia el relay. Sin ellas la página carga pero no recibe actualizaciones en vivo, y todos los clientes comparten la dirección del proxy y su bloqueo de inicio de sesión. Consulta Un proxy en otra máquina.
• Diez tokens incorrectos desde una dirección en un minuto reciben 429 hasta que termina el minuto. Las solicitudes desde la propia máquina del relay que nada reenvió nunca se cuentan. Consulta Protecciones en el inicio de sesión.
• ?token= solo funciona en la dirección de la página. Los scripts que piden direcciones de la API, de archivos o de recursos con ?token= deben enviar en su lugar Authorization: Bearer <token>, o la cookie; un cliente de Socket.IO lo pasa como auth.token. Consulta Formas de presentarlo.
• Restart web relay, cancelar un reinicio en cola y Empty queue (Vaciar la cola) solo necesitan el token, desde cualquier dispositivo con la sesión iniciada. El socket de los workers de sesión y la ejecución de operaciones de imagen solo responden a solicitudes desde la máquina del relay que ningún túnel ni proxy reenvió. Consulta Endpoints que solo puede usar la máquina del relay.
• Cuatro migraciones de la base de datos (vistas previas, grupos de sesiones, la posición en un grupo, el registro de accesos a enlaces compartidos) se ejecutan solas en el primer arranque. Node.js 22.13 o posterior sigue bastando.
• Las dependencias están fijadas. Los paquetes que OAR usa directamente, entre ellos los SDK de Claude, Copilot y Cursor, se instalan en las versiones exactas con las que se probó la versión; una más reciente llega con una actualización de OAR.

Qué ha cambiado #

El registro de cambios está en oar.sh y en el repositorio como CHANGELOG.md. Cada versión también tiene notas de la versión en GitHub, que abre el enlace release notes de Settings → General. Los pasos que una actualización necesita de ti están bajo Upgrade notes (Notas de actualización) en la entrada de una versión, cuando los tiene.

Si no funciona #