Redémarrages et reprise

Chaque conversation a son propre agent, qui tourne dans un processus en arrière-plan sur la machine du relais. La conversation elle-même, son historique, sa queue et son brouillon, vit dans le relais. Cette page explique comment les deux s’articulent, pour que vous sachiez ce que vous coûte un Kill session (Tuer la session), un redémarrage du relais ou un redémarrage de la machine, et ce qui revient tout seul.

En bref : rien de ce que vous avez écrit n’est perdu. Le message suivant envoyé à une conversation redémarre son agent s’il ne tourne pas, et l’agent poursuit la session du fournisseur, pas une session vierge.

Le processus d’agent d’une conversation #

OAR appelle ce processus le worker de session. Vous ne le démarrez pas. Le relais le démarre quand une conversation en a besoin, en général avec votre premier message, et le worker se reconnecte au relais pour recevoir les messages et transmettre la réponse. Sous Linux et macOS avec tmux installé, les workers tournent dans des sessions tmux détachées, et Inspect tmux console (Inspecter la console tmux) dans le menu ⋯ en affiche une. Sans tmux, ils tournent comme de simples processus en arrière-plan.

Ajouté en 0.9.11 Les workers tournent sur le Node.js du relais lui-même, par son chemin complet, sur toutes les plateformes. Ils démarrent donc même quand le PATH du relais ne contient pas de node, comme pour un relais démarré par la tâche de démarrage de Windows avant que quiconque ne se soit connecté. COPILOT_WEB_RELAY_NODE en définit un autre (Variables d’environnement). Quand le PATH d’un worker ne contient pas de node, ce dossier Node.js est ajouté à la fin, pour que les CLI et les commandes qu’un worker démarre en trouvent un eux aussi.

Si le worker ne peut pas être démarré, la conversation affiche une note :

The worker for this conversation could not be started (2 tries). Cause: <reason>. Your message stays queued; the relay tries again every 1 minute until 14:20 UTC.

Le relais réessaie toutes les minutes pendant 10 minutes. Ensuite, la note indique qu’il a cessé d’essayer et affiche un bouton Retry (Réessayer). Votre message reste en file pendant tout ce temps, et il est remis dès qu’un worker démarre. Sous Windows, un lancement qui échoue ou ne rend jamais la main échoue immédiatement et nomme le programme, et le journal du relais nomme la commande et le PATH avec lequel elle a été lancée.

Arrêt automatique #

Une conversation Claude ou DeepSeek, et une conversation GitHub Copilot ou OpenAI sur le moteur SDK, libèrent leur mémoire quand il ne se passe rien. Après 10 minutes sans activité, le programme de l’agent se termine, et le message suivant le redémarre et poursuit la même session du fournisseur. Le processus worker reste et garde sa liaison avec le relais. L’app n’a pas de réglage pour ces 10 minutes.

L’agent n’est pas arrêté tant que l’une de ces choses est en cours :

• un turn tourne ou est en file pour lui,
• une carte de question ou de permission attend votre réponse,
• une tâche de fond tourne, ou la suite d’une tâche qui vient de se terminer est encore attendue.

Les tâches de fond seules ne peuvent le maintenir ouvert que jusqu’au Background task timeout (Délai des tâches de fond) dans Settings → General (Réglages → Général) (4 heures par défaut ; 0 signifie sans limite).

Ajouté en 0.9.17 Une conversation DeepSeek redémarre aussi le programme de son agent quand vous changez son modèle ou son effort de raisonnement, car Claude Code ne lit les deux qu’au démarrage. Le redémarrage a lieu avant le turn suivant, quand rien ne tourne dans le programme, et poursuit la même session. Tant que du travail de fond y tourne encore, le turn s’exécute dans le programme tel qu’il est : un nouveau modèle y est basculé, un nouvel effort attend le redémarrage.

Les autres fournisseurs n’ont pas cet arrêt sur inactivité. Un worker Claude Cloud, Cursor ou Grok continue de tourner jusqu’à ce que vous tuiez la session, archiviez la conversation ou que la machine s’arrête. Le moteur d’extension de Copilot garde lui aussi sa Copilot CLI en marche. Un worker Cursor inutilisé depuis 30 minutes ferme son handle d’agent et rouvre le même agent Cursor au message suivant.

Kill session #

Kill session dans le menu ⋯ de la conversation, ou dans le menu de sa ligne dans la liste, arrête le worker et les processus qu’il a démarrés. Utilisez-le quand une conversation est bloquée, quand l’agent ne réagit pas à Stop (Arrêter), ou quand vous voulez que l’agent reparte de zéro pour prendre en compte de nouveaux outils ou réglages, par exemple après avoir activé les sessions d’agent.

Une confirmation s’ouvre d’abord :

Kill the session for <title>?
This stops the current worker and any active turn will need a manual retry or a new message.

Ensuite, une courte notification indique Session killed. (Session tuée.) Si aucun processus actif n’a été trouvé, elle indique à la place Session state cleared; no live worker process was found. Si un processus survit à la tentative, une alerte indique Failed to kill session (Impossible de tuer la session) et rien n’est effacé.

Un turn qui tournait se termine par une note dans la conversation : This session was killed from the relay UI before the turn completed. Renvoyez le message, ou écrivez-en un nouveau. La conversation, son historique et ses messages en file restent. Le message suivant démarre un nouveau worker, et la session du fournisseur est reprise.

Archiver une conversation arrête aussi son worker. Voir La liste des conversations.

Quand l’agent est injoignable #

Quand aucun worker ne s’est manifesté depuis 10 secondes, une bannière apparaît au-dessus de la conversation et la ligne d’état de la barre latérale indique CLI offline (CLI hors ligne) :

⚠️ CLI is offline — messages will queue until it reconnects

La bannière appartient au relais, pas à une conversation, et elle peut être normale sur un relais resté inactif. Les messages que vous envoyez sont conservés. Envoyez-en un : le relais démarre le worker de la conversation et la bannière disparaît dès qu’il se connecte. Si elle reste, regardez worker-<session>.log dans le dossier de journaux du relais ; voir Fichiers et dossiers pour savoir où il se trouve.

Un worker qui a perdu sa connexion, par exemple pendant un redémarrage du relais, continue d’essayer de se reconnecter, en attendant jusqu’à 8 secondes entre deux tentatives. Ajouté en 0.9.13 Il abandonne aussi une connexion qui n’a pas abouti en 15 secondes, et n’attend pas qu’un relais en train de s’arrêter ferme la liaison : un redémarrage qui se bloque ne le laisse donc plus sans tentative suivante. Chaque tentative échouée écrit une ligne worker ws disconnected avec la raison dans son worker-<session>.log : les trois premières, puis au plus une par minute. Ajouté en 0.9.11 Par sécurité, le relais remplace un worker resté sans connexion pendant 60 secondes alors qu’un message l’attend : il arrête l’ancien processus et en démarre un nouveau, qui prend le message. Il ne le fait jamais pendant qu’un turn ou du travail de fond de cette session tourne, et il écrit une ligne WORKER DETACHED dans le journal quand il le fait.

Redémarrer le relais #

Redémarrez le relais pour charger une nouvelle version, un fichier de config modifié ou une CLI de fournisseur fraîchement installée. Choisissez 🌄 Restart web relay (Redémarrer le relais web) dans le menu ⋯ de la conversation, ou lancez oar restart sur la machine du relais. oar update et le bouton Update (Mettre à jour) dans Settings → General le redémarrent pour vous après une installation.

Ce que le redémarrage attendrait Ajouté en 0.9.13 #

🌄 Restart web relay montre d’abord ce qu’un redémarrage attendrait et ce qu’il laisserait tourner :

• les sessions avec un turn en cours, chacune avec son titre ;
• combien de messages il retiendrait jusque-là ;
• les sessions avec des tâches de fond (commandes, moniteurs, subagents), chacune marquée comme continuant de tourner ou comme may stop (peut s’arrêter). Une tâche que le relais a gardée d’un redémarrage précédent, et que son worker n’a pas encore confirmée, est listée comme pas encore confirmée.

Quand un turn tourne, la fenêtre propose 🌄 Restart when idle (Redémarrer une fois inactif), qui met le redémarrage en file, et Restart now (Redémarrer maintenant), qui n’attend pas. Quand rien ne tourne, le bouton est 🌄 Restart web relay et le relais redémarre aussitôt.

Le redémarrage attend les turns en cours #

Le redémarrage n’interrompt pas un turn. Restart when idle le met en file, et chaque page sur chaque appareil connecté affiche une bannière :

🌄 Relay restart queued — waiting for 2 sessions · waited 4 min of 30 min
Waiting for: Review: server/, Build docs (2 turns)
New messages are held until the restart: 3 messages waiting.

Les noms de session sont des liens qui ouvrent la conversation. Une ligne Background tasks: (Tâches de fond :) suit quand des sessions ont du travail de fond, avec pour chacune l’indication qu’elle continue de tourner ou non. La bannière a deux boutons :

• Restart now demande d’abord confirmation, nomme les sessions qu’il n’attend pas, puis redémarre. Leurs workers continuent de tourner et se manifestent auprès du relais redémarré ; la sortie en direct de leurs turns est en pause pendant l’absence du relais, et un turn dont la réponse n’arrive pas doit être renvoyé. Sous le service Linux, les workers peuvent s’arrêter avec le relais, et la fenêtre le signale.
• Cancel restart (Annuler le redémarrage) retire le redémarrage. Les messages retenus partent aussitôt.

Seuls les turns en cours retiennent le redémarrage. Tant qu’il est en file, les messages que vous envoyez attendent dans la queue et ne sont remis à aucun agent, pour qu’un relais occupé ne puisse pas repousser le redémarrage encore et encore. Ils s’exécutent après le redémarrage. Un turn dont l’agent est devenu silencieux est abandonné après la fenêtre d’inactivité du relais, 10 minutes par défaut (processingTimeoutMs), et ne le retient alors plus.

Quand l’attente est longue Ajouté en 0.9.13 #

Un redémarrage en file attend au plus Ask after a queued relay restart has waited (Demander quand un redémarrage du relais en file a attendu) dans Settings → General : 30 minutes par défaut ; 5, 10, 15 ou 30 minutes, 1, 2 ou 4 heures, ou No limit (Sans limite). La bannière se transforme alors en question :

🌄 The relay restart has waited 30 min for 2 sessions — restart now, keep waiting or cancel?

Elle propose Restart now, Keep waiting (30 min) (Continuer d’attendre, 30 min) et Cancel restart. Keep waiting attend une nouvelle période complète, comptée à partir de ce moment, et redemande. Les appareils qui ont les notifications activées en reçoivent aussi une, intitulée Relay restart waiting (Redémarrage du relais en attente).

Le relais ne redémarre jamais tout seul pendant que des turns tournent, question ou non, et il redémarre quand même dès que le dernier se termine. Avec No limit, un redémarrage en file, et les messages qu’il retient, attendent que les turns en cours se terminent ou que vous décidiez. Un réglage modifié s’applique à un redémarrage déjà en file.

Quand rien ne tourne, la bannière indique Relay restarting now… et le relais est de retour en quelques instants. Un appareil ouvert peut montrer une brève coupure de connexion et, jusqu’à ce que le premier worker se soit manifesté, la bannière CLI is offline.

oar restart se comporte de la même façon quand le relais a été démarré par oar start ou dans un terminal : il met le redémarrage en file, si bien que la bannière et la question après l’attente maximale s’appliquent aussi. Il attend jusqu’à une minute, puis indique que le relais est encore occupé et qu’il redémarrera de lui-même quand ses turns seront terminés. oar stop attend jusqu’à 30 secondes de la même façon. Quand le relais tourne comme service systemd (oar service install), oar restart et oar stop passent par systemd et agissent aussitôt, sans attendre les turns. Un turn en cours se termine alors, et il est traité comme décrit plus bas.

Ajouté en 0.9.11 N’importe quel navigateur connecté peut mettre le redémarrage en file ou l’annuler ; il lui faut le token d’accès et rien d’autre. Si le relais refuse, la page affiche sa raison. Depuis un terminal sur l’hôte, oar restart fonctionne toujours.

Ajouté en 0.9.13 Un agent à qui vous demandez de redémarrer le relais met le redémarrage en file de la même façon, et il apprend ce que le redémarrage attend, quels messages il retient et quelles tâches de fond continuent de tourner, pour pouvoir vous le dire. Les agents ont pour consigne de ne jamais sauter l’attente : redémarrer sans elle, c’est Restart now, et c’est votre décision.

Ce qu’un redémarrage conserve et ce qu’il perd #

Conservé :

• Les conversations et leur historique
• Les messages en file, y compris ceux qui ont attendu le redémarrage
• Les brouillons de la zone de saisie et les pièces jointes
• Ajouté en 0.9.11 Les aperçus, vérifiés à nouveau au démarrage
• Ajouté en 0.9.11 Les tâches de fond des workers qui continuent de tourner
• Ajouté en 0.9.13 Les consoles de tâche : les lignes terminées pour le reste de leur heure, et la sortie des commandes en cours
• Les abonnements que les agents ont mis en place pour surveiller d’autres sessions
• L’approbation qu’un agent a obtenue pour démarrer des sessions
• Une pause à la limite d’utilisation
• Les sessions de fournisseur des conversations

Perdu :

• Un Suspend host (Mettre l’hôte en veille) en file (Windows), que le relais abandonne en le signalant
• Les tâches de fond des workers que le redémarrage a arrêtés (sous le service Linux, voir plus bas)

Quand le relais a été démarré par oar start ou dans un terminal, il n’arrête pas les workers en se terminant. Ils remarquent que la liaison a disparu et se reconnectent au nouveau relais. Le service de oar service install est différent : systemd arrête tout ce que le service a démarré, workers compris, car le service ne demande rien d’autre. Le message suivant envoyé à chaque conversation démarre alors un nouveau worker, et la conversation continue comme décrit ci-dessous.

Un turn qui tournait quand tout s’est arrêté #

Un redémarrage planifié attend les turns, donc ceci concerne Restart now, un plantage, un kill, une coupure de courant ou un redémarrage de la machine.

Le relais marque un turn comme en cours jusqu’à ce que son worker se manifeste. Si le worker cesse de se manifester, le relais attend sa fenêtre d’inactivité (10 minutes par défaut, processingTimeoutMs ; 45 secondes au plus quand aucun worker n’est connecté) puis remet le message dans la queue. Le message est remis à un nouveau worker, qui reprend la session du fournisseur : l’agent dispose donc de sa conversation antérieure. Les fichiers que l’agent a déjà modifiés restent modifiés.

• Un message est remis en file au plus maxRequeueRetries fois (5 par défaut). Ensuite, il échoue avec Relay recovery limit reached … Send it again to retry.
• Un turn que l’agent a démarré lui-même après une tâche de fond, une suite, n’est pas remis en file. Il est abandonné, car le relancer donnerait à l’agent sa propre notification comme si c’était votre prompt.
• Copilot sur le moteur SDK garde une réponse terminée que le relais n’a pas pu recevoir pendant son redémarrage, et la propose de nouveau pendant cinq minutes au plus : la réponse n’est pas perdue et le prompt ne s’exécute pas deux fois.

Un worker qui a continué de tourner pendant le redémarrage garde son turn : il se manifeste auprès du nouveau relais et le turn continue.

Demander à une session interrompue de continuer Ajouté en 0.9.13 #

Quelques turns ne peuvent pas être relancés, parce que l’agent avait déjà pris le message : un message que vous avez envoyé pendant qu’il travaillait, une suite, ou un turn déjà commencé quand son worker est revenu sans lui. Un tel turn s’arrête simplement, et l’agent n’apprend jamais qu’il a été coupé.

Activez After a relay restart, tell interrupted sessions to carry on (Après un redémarrage du relais, demander aux sessions interrompues de continuer) dans Settings → General (désactivé par défaut, un réglage du relais) et une telle session reçoit une note du relais une fois celui-ci revenu. Elle s’affiche comme une ligne compacte relay (relais) dans la conversation, et l’agent lit :

Automatic message from OAR, not from the user: the relay restarted at 2026-10-20 14:05 UTC, and the turn you were working on was interrupted before it finished. Check where you were (the files you changed, the commands and background tasks you started) and carry on from there. Do not repeat steps that already completed; if the work was already done, say so briefly.

• Votre message n’est jamais renvoyé, et une session reçoit au plus une note par redémarrage.
• Rien n’est envoyé aux sessions inactives, pour les turns qui se relancent d’eux-mêmes, aux conversations archivées, ni pendant qu’une pause à la limite d’utilisation retient la session (sa propre relance fait continuer le turn).
• Un message que vous avez mis en file entre-temps passe en premier ; la note attend derrière lui.
• La note démarre l’agent de la session comme n’importe quel message. Les turns coupés dans les 30 minutes qui suivent le démarrage du relais sont pris en compte.

Sans ce réglage, envoyez vous-même un court message comme « continue ».

Par fournisseur #

La conversation et la queue sont conservées par le relais pour tous les fournisseurs. Ce que le fournisseur conserve, et donc ce à partir de quoi une conversation reprise continue, diffère. Les conversations OpenAI Image n’ont pas de worker : le relais appelle lui-même l’API Images, donc rien sur cette page ne s’applique à elles.