Mettre à jour OAR Ajouté en 0.9.2

OAR ne se met pas à jour tout seul en arrière-plan. Un relais peut chercher une version plus récente, vous la signaler dans Settings (Réglages) et l’installer quand vous appuyez sur Update (Mettre à jour) ou lancez oar update. Rien ne s’installe sans vous, et la vérification qui trouve une version reste désactivée tant que vous ne l’activez pas.

La vérification des mises à jour #

La vérification est désactivée par défaut. Un relais à qui l’on n’a jamais dit le contraire n’envoie rien à oar.sh.

1. Ouvrez Settings → General (Réglages → Général).
2. Activez Check for updates automatically (Rechercher automatiquement les mises à jour).

Une fois l’interrupteur activé, le relais demande à oar.sh la version la plus récente environ deux fois par jour : toutes les 12 heures, à une heure près, pour que de nombreux relais ne demandent pas tous en même temps. Il demande aussi une fois quand vous activez l’interrupteur, et une fois à chaque démarrage du relais avec l’interrupteur activé. Désactiver l’interrupteur arrête les demandes.

Le bouton Check for updates (Rechercher des mises à jour) vérifie une fois, quel que soit l’état de l’interrupteur. La ligne à côté affiche Last checked <date and time>, ou Never checked.

Ce que demande la vérification #

Le relais demande un seul fichier, le manifeste https://oar.sh/latest.json : un simple GET avec un en-tête Accept: application/json, et un en-tête If-None-Match qui contient l’étiquette de la dernière réponse dès qu’il y en a une, pour qu’un manifeste inchangé ne coûte aucun téléchargement. La requête ne transporte ni version, ni token, ni compte, ni information sur la machine. Elle attend au plus 5 secondes. Il n’y a aucun autre contact avec oar.sh. L’installation d’une mise à jour s’adresse au registre npm, pas à oar.sh.

Le manifeste a une entrée par canal avec la version la plus récente, sa date de publication, un lien vers ses notes de version et un indicateur 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
    }
  }
}

Le relais lit l’entrée de son propre canal (voir Canaux), ou l’entrée stable quand son canal n’en a pas. minNode indique la plus ancienne version de Node.js sur laquelle la version publiée tourne ; ni le relais ni les installateurs ne le lisent.

Une vérification automatique qui échoue (pas de réseau, un délai dépassé, une réponse invalide) ne dit rien et réessaie à l’intervalle suivant. Un clic sur Check for updates qui n’obtient aucune réponse exploitable affiche l’avis Update check failed — the update server could not be reached. Un manifeste dont le schemaVersion n’est pas 1 arrête les vérifications jusqu’au redémarrage du relais et ajoute The relay could not read the update feed — try updating manually. à la ligne à côté du bouton.

Quand une version est trouvée #

Une version plus récente apparaît sous forme de ligne sous Check for updates dans Settings → General :

OAR 0.9.19 available

avec un lien release notes (notes de version) et les boutons Update et Dismiss (Ignorer). Il n’y a ni bannière ni badge ailleurs, et quand la vérification est désactivée, rien n’apparaît, car aucune version plus récente n’est connue. Dismiss masque cette version jusqu’à ce qu’une version encore plus récente apparaisse. Une version marquée critical affiche OAR 0.9.19 available — critical update, ne peut pas être ignorée, et ne s’installe toujours jamais d’elle-même. Sur un checkout git, la ligne n’a pas de bouton Update ; elle indique This relay runs from a git checkout — pull and restart to update.

Désactiver la vérification pour de bon #

Définissez OAR_NO_UPDATE_CHECK=1 dans l’environnement du relais. Le relais ne fait alors plus aucune requête, pas même quand vous appuyez sur Check for updates : l’interrupteur et le bouton sont désactivés et une ligne indique Update checks are disabled by OAR_NO_UPDATE_CHECK in this relay's environment. oar update sans --to refuse aussi. OAR_UPDATE_MANIFEST_URL fait pointer le relais et oar update vers un autre manifeste. Voir Variables d’environnement.

Mettre à jour depuis l’interface web #

Appuyez sur Update dans Settings → General. Cela fonctionne sur une installation globale, celle que font l’installateur et npm install -g.

1. Le relais lance npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar@<version> (Ajouté en 0.9.14 avec @oar-sh/oar dans la liste ; voir Installer avec npm). Sous macOS et Linux, il utilise le npm situé à côté du Node.js qui fait tourner le relais, et installe dans le dossier où se trouve déjà le paquet. Cela couvre les trois dispositions de l’installateur : votre propre dossier npm global, ~/.oar/npm quand votre dossier npm exigeait root, et ~/.oar/npm avec le Node.js propre à OAR. Sous Windows, il lance npm.cmd depuis le PATH. npm dispose de 10 minutes.
2. La ligne d’état affiche Updating to <version>…, et un Update log (Journal de mise à jour) se déplie avec la sortie de npm. Cancel update (Annuler la mise à jour) arrête npm.
3. Quand npm a terminé, la ligne affiche npm finished — the relay restarts once the running turns finish. Le relais se demande à lui-même de redémarrer. Il attend les turns en cours ; les messages que vous envoyez entre-temps attendent dans la queue et s’exécutent après le redémarrage. Une bannière sur chaque appareil connecté montre l’attente, avec Restart now (Redémarrer maintenant) et Cancel restart (Annuler le redémarrage). Ajouté en 0.9.13 Une fois écoulé le délai Ask after a queued relay restart has waited (Demander quand un redémarrage du relais en file a attendu), 30 minutes par défaut, il demande s’il faut redémarrer maintenant, continuer d’attendre ou annuler. Voir Redémarrages et reprise.
4. Le relais redémarre et la page se reconnecte d’elle-même. Le redémarrage ne passe ni par systemd ni par un autre gestionnaire de services ; voir Démarrage automatique.

Si npm échoue, la ligne affiche Update failed: <reason> et le journal montre pourquoi. Le relais continue de faire tourner l’ancienne version.

Comment le relais vérifie le résultat #

Avant de redémarrer, le relais note la version qu’il a tenté d’installer. Au démarrage suivant, il la compare à la version qu’il fait tourner. Si elles correspondent, il affiche Updated to <version>. Si elles diffèrent, par exemple parce que npm n’a pas remplacé le paquet, il affiche Update to <version> did not apply. avec la fin du journal npm. Une note de plus de 7 jours est abandonnée sans message. Dismiss à côté de la ligne l’efface.

Mettre à jour depuis un terminal #

oar update

La commande cherche la version la plus récente de votre canal dans le manifeste, l’installe avec npm install -g et demande à un relais en cours d’exécution de redémarrer dès que sa queue est inactive. Elle affiche Already up to date (<version>). quand il n’y a rien de plus récent. Les options et les codes de sortie sont dans oar update.

Pour installer une version précise, même plus ancienne, nommez-la après une espace derrière l’option :

oar update --to 0.9.9

--to lit le registre npm et ignore le manifeste, donc cela fonctionne aussi avec OAR_NO_UPDATE_CHECK=1. Écrivez --to 0.9.9, pas --to=0.9.9 : la seconde forme est ignorée et installe la version la plus récente de votre canal.

L’installateur est une autre possibilité. Il réinstalle le paquet, donc le relancer met à jour ; voir Installation.

Canaux #

Il y a deux canaux, stable et beta. Une version beta ressemble à 0.9.19-beta.1 et se classe avant la version stable de même numéro.

Un relais n’a pas de réglage de canal. Il suit le canal de la version qu’il fait tourner : une version beta suit beta, toute autre suit stable. Cela vaut pour sa propre vérification et pour oar update.

Un relais beta se voit proposer la version que le manifeste indique sous beta, quelle qu’elle soit, tant qu’elle est plus récente que celle qui tourne. Quand l’entrée beta indique une version stable, comme les deux entrées le font pour 0.9.19, un relais beta y passe et suit stable à partir de là. Revenir à une version plus ancienne demande --to.

Ce qu’une mise à jour laisse intact #

Sessions qui tournaient #

Le redémarrage attend qu’aucun turn ne tourne, puis le relais redémarre avec le nouveau code. Les processus d’agent démarrés avant la mise à jour gardent l’ancien code jusqu’à leur prochain démarrage. L’agent d’une session apprend ses outils quand il démarre. La version 0.9.10 en est un exemple : une session qui tournait déjà avant la mise à jour ne propose ni subscribe ni usage de remote_relay (aujourd’hui relay_tool) tant que son agent ne redémarre pas. En 0.9.11, un worker démarré avant la mise à jour ne peut pas signaler ses tâches de fond au relais redémarré. En 0.9.12, la console d’une commande nécessite un agent démarré après la mise à jour, tout comme les terminaux de Grok dans le panneau des tâches. En 0.9.13, le marquage d’une commande redirigée vers tail nécessite un agent démarré après la mise à jour, car c’est l’agent qui signale la ligne de commande. Kill session (Tuer la session) sur une session inactive la redémarre, et le message suivant démarre un nouvel agent. Voir Redémarrages et reprise.

CLI des fournisseurs #

OAR ne met à jour que lui-même. Les outils en ligne de commande de Claude, Grok et GitHub Copilot sont des programmes distincts ; voir Installer ou mettre à jour la CLI d’un fournisseur.

Bon à savoir #

• Cursor sur une installation globale. Ajouté en 0.9.14 Les stockages d’agents Cursor se trouvent dans cursor-agents du dossier de données du relais, si bien qu’une mise à jour ne les remplace plus. Avant 0.9.14, ils se trouvaient par défaut dans le dossier du paquet, et une conversation dont une mise à jour supprimait le stockage recevait un nouvel agent. Voir Fichiers et dossiers et Cursor.
• Windows. Une installation globale fait tourner le relais depuis le dossier d’état d’OAR (%APPDATA%\oar), et non depuis le dossier du paquet, si bien qu’une mise à jour peut remplacer le paquet pendant que le relais tourne. Les entrées de démarrage automatique démarrent le paquet installé ; voir Démarrage automatique.

Un checkout git #

Un checkout ne se met jamais à jour tout seul, et ni Update ni oar update ne fonctionnent dessus. Faites un pull, installez, puis redémarrez le relais avec 🌄 Restart web relay (Redémarrer le relais web) dans le menu ⋯ d’une conversation :

git pull
npm install

Voir Installation.

Notes de mise à niveau #

Les étapes qu’une mise à jour attend de vous, de la version la plus récente à la plus ancienne. Les versions absentes de la liste n’en demandent aucune.

0.9.19 Ajouté en 0.9.19 #

• Aucune migration. Revenir à 0.9.18 ne demande aucune étape : 0.9.18 ignore heapLimitMb, et le dossier diagnostics reste tel quel.
• Le relais a désormais une limite de heap et écrit un instantané du heap dans diagnostics, dans le dossier de données, quand il en approche. Un instantané contient le token d’accès et les clés d’API : ne le partagez jamais tel quel.
• Arrêtez oar puis redémarrez-le une fois après la mise à jour. Le processus qui démarre et surveille le relais garde le code avec lequel il a démarré : un redémarrage par la mise à jour, depuis l’interface web ou avec oar restart sans le service systemd ne redémarre que le relais qu’il contient. Tant que ce processus n’a pas démarré sur 0.9.19, le relais tourne sans la limite de heap, sans heapLimitMb et sans l’instantané du heap, et un relais à court de mémoire reste toujours arrêté. Avec le service systemd de Linux, lancez oar restart ; sinon oar stop, puis oar start. Pour un relais démarré par oar copilot, terminez cette session et relancez-la.
• Les sessions d’agents démarrées avant 0.9.19 gardent leur liste de fournisseurs. Leurs workers continuent de tourner pendant la mise à jour, avec le relay_tool avec lequel ils ont démarré. Cette liste est celle de 0.9.19, donc rien ne change pour l’instant ; il lui manque les fournisseurs qu’une mise à jour ultérieure ajoute, jusqu’à ce que le worker de la session redémarre, par exemple après ☠️ Kill session dans le menu ⋯.
• Node.js 22.13 ou plus récent suffit toujours.

0.9.18 Ajouté en 0.9.18 #

• Les migrations 0031 à 0034 s’exécutent d’elles-mêmes au premier démarrage : 0031 marque chaque message en file avec son fournisseur, 0032 ajoute les colonnes du sélecteur de facturation, et 0033 et 0034 ajoutent les tables de la carte de consommation Claude API. Une version plus ancienne ignore les nouvelles colonnes et tables. Les deux déclencheurs que 0031 pose sur la table de la queue continuent d’y renseigner sa nouvelle colonne, ce qui ne fait aucun mal.
• L’outil d’agent s’appelle désormais relay_tool. Si vos propres instructions, règles de permission ou hooks nomment remote_relay ou mcp__relay__remote_relay, remplacez-les par relay_tool ou mcp__relay__relay_tool. Voir Le nom.
• Avant de revenir à 0.9.17, repassez sur Subscription (Abonnement) les chats Claude qui utilisent la clé Claude API. 0.9.17 ne connaît pas Claude API : elle rattache à Copilot un chat d’un fournisseur qu’elle ne connaît pas, si bien qu’un chat laissé sur la clé y tourne comme un chat Copilot. Cela inclut un chat qui a démarré sur l’abonnement puis est passé à la clé.
• Revenir à 0.9.17 réactive les hooks dans les chats DeepSeek. Ils exécutent de nouveau les hooks et la ligne d’état de leurs dossiers de réglages ; voir Les réglages du dossier ne peuvent pas rediriger DeepSeek.
• Node.js 22.13 ou plus récent suffit toujours.

0.9.17 Ajouté en 0.9.17 #

• Les migrations 0024 à 0030 ajoutent les tables de la carte de consommation DeepSeek : les dépenses par modèle et par jour, le solde par rapport auquel elle mesure et, dans 0030, les chiffres d’un export de consommation importé. Elles s’exécutent d’elles-mêmes au premier démarrage, y compris sur un relais qui n’utilise jamais DeepSeek, et ne touchent aucune table qu’utilise une version plus ancienne. Une version plus ancienne les ignore.
• Un token de connexion Claude dans l’environnement du relais (CLAUDE_CODE_OAUTH_TOKEN) n’atteint que les workers Claude et Claude Cloud. Les workers Copilot, OpenAI, Cursor, Grok et DeepSeek sont démarrés sans lui, avec ou sans tmux. Voir Quelles variables atteignent les agents.
• ANTHROPIC_API_KEY et ANTHROPIC_AUTH_TOKEN dans l’environnement du relais n’atteignent aucun worker. Les chats Claude qui tournaient avec une telle clé tournent désormais avec la connexion Claude de l’hôte. Si l’hôte n’en a pas, connectez-vous avec Relogin (Se reconnecter) sous Settings → Providers → Claude (Réglages → Fournisseurs → Claude). Voir Variables d’environnement.
• Un relais démarré depuis une session Claude Code ne transmet plus cette session à ses workers. Ses variables sont retirées pour chaque worker, y compris sous un serveur tmux qui les porte encore. Vos propres réglages CLAUDE_CODE_* restent. Voir Quelles variables atteignent les agents.
• Une session qui rejoint un groupe que vous avez ordonné à la main arrive en premier dans le groupe, et non plus en dernier. Voir Groupes de sessions.
• Node.js 22.13 ou plus récent suffit toujours, et aucun réglage ni aucune clé de config.json n’a besoin d’être modifié.

0.9.16 Ajouté en 0.9.16 #

• Trois migrations de base de données s’exécutent d’elles-mêmes au premier démarrage : 0019 pour les options d’abonnement et les prompts propres à l’agent qui surveille, 0020 pour l’interrupteur Agents in this conversation may start sessions (Les agents de cette conversation peuvent démarrer des sessions) et 0021 pour savoir quels groupes de sessions un agent a créés, et quels groupes à vous un agent a vidés. Elles ne font qu’ajouter des colonnes et une table. Revenir à une version plus ancienne ne demande aucune modification des données : elle les ignore, garde la règle à un seul niveau et supprime un groupe vide à son démarrage, comme avant.
• La migration 0022 ajoute la table des prompts planifiés, avec l’origine des messages de chaque planification (origin_json, avec leurs sauts) et le moment où un déclenchement a été retenu pour vous (held_since). Elle s’exécute d’elle-même au premier démarrage, en même temps que 0019 à 0021.
• La migration 0023 ajoute la table des questions non bloquantes (relay_asks). Elle s’exécute aussi d’elle-même au premier démarrage. Une version plus ancienne l’ignore.
• Les abonnements qui prennent question_asked reçoivent désormais aussi question_answered, votre réponse à une question.
• Le garde-fou anti-boucle ne compte comme vôtres que vos propres messages. Avant 0.9.16, un événement du relais, la relance après une limite d’utilisation ou la note après un redémarrage remettait à zéro le compte des prompts qu’un agent peut envoyer à d’autres agents avant qu’on vous demande, si bien que deux agents qui se surveillaient l’un l’autre pouvaient continuer sans vous. Désormais, seul un message que vous écrivez le remet à zéro, et les agents pris dans une telle boucle vous demandent plus tôt. Voir les règles.
• Agents qui passent des arguments qu’une action ne prend pas : create_session et update_session refusent désormais l’appel et ne changent rien ; les autres actions s’exécutent toujours et les nomment dans ignored. Voir Actions.
• Un agent qui surveille et attendait la réponse à son propre prompt ne reçoit plus, en plus, le turn_end de ce turn sous forme d’événement.
• Node.js 22.13 ou plus récent suffit toujours, et aucun réglage ni aucune clé de config.json n’a besoin d’être modifié.

0.9.15 #

• Depuis 0.9.14 avec une tâche de démarrage automatique faite à la main sous Windows : passer au mode « au démarrage » dans 0.9.14 pouvait supprimer une tâche existante du même nom (oar-relay, ou celle d’avant le renommage) sans en faire de copie. 0.9.15 conserve une telle tâche et demande --replace, qui en enregistre d’abord une copie. Si une de vos tâches a déjà disparu, OAR n’en a aucune copie.
• Changer de mode de démarrage automatique ne remplace plus rien de ce qu’OAR n’a pas créé. Une tâche de démarrage ou un lanceur modifié à la main, une tâche créée par quelqu’un d’autre, la tâche de démarrage d’avant le renommage et une entrée du dossier Démarrage faite à la main bloquent désormais le changement, dans l’interface web comme dans oar autostart, là où 0.9.14 les remplaçait. oar autostart <mode> --replace les remplace en gardant une copie de chacun. Voir Entrées qu’OAR n’a pas créées.
• Nouvelles commandes : oar autostart et oar uninstall, et oar setup demande le mode de démarrage automatique sous Windows. Voir La commande oar.
• Le paquet est plus petit : les README pour développeurs, server/README.md avec l’API HTTP et celui de l’extension du relais web, n’y sont plus. Ils sont dans le dépôt sur GitHub.
• Node.js 22.13 ou plus récent suffit toujours, et aucun réglage ni aucune clé de config.json n’a besoin d’être modifié.

0.9.14 #

0.9.14 copie d’abord ces données, pendant l’installation, dans rescued-package-data/<time>/ du dossier de données d’OAR (%APPDATA%\oar\data, ~/.oar/data), et le relais reprend la copie à son démarrage suivant. npm 10 et 11 exécutent cette copie (11.21 avec un avertissement), et si elle échoue, ils remettent l’ancienne version avec ses données. npm 12 la saute, sauf si @oar-sh/oar est autorisé : l’installation réussit alors et les anciennes données sont perdues. Avec strict-allow-scripts, npm 11 et 12 refusent l’installation et ne changent rien. Une entrée allow-scripts dans .npmrc n’aide ni le bouton Update ni oar update de 0.9.13, car leur propre --allow-scripts la remplace. Par sécurité, faites cette mise à jour à la main :

1. Fermez toutes les sessions gh copilot (leur extension redémarre le relais), puis lancez oar stop et attendez que oar status indique qu’il ne tourne pas. Si le oar stop de 0.9.13 n’arrête pas un relais démarré par le lanceur du démarrage système, arrêtez le relais avant d’installer : mettez fin à ses processus dans le Gestionnaire des tâches (node.exe qui fait tourner OAR).
2. Lancez npm root -g et ouvrez <that folder>/@oar-sh/oar/server (en général %APPDATA%\npm\node_modules\@oar-sh\oar\server). Copiez les deux dossiers data et uploads, avec tous leurs fichiers, en lieu sûr.
3. Mettez à jour en autorisant les scripts d’installation de npm : npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar. Ne mettez jamais à jour avec --ignore-scripts : cette option saute la copie et les modules natifs (better-sqlite3, koffi), et le relais ne peut plus démarrer ensuite.
4. Avant de démarrer le relais, recopiez les deux dossiers dans le même dossier server.
5. Lancez oar start. Dans relay-console.log, dans le dossier logs d’OAR, cherchez [data] Brought over the database … : vos conversations devraient être revenues. Une base de données qui se trouvait déjà dans le dossier de données d’OAR est conservée dans backups/<time>/ du dossier OAR (%APPDATA%\oar, ~/.oar). Le dossier repris garde sa base sous le nom copilot.db.adopted-<time> ; les autres dossiers examinés gardent la leur sous le nom copilot.db.older-<time>. Rien n’est supprimé.
6. Si le relais s’arrête avec [data] Not starting: each database has changes newer than the other's, les deux contiennent du travail. La ligne nomme les deux dossiers ; l’un peut se trouver sous rescued-package-data/<time>/data. Choisissez celui à garder, déplacez les fichiers copilot.db, copilot.db-wal et copilot.db-shm de l’autre dans un dossier à vous (ne les supprimez pas), puis relancez oar start.
7. Si vous avez déjà mis à jour sans sauvegarder et que rien n’a été copié, OAR ne peut pas récupérer la base de données depuis le paquet.

Aussi dans 0.9.14 :

• Un relais qui ne peut pas tourner sur ses données s’arrête avec le code de sortie 78 : quand un autre relais détient son verrou, quand deux bases de données contiennent chacune du travail plus récent, ou quand son dossier de données ou d’envoi ne peut pas être créé. La ligne avant la sortie dit lequel de ces cas se présente et ce qu’il faut faire. Une unité systemd écrite par oar service install de 0.9.14 ne le redémarre pas ; relancez oar service install pour obtenir cette unité. Voir Un relais par dossier de données.
• Une grande base de données met plusieurs minutes à être reprise. Le relais journalise sa taille, la progression au moins une fois par minute et la durée de chaque étape, et oar start indique entre-temps qu’il est toujours en train de la reprendre. Ne démarrez pas un second relais.
• Le démarrage automatique Windows attend désormais jusqu’à 5 minutes %TEMP% et le lecteur de données, et le premier démarrage après la mise à jour met à niveau une entrée ou un lanceur générés. Voir Démarrage automatique.
• Les stockages d’agents Cursor passent dans cursor-agents du dossier de données, et les fichiers envoyés suivent dataDir ; les fichiers envoyés qu’une version antérieure a laissés dans server/uploads ou dans uploads/ du dossier d’état sont toujours lus là où ils sont. Voir Fichiers et dossiers.
• Node.js 22.13 ou plus récent suffit toujours.

0.9.13 #

• La migration 0018 ajoute la table qui conserve les consoles de tâche d’un redémarrage du relais à l’autre, et s’exécute d’elle-même au premier démarrage. Les lignes terminées que le relais d’avant cette mise à jour gardait en mémoire sont perdues une dernière fois au redémarrage vers cette version. Node.js 22.13 ou plus récent suffit toujours.
• Nouveaux réglages dans Settings → General : Ask after a queued relay restart has waited (30 minutes par défaut) et After a relay restart, tell interrupted sessions to carry on (Après un redémarrage du relais, demander aux sessions interrompues de continuer), désactivé par défaut. Une nouvelle notification, Queued relay restart waited its maximum time (Le redémarrage du relais en file a attendu le délai maximal), est activée par défaut. Voir Settings (Réglages) et Quand l’attente est longue.
• Agents qui surveillent : un abonnement qui n’a nommé aucun événement laisse désormais de côté les commandes shell qui se sont bien terminées ; les subagents terminés et les échecs le réveillent toujours. Un abonnement qui a nommé ses événements les garde. Nommez task_finished pour recevoir chaque fin de tâche. Voir Les événements par défaut.
• Les scripts qui publient un message sans modèle dans une conversation existante reçoivent désormais le modèle, l’effort et le mode propres à la conversation au lieu du premier modèle du relais, ou un 409 avec le code CONVERSATION_MODEL_UNAVAILABLE quand ce modèle a quitté le catalogue. Voir Modèles et raisonnement.
• Les agents qui passent un modèle à relay_tool doivent utiliser un id que la cible liste ; un id inconnu est désormais refusé avec REMOTE_RELAY_UNKNOWN_MODEL. Voir Quels modèles sont acceptés.

0.9.12 #

• La migration 0017 ajoute deux index pour l’historique des longues conversations et s’exécute d’elle-même au premier démarrage. Node.js 22.13 ou plus récent suffit toujours, et aucun réglage ni aucune clé de config.json n’a besoin d’être modifié.
• Deux nouveaux réglages dans Settings → General : Mark a background task as quiet after (Marquer une tâche de fond comme silencieuse après), 10 minutes par défaut, pour le relais, et Messages kept per conversation for switching back (Messages conservés par conversation pour y revenir), 200 par défaut, dans chaque navigateur. Voir Settings (Réglages).
• Les commandes de fond de Claude peuvent tourner 2 heures par défaut, et jusqu’à 8 quand Claude le demande : Settings → Providers → Claude → Claude background command limit (Réglages → Fournisseurs → Claude → Limite des commandes de fond Claude). OAR définit désormais BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS et CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS pour ses sessions Claude, si bien que les valeurs de ces variables dans l’environnement du relais ne s’appliquent plus. Voir Limite des commandes de fond.
• Les sessions qui tournent pendant la mise à jour gardent leur agent jusqu’à son prochain démarrage, et n’affichent d’ici là aucune sortie dans la console d’une commande. Voir Sessions qui tournaient.

0.9.11 #

• Derrière un proxy inverse sur une autre machine, définissez trustProxy et allowedOrigins. 0.9.11 est la première version qui vérifie l’origine de la connexion en direct et qui ne lit l’adresse du client, l’hôte et le schéma dans les en-têtes X-Forwarded-* que si le proxy est de confiance. Un proxy ou un tunnel sur la machine du relais est déjà de confiance. Pour un proxy sur une autre machine, ou un proxy qui réécrit l’en-tête Host, ajoutez les deux clés à config.json et redémarrez le relais. Sans elles, la page se charge mais ne reçoit aucune mise à jour en direct, et tous les clients partagent l’adresse du proxy et son blocage de connexion. Voir Un proxy sur une autre machine.
• Dix tokens erronés depuis une même adresse en une minute reçoivent 429 jusqu’à la fin de la minute. Les requêtes venant de la machine du relais que rien n’a relayées ne sont jamais comptées. Voir Les protections à la connexion.
• ?token= ne fonctionne que sur l’adresse de la page. Les scripts qui récupèrent des adresses d’API, de fichier ou de ressource avec ?token= doivent envoyer Authorization: Bearer <token> à la place, ou le cookie ; un client Socket.IO le passe comme auth.token. Voir Les façons de le présenter.
• Restart web relay, l’annulation d’un redémarrage en file et Empty queue (Vider la file) n’ont besoin que du token, depuis n’importe quel appareil connecté. Le socket du worker de session et l’exécution des opérations d’image ne répondent qu’aux requêtes de la machine du relais qu’aucun tunnel ni proxy n’a relayées. Voir Les points d’accès réservés à la machine du relais.
• Quatre migrations de base de données (aperçus, groupes de sessions, place dans un groupe, journal d’accès des partages) s’exécutent d’elles-mêmes au premier démarrage. Node.js 22.13 ou plus récent suffit toujours.
• Les dépendances sont épinglées. Les paquets qu’OAR utilise directement, dont les SDK Claude, Copilot et Cursor, sont installés dans les versions exactes avec lesquelles cette version d’OAR a été testée ; une version plus récente arrive avec une mise à jour d’OAR.

Ce qui a changé #

Le journal des modifications se trouve sur oar.sh et dans le dépôt sous le nom CHANGELOG.md. Chaque version a aussi des notes de version sur GitHub, que le lien release notes de Settings → General ouvre. Les étapes qu’une mise à jour attend de vous figurent sous Upgrade notes (Notes de mise à niveau) dans l’entrée d’une version, quand elle en a.

Si ça ne marche pas #