Tâches de fond

Un agent peut laisser du travail tourner après avoir répondu : un serveur de dev, un long build ou un subagent qui travaille de son côté. OAR appelle cela une tâche de fond. Le panneau des tâches, au-dessus de la zone de saisie, liste ces tâches, vous permet d’arrêter chacune d’elles et d’ouvrir la sortie d’une commande, et le compte rendu de l’agent sur une tâche terminée arrive sous forme de réponse à part entière.

Ce qui compte comme tâche de fond #

• Une commande shell que l’agent a laissée tourner, comme un serveur de dev ou un long build. Ajouté en 0.9.12 Sur Grok, toute commande qui tourne plus de deux secondes.
• Un subagent qui travaille en arrière-plan. Les subagents ont leur propre page ; ici, ce n’est qu’une ligne de plus dans le panneau.
• Un moniteur et, sur Claude, un workflow Ultracode (voir Workflows Ultracode).

Quand l’agent a répondu et qu’il ne reste que de telles tâches, la conversation n’exécute plus de turn, mais elle n’est pas inactive pour autant. Les autres agents y voient l’état background_only (voir Comment les autres agents la voient). Vous, vous le voyez au panneau des tâches, qui reste affiché tant qu’une tâche tourne. La liste des conversations le montre par la couleur du titre : une session où tourne un turn ou du travail de fond garde son titre vert vif (voir Ce que montre une ligne).

Le panneau des tâches #

Le panneau se trouve juste au-dessus du champ de message. Il est replié sur une ligne, comme 2 background tasks running (2 tâches de fond en cours), avec un indicateur de chargement tant que des tâches tournent, et · 1 finished quand des commandes terminées sont listées. Cliquez sur la ligne pour ouvrir la liste. Le panneau est masqué quand il n’y a rien à montrer, et la liste défile quand elle contient plus de lignes qu’il n’en tient.

Chaque ligne affiche :

Une ligne en cours n’a pas d’étiquette d’état distincte : une tâche présente dans le panneau tourne. Un subagent quitte le panneau quand il se termine ; une commande shell ou un moniteur peut y rester une heure sous forme de ligne terminée. Après Stop, le bouton affiche Stopping… (Arrêt en cours…) jusqu’à la prochaine mise à jour du panneau, pendant 15 secondes au plus.

Sur le moteur SDK de Copilot, un shell n’a pas de bouton Stop quand la runtime Copilot ne peut pas lister ses tâches de fond. Un tel shell, vous ne pouvez y mettre fin qu’avec Kill session (Tuer la session) ; voir Ce qui met fin à une tâche.

Les cartes d’aperçu se trouvent dans le même panneau, au-dessus des tâches. Voir Ce que vous voyez. Un aperçu garde le panneau ouvert après la fin de la tâche qui a démarré son serveur.

La console de tâche Ajouté en 0.9.12 #

Cliquez sur la description d’une commande shell ou d’un moniteur dans le panneau, et sa console s’ouvre : la sortie de la commande, pour voir ce que fait un build, un serveur de dev ou une exécution de tests sans le demander à l’agent. Elle occupe tout l’écran sur un téléphone. Ajouté en 0.9.13 Sur un écran plus large, elle s’arrête au-dessus de la ligne de la tâche dans le panneau, de sorte que la puce de tests, le chronomètre et le bouton Stop de la ligne restent visibles et actifs à côté d’elle. Escape, ×, un clic à l’extérieur ou le bouton retour la ferment.

• Les 2 000 dernières lignes s’affichent à l’ouverture, et la nouvelle sortie suit en direct. Si vous avez remonté, vous restez où vous êtes, et Jump to end ↓ (Aller à la fin) vous ramène en bas.
• Load earlier (Charger les précédentes), en haut, remonte dans tout le journal, jusqu’à 2 000 lignes à la fois, jusqu’à ce qu’environ 5 Mo soient chargés. Au-delà, le bouton affiche older output not loaded (sortie plus ancienne non chargée). Ajouté en 0.9.13 L’en-tête de la console a le même bouton dès qu’il existe une sortie antérieure, pour qu’il reste à portée pendant que vous suivez la fin d’un long journal.
• Les barres de progression qui redessinent une ligne n’affichent que leur dernier état, et une ligne répétée plusieurs fois de suite s’affiche une seule fois avec ×N.
• Les couleurs restent, si bien qu’un échec en rouge reste rouge. Ajouté en 0.9.13 Le texte inversé échange ses couleurs, si bien que les badges RUN, PASS et FAIL de vitest s’affichent pleins. Les autres codes de contrôle sont supprimés, et une ligne est coupée à 4 000 caractères.
• Les identifiants sont caviardés : les tokens et clés aux formes habituelles, les en-têtes Bearer et Basic, un mot de passe dans une adresse et une valeur après un nom comme API_TOKEN= ou password: deviennent [redacted]. Ajouté en 0.9.13 De même pour le mot de passe de curl -u name:password, les valeurs de --password, --token et --secret, mysql -p…, docker login -p, sshpass -p, redis-cli -a, une clé d’accès secrète AWS, un chemin de webhook Slack, les valeurs ?key=, &sig= et &token= dans une adresse, et un en-tête Authorization avec n’importe quel schéma. Une référence comme $API_TOKEN ou $(cat ~/.token) est laissée telle quelle. Les lignes de tâche du panneau sont nettoyées de la même façon : la description, le résumé et la ligne d’activité d’une tâche.

L’en-tête indique le nom de la tâche, son type (Shell ou Monitor), sa durée d’exécution et si elle est running, completed, stopped ou failed, exit code 1, ou Ajouté en 0.9.13 waiting for its worker after the relay restart (voir Après un redémarrage du relais). Il porte aussi l’indication de silence et la puce de tests, ainsi que son propre bouton Stop tant que la tâche tourne.

Les agents de ce relais ou d’un autre peuvent lire la même sortie avec read_task_output. Ce que propose chaque fournisseur figure dans Par fournisseur.

Tâches silencieuses #

Une commande shell ou un moniteur en cours qui n’a rien écrit depuis une minute ou plus l’indique sur sa ligne et dans l’en-tête de sa console : no output for 12 min. À partir de la valeur de Settings → General → Mark a background task as quiet after (Réglages → Général → Marquer une tâche de fond comme silencieuse après), l’indication devient ambre. C’est 10 minutes par défaut, de 1 à 120 minutes, et cela s’applique à tous les navigateurs du relais.

Silencieuse ne veut pas dire bloquée : certaines étapes n’affichent rien pendant longtemps. Ouvrez la console pour voir les dernières lignes, puis attendez, augmentez le réglage ou arrêtez la tâche avec Stop. Le relais examine la sortie toutes les 10 secondes, l’indication peut donc avoir jusqu’à ce retard.

Commandes redirigées vers tail Ajouté en 0.9.13 #

Une commande redirigée vers tail, comme npm test 2>&1 | tail -40, n’écrit rien avant de se terminer : tail retient les dernières lignes jusque-là. Sa console aurait l’air bloquée. Quand la ligne de commande de la tâche montre un tel pipe, la console marque l’endroit où la sortie s’arrête, jusqu’à ce que d’autres sorties arrivent ou que la tâche se termine :

Output stops here: this command pipes into tail, so the rest arrives when it ends.
Logging to a file instead (> run.log 2>&1) and following that file shows it live.

L’indication no output for N min de la ligne dit la même chose au survol. tail -f et head transmettent les lignes au fur et à mesure et ne sont pas marqués. Pour suivre une exécution en direct, demandez à l’agent d’écrire dans un fichier (> run.log 2>&1) et suivez ce fichier.

Claude, DeepSeek, Copilot et Grok communiquent pour cela la ligne de commande d’une tâche shell. Le relais y caviarde les identifiants, comme dans la sortie, et en garde les 2 000 premiers caractères. Une session dont l’agent a démarré avant la mise à jour vers 0.9.13 n’en communique aucune.

Exécutions de tests #

Quand la sortie d’une commande ressemble à une exécution de tests de vitest, Playwright, node:test, jest, pytest ou turbo (y compris lancée via pnpm), sa ligne et l’en-tête de sa console affichent une puce avec les décomptes : ✓ 412 ✘ 2 en rouge quand des tests ont échoué, ou ✓ 38 quand aucun n’a échoué. Survolez la puce pour voir le lanceur et les nombres de tests réussis, échoués et ignorés. Les décomptes suivent l’exécution pendant qu’elle avance. Ajouté en 0.9.13 Une exécution en cours est comptée sur tout son journal, quelle que soit sa longueur, lu au fur et à mesure qu’il grandit, si bien que la puce garde chaque test même quand la sortie dépasse ce que la console affiche. Dès que le lanceur affiche son résumé final, c’est lui qui fait foi.

Dans la console, la puce et le bouton first failure (premier échec) à côté, affiché quand des tests ont échoué, sautent au premier test en échec dans la sortie chargée. S’il se trouve dans une sortie plus ancienne, la console le dit ; Load earlier le fait apparaître.

Commandes terminées #

Une commande shell ou un moniteur dont le relais lit la sortie dans un fichier reste dans le panneau pendant une heure après sa fin, sous forme de ligne estompée : ✓ quand la commande s’est terminée normalement, ✘ quand elle a échoué, ■ quand elle a été arrêtée, Ajouté en 0.9.13 ? quand le relais ne peut pas savoir comment elle s’est terminée (Après un redémarrage du relais), avec sa durée d’exécution et sa puce de tests. Sa console s’ouvre toujours, si bien que vous pouvez lire pourquoi une exécution a échoué après que l’agent est passé à autre chose. × masque la ligne jusqu’à ce que vous rechargiez la page. Au plus 20 lignes de ce type sont conservées par conversation. Ajouté en 0.9.13 Elles survivent à un redémarrage du relais (voir Après un redémarrage du relais).

Quand une tâche se termine #

Quand une tâche se termine, elle quitte le panneau, ou bien une commande reste sous forme de ligne terminée. L’agent est réveillé, examine le résultat et répond. Cette réponse est une réponse de suite : elle ne répond pas à un de vos messages, et son en-tête porte un badge background continuation (suite en arrière-plan). Vous pouvez la lire comme n’importe quelle autre réponse.

Pour les notifications, une suite est une réponse comme une autre : un appareil qui vous notifie à la fin d’un turn le fait donc ici aussi, avec Turn completed (Turn terminé) dans Settings → Notifications (Réglages → Notifications). Un agent qui surveille la session reçoit à la place un événement task_finished ou task_failed (voir Comment les autres agents la voient).

Si un redémarrage du relais survient entre la fin d’une tâche et sa suite, la suite est abandonnée, pas relancée. Voir Redémarrages et reprise.

Workflows Ultracode #

Les workflows Ultracode sont une fonctionnalité de Claude. Le panneau en affiche un sous forme de ligne Workflow avec un chevron. Ouvrez le chevron pour voir l’arbre de progression.

• Les phases sont des en-têtes, et les agents du workflow se rangent dessous.
• Chaque agent affiche une icône d’état (○ en file, ◐ en cours, ✓ terminé, ✗ échoué ou tué), son libellé et une ligne avec le modèle, les tokens, le nombre d’appels d’outil, la durée et, après une nouvelle tentative, attempt 2. Un agent en cours ajoute l’outil qu’il utilise.
• Les lignes de journal, les cinq dernières, se trouvent au-dessus des phases.
• Un arbre de plus de 100 agents se termine par +N more agents (+N autres agents).

L’arbre est ouvert pendant que le workflow tourne et replié une fois qu’il s’est achevé. Un choix que vous faites avec le chevron est conservé tant que la ligne reste dans le panneau. Pendant que le workflow tourne, l’arbre peut ne pas avoir de titres de phase ni de lignes de journal ; l’arbre final les contient.

Quand le workflow se termine, la réponse qui le résume garde une carte repliée dans le fil de la conversation :

🧩 Finished background task — review-shared-modules · 20 agents · 1.2M tok · 28m

Ouvrez-la pour voir l’arbre final. Les champs inconnus sont omis, et un workflow qui ne s’est pas terminé normalement indique comment entre parenthèses, comme dans Finished background task (failed), ou (unconfirmed) quand le résultat n’est jamais arrivé. La carte est enregistrée avec la réponse et reste après un rechargement.

Background task timeout (Délai des tâches de fond) #

Settings → General → Background task timeout (Réglages → Général → Délai des tâches de fond) définit combien de temps les tâches de fond peuvent, à elles seules, garder une session active après sa réponse. C’est un curseur de 0 à 10 heures par pas de 5 minutes. La valeur par défaut est de 4 heures. 0 signifie aucune limite : les tâches tournent alors jusqu’à ce qu’elles se terminent ou que vous les arrêtiez.

Quand le temps est écoulé, le relais arrête les tâches, et l’agent en rend compte dans une réponse de suite, comme pour toute tâche qui se termine. Sur Claude et DeepSeek, le chronomètre ne compte que tant que rien d’autre que des tâches ne maintient la session active, et repart de zéro chaque fois qu’un turn tourne entre-temps. Sur le moteur SDK de Copilot, chaque tâche a son propre chronomètre, qui démarre avec elle. La place de ce délai parmi les autres minuteries est décrite dans Les turns et la queue.

Ce qui met fin à une tâche #

Après un redémarrage du relais Ajouté en 0.9.11 #

Un worker qui continue de tourner pendant un redémarrage du relais garde ses tâches, et le relais les lui redemande au prochain signal de vie du worker. Elles reviennent dans le panneau avec leur heure de début d’origine, si bien que la session apparaît toujours au travail : Suspend host (Mettre l’hôte en veille) les attend, et une session qui surveille ne reçoit pas all_idle. Une tâche qui s’est terminée pendant l’absence du relais signale quand même sa fin.

Une session dont le worker a été démarré avant la mise à jour vers 0.9.11 ne sait pas encore répondre à cette demande. Elle affiche une seule ligne, background work, details not reported since the relay restarted (Kill session in its ⋯ menu ends it) (travail de fond, détails non transmis depuis le redémarrage du relais ; Kill session dans son menu ⋯ y met fin), jusqu’à ce qu’elle signale un changement. Pendant les 45 premières secondes après le démarrage du relais, une mise en veille attend aussi les sessions qui n’ont pas encore répondu.

Ajouté en 0.9.12 Les consoles des tâches qui reviennent s’ouvrent de nouveau, avec tout le journal, et une indication de silence réapparaît dès que le relais a examiné la sortie.

Ajouté en 0.9.13 Le relais garde les lignes de console dans sa base de données, si bien que les consoles survivent aussi au redémarrage :

• Les lignes terminées reviennent avec leur ✓ ou leur ✘ pour le reste de leur heure.
• La console d’une commande en cours lit sa sortie tout de suite, avant que son worker ait répondu. Tant que le worker n’a pas confirmé que la commande tourne encore, la console indique qu’elle attend son worker et n’a pas de bouton Stop.
• Une commande dont le worker n’est pas revenu (il est tombé avec le relais, par exemple lors d’un redémarrage de la machine) est marquée terminée après environ une minute et demie, et jamais de nouveau comme en cours. Le relais ne peut pas savoir comment elle s’est terminée, si bien que sa ligne affiche un ? neutre au lieu de ✓ ou ✘, avec le titre ended, result unknown (terminée, résultat inconnu). Sa sortie reste lisible pour le reste de l’heure.

Les commandes qui ont tourné avant la mise à jour vers 0.9.13 n’ont pas de ligne enregistrée ; elles reviennent quand leur worker répond, comme ci-dessus.

Sous le service Linux, un redémarrage arrête les workers, et leurs tâches avec eux ; voir Ce qu’un redémarrage conserve.

Comment les autres agents la voient #

list_sessions et read_session donnent à chaque session un state : running_turn, background_only (l’agent a répondu, du travail de fond tourne encore) ou idle. Ils listent aussi ses tasks, les agents en arrière-plan et les tâches shell, avec le moment où chacune a démarré, celui où elle a fait quelque chose pour la dernière fois, la façon dont elle s’est terminée et le code de sortie quand il est connu. Une session qui n’a que des tâches de fond n’apparaît donc pas comme inactive. Ajouté en 0.9.12 Sur le moteur SDK de Copilot, une tâche terminée signale completed, failed ou stopped, un shell son code de sortie, et un subagent son résultat (ou son erreur) comme résumé ; auparavant, ces tâches se terminaient en unknown.

Un agent qui surveille la session peut être réveillé par les événements task_finished et task_failed, chacun avec la description, le résultat et le résumé de la tâche. Une tâche qui a été arrêtée, ou qui s’est terminée avec un code non nul, compte comme échouée. Il peut aussi demander task_started. Ajouté en 0.9.13 Par défaut, un agent qui surveille est informé d’un subagent qui s’est terminé et de toute tâche qui a échoué, mais pas d’une commande shell ou d’un moniteur qui s’est bien terminé ; il doit nommer task_finished pour les recevoir.

Ajouté en 0.9.12 read_session donne aussi pour chaque tâche son taskId, si elle a une sortie à lire et, pour une commande, sa durée de silence et ses décomptes de tests. Ajouté en 0.9.13 Il donne aussi la ligne de commande d’une tâche shell, quand le fournisseur la communique. La description, le résumé, le dernier appel d’outil et la ligne de commande d’une tâche ont leurs identifiants caviardés, comme dans la console. read_task_output lit ensuite la fin de cette sortie, nettoyée comme celle de la console.

Par fournisseur #

L’arbre Ultracode et la carte Finished background task (Tâche de fond terminée) n’existent que sur Claude. Le tableau complet des capacités se trouve dans Les fournisseurs en un coup d’œil.