Fichiers et dossiers

OAR garde tout ce qui lui appartient dans un seul dossier, le dossier d’état : le fichier de config, la base de données avec vos conversations, les journaux et les fichiers envoyés. Cette page indique où se trouve ce dossier, ce qu’il contient, quelles parties vous pouvez supprimer, lesquelles contiennent des secrets et ce que le relais supprime de lui-même. Certaines données ne sont pas du tout dans le dossier d’état : chaque fournisseur garde ses propres données de session et ses connexions dans ses propres dossiers.

Le dossier d’état #

npm install -g et oar update remplacent le paquet mais ne touchent jamais au dossier d’état. OAR_STATE_ROOT doit être défini dans chaque shell où vous lancez oar, sinon la commande cherche dans le dossier par défaut ; voir Variables d’environnement. oar doctor affiche les chemins utilisés : le dossier d’état, le fichier de config, la base de données et sa taille. Les mêmes chemins sont listés pour chaque installation dans Installation.

Trois variables d’environnement déplacent des parties isolées : COPILOT_WEB_RELAY_CONFIG le fichier de config, COPILOT_WEB_RELAY_DATA_DIR le dossier de données (base de données, verrou et fichiers envoyés) et COPILOT_WEB_RELAY_LOG_DIR le dossier des journaux. Dans config.json, la clé dataDir déplace aussi le dossier de données ; la variable d’environnement l’emporte. Un dataDir relatif part du dossier de config.json.

Ajouté en 0.9.14 Les fichiers envoyés suivent aussi le dossier de données : <dataDir>/uploads. Les fichiers envoyés que des versions antérieures ont laissés dans server/uploads, ou qu’une migration a copiés dans le dossier uploads/ du dossier d’état, sont toujours lus là, sur place.

Ajouté en 0.9.14 Le relais d’une installation globale tourne sur le dossier de données du dossier d’état, quelle que soit la façon dont il est démarré : oar start, le service Linux, les deux modes de démarrage automatique de Windows et un simple gh copilot avec l’extension d’OAR. Un dataDir dans config.json qu’utilisait un ancien relais en démarrage automatique est copié une fois, puis laissé tel quel.

Sous macOS et Linux, le relais rend le dossier de données lisible par vous seul (mode 700), et le fichier de config et les fichiers de la base de données accessibles au seul propriétaire (mode 600).

Déplacer une ancienne installation #

Avant le renommage du projet, l’état se trouvait dans le dossier server/ d’un checkout git, et le fichier de config et les journaux du lanceur d’un checkout dans ~/.config/copilot-remote ($XDG_CONFIG_HOME/copilot-remote quand cette variable est définie ; Windows : %LOCALAPPDATA%\copilot-remote). Une installation globale copie une fois le fichier de config et les journaux de ce dossier dans le dossier d’état, lors de son premier oar setup ou oar copilot. oar start ne migre pas. Pour importer l’état d’un checkout, base de données comprise :

oar setup --migrate-from /home/dev/projects/old-oar

Le dossier est le checkout lui-même, pas son dossier server/. Ce qui se passe :

• La commande copie la base de données (avec ses fichiers -wal et -shm), le fichier de config, les stockages d’agents Cursor qui se trouvaient dans data/ (seulement s’il y avait une base de données), le dossier uploads et le dossier logs s’il fait 50 Mo ou moins.
• Elle ne modifie jamais la source. Supprimez vous-même l’ancien dossier quand le résultat vous convient.
• Elle refuse tant qu’un relais tourne encore depuis la source, et le signale.
• Elle vérifie la copie avant de la valider : la base de données doit passer le contrôle d’intégrité de SQLite et contenir le même nombre de conversations et de messages. Sinon, elle supprime ce qu’elle a copié, Ajouté en 0.9.14 et non plus tout le dossier d’état, et laisse un message.
• Ajouté en 0.9.14 Elle n’écrase jamais rien. Un config.json déjà présent dans le dossier d’état est conservé. La base de données vide créée par le relais d’un installateur est déplacée dans backups/ (arrêtez d’abord le relais : oar stop) ; une base de données qui contient des conversations la fait refuser, et elle indique quoi faire à la place. Pendant qu’elle copie une base de données, elle détient le verrou du relais, si bien qu’aucun relais ne démarre dessus entre-temps.
• Elle écrit un reçu dans backups/MIGRATION.md et un fichier marqueur .migrated dans le dossier d’état.

Ajouté en 0.9.14 Les fichiers envoyés migrés arrivent dans data/uploads/, où le relais les lit, et les stockages d’agents Cursor dans data/cursor-agents/, que le relais lit par défaut. Les fichiers envoyés qu’une migration antérieure a laissés dans le dossier uploads/ du dossier d’état sont fusionnés dans data/uploads/ au démarrage suivant du relais ; rien n’est écrasé ni supprimé. Les dossiers liés par lien symbolique dans le checkout sont copiés comme de vrais dossiers.

Ce qu’il contient #

Les chemins sont relatifs au dossier d’état. « Supprimable sans risque » signifie que le relais fonctionne ensuite ; cela ne dit rien de ce que vous perdez.

Hors du dossier d’état, le lanceur oar de l’installateur se trouve dans ~/.local/bin/oar (seulement dans les cas où il installe dans ~/.oar/npm), et le service Linux est ~/.config/systemd/user/oar.service. Leur suppression est décrite dans Supprimer OAR. Ajouté en 0.9.15 oar uninstall supprime le service et le paquet et laisse le dossier d’état tel quel ; oar uninstall --purge le supprime, une fois que vous avez tapé delete.

Un checkout git garde les mêmes fichiers dans server/. Les images générées ne sont pas dans le dossier d’état, voir Hors du dossier d’état.

La base de données #

La base de données est un unique fichier SQLite, copilot.db. Le relais la crée à son premier démarrage. Elle contient ce que vous appelleriez vos données :

• les conversations et leurs messages, avec le fil de la conversation, l’index des pièces jointes et les messages épinglés
• la queue des messages, les messages en file et en attente, et les questions posées par un agent
• les réglages du relais que vous modifiez dans l’interface web (les interrupteurs valables pour toute l’app, les réglages des fournisseurs, le choix de rétention, les préférences de mise à jour, les listes de modèles)
• les clés d’API OpenAI, Cursor et Ajouté en 0.9.17 DeepSeek, si vous les avez saisies
• les relais associés et leurs tokens, et les abonnements qui surveillent des sessions sur ce relais et sur des relais associés
• les abonnements web push de vos appareils et les clés push du relais
• les liens des conversations partagées
• les enregistrements des subagents et des workflows, l’activité et les réflexions par conversation
• l’index des fichiers envoyés et des messages qui les utilisent
• les instantanés de consommation pour les jauges du forfait dans Check Usage (Vérifier la consommation), et Ajouté en 0.9.17 ce que compte la carte DeepSeek : les tokens et les recherches des turns DeepSeek par modèle et par jour, les derniers totaux signalés par chaque session DeepSeek, et les relevés de solde par rapport auxquels sa barre est mesurée
• les chats d’images : leurs opérations et les liens entre les images générées
• les cartes d’aperçu

Les migrations s’exécutent d’elles-mêmes à chaque démarrage du relais. Elles créent ce qui manque et ajoutent des colonnes, et les relancer ne change rien. Vous ne les lancez pas et ne pouvez pas les sauter.

Sauvegarder #

OAR n’a pas de commande de sauvegarde. La base de données tourne en mode d’écriture anticipée de SQLite, si bien que les modifications récentes peuvent se trouver dans le fichier -wal à côté d’elle. Pour la sauvegarder :

1. Arrêtez le relais avec oar stop.
2. Copiez ensemble copilot.db et, s’ils existent, copilot.db-wal et copilot.db-shm.
3. Redémarrez le relais.

Pour restaurer, arrêtez le relais et remettez les fichiers copiés tels qu’ils étaient. Ne copiez pas copilot.db seul pendant que le relais tourne, et ne mélangez pas un fichier de base de données avec le fichier -wal d’une autre copie. Une sauvegarde contient vos clés d’API et vos tokens, voir Où se trouvent les secrets ; gardez-la aussi privée que le dossier d’état.

Journaux #

Le moteur d’extension Copilot n’a pas de journal de worker : c’est le terminal propre de la CLI Copilot. Un relais lancé comme service systemd écrit aussi dans le journal système, voir Démarrer le relais automatiquement.

Un checkout git démarré avec npm start garde ses journaux dans server/logs. Un checkout démarré avec oar start ou oar copilot les garde dans ~/.config/copilot-remote/logs (Windows : %LOCALAPPDATA%\copilot-remote\logs), sauf si COPILOT_WEB_RELAY_LOG_DIR indique un autre dossier.

Où se trouvent les secrets #

Pendant qu’un worker démarre sous tmux, le relais écrit la clé de son fournisseur (la clé OpenAI, Cursor ou Ajouté en 0.9.17 DeepSeek, ou un CLAUDE_CODE_OAUTH_TOKEN tiré de l’environnement du relais pour un worker Claude Cloud ou, Ajouté en 0.9.17, Claude) dans un fichier temporaire du dossier temporaire du système, lisible par vous seul. Le shell du worker le lit une fois et le supprime. Chaque worker ne reçoit que la clé de son propre fournisseur.

Rétention #

Le relais supprime ces éléments de lui-même. Rien d’autre n’est supprimé, sauf si vous supprimez une conversation.

Supprimer une conversation supprime de la base de données ses messages, ses entrées de queue, ses questions et les enregistrements de ses subagents, ainsi que le fil de la conversation Claude et les images générées qui lui appartiennent. Ajouté en 0.9.17 Pour une conversation DeepSeek, cela supprime aussi, dans data/deepseek-claude/, le fil de la conversation, les dossiers de la session, ce qu’a laissé son Claude Code arrêté (son inscription, l’environnement des hooks et l’instantané de shell) et le dossier du projet dès qu’aucune autre session ne l’utilise, et, dans la base de données, les derniers totaux signalés par ses sessions. Ce qu’elle a ajouté aux totaux et aux jours de la carte DeepSeek reste. Ce que chaque fournisseur garde lui-même est décrit dans la section suivante.

Hors du dossier d’état #

Avant 0.9.14, les stockages Cursor se trouvaient par défaut dans server/data/cursor-agents, à l’intérieur du dossier du paquet, qu’une mise à jour remplace : une conversation pouvait donc perdre son agent stocké et en recevoir un nouveau (voir Cursor). Une conversation dont le stockage est encore à cet ancien emplacement continue de l’utiliser là, et une conversation qui a un stockage aux deux endroits utilise celui qui a été modifié en dernier ; rien n’est déplacé ni supprimé.

Le travail de vos agents, les fichiers de vos dossiers de projet, se trouve entièrement hors du stockage d’OAR.

Un relais par dossier de données #

Le relais crée relay-server.lock dans le dossier de données au démarrage et le supprime quand il s’arrête. Le fichier contient le numéro de processus du relais, un hash de son token et son heure de démarrage.

Si un second relais démarre sur le même dossier de données pendant que le premier tourne, le second affiche une ligne et quitte, Ajouté en 0.9.14 avec le code 78 (code 1 auparavant), que le service Linux ne relance pas :

Relay already running (pid=4242, startedAt=2026-01-05T09:12:40.000Z; lock /home/dev/.oar/data/relay-server.lock). It is held by relay process 4242: oar stop, or end process 4242.

Relay appears to be owned by another live process au lieu de Relay already running signifie que le relais en marche a un autre token. Quand on ne peut pas établir que le détenteur est un relais, l’indication est If no relay is running, end process 4242 or delete the lock. oar start affiche la même indication après The relay did not come up. Le premier relais n’est pas touché. Les messages restent en attente quand le relais que vous attendiez n’est pas celui qui tourne ; oar doctor affiche la config et la base de données utilisées.

Après un plantage ou une coupure de courant, le fichier de verrou reste en place. Ajouté en 0.9.14 Un verrou datant d’avant le dernier démarrage de la machine, ou dont le numéro de processus appartient désormais à un processus démarré après lui, est périmé : le démarrage suivant le met de côté, consigne Recovered stale singleton lock et reprend le verrou. Cela ne dépend plus de l’horloge : un saut d’horloge ne fait donc pas passer un relais en marche pour disparu, et deux démarrages qui récupèrent le même verrou ne tournent pas tous les deux. Un verrou illisible (un verrou vide laissé par une coupure de courant) est relu et compte comme détenu, sauf si son heure est décalée de plus de 10 secondes. oar start ne supprime plus un verrou écrit par cette version ; il supprime toujours celui d’une version antérieure quand rien ne répond sur le port du relais.

Deux relais peuvent tourner côte à côte quand ils ont des dossiers de données et des ports distincts. Voir La commande oar pour savoir comment oar trouve le relais, et Redémarrages et reprise pour ce qu’un redémarrage conserve.