Dateien und Ordner

OAR legt alles, was ihm gehört, in einem Ordner ab, dem Zustandsordner: die Config-Datei, die Datenbank mit deinen Konversationen, die Logs und die hochgeladenen Dateien. Diese Seite sagt, wo dieser Ordner liegt, was darin ist, welche Teile du löschen kannst, welche Geheimnisse enthalten und was das Relay von selbst entfernt. Manche Daten liegen gar nicht im Zustandsordner: Jeder Provider hält seine eigenen Session-Daten und Anmeldungen in eigenen Ordnern.

Der Zustandsordner #

npm install -g und oar update ersetzen das Paket, fassen den Zustandsordner aber nie an. OAR_STATE_ROOT muss in jeder Shell gesetzt sein, in der du oar ausführst, sonst sucht der Befehl im Standardordner; siehe Umgebungsvariablen. oar doctor gibt die verwendeten Pfade aus: den Zustandsordner, die Config-Datei, die Datenbank und ihre Größe. Dieselben Pfade stehen für jede Installationsart unter Installation.

Drei Umgebungsvariablen verschieben einzelne Teile: COPILOT_WEB_RELAY_CONFIG die Config-Datei, COPILOT_WEB_RELAY_DATA_DIR den Datenordner (Datenbank, Lock und Uploads) und COPILOT_WEB_RELAY_LOG_DIR den Log-Ordner. In config.json verschiebt der Key dataDir den Datenordner ebenfalls; die Umgebungsvariable hat Vorrang. Ein relatives dataDir gilt ab dem Ordner von config.json.

Neu in 0.9.14 Auch Uploads folgen dem Datenordner: <dataDir>/uploads. Uploads, die frühere Versionen in server/uploads hinterlassen haben oder die eine Migration in uploads/ des Zustandsordners kopiert hat, werden weiter an Ort und Stelle gelesen.

Neu in 0.9.14 Das Relay einer globalen Installation läuft auf dem Datenordner des Zustandsordners, egal, wie es gestartet wird: oar start, der Linux-Dienst, beide Windows-Autostart-Modi und ein einfaches gh copilot mit OARs Extension. Aus einem dataDir in config.json, das ein früheres Autostart-Relay genutzt hat, wird einmal kopiert; der Ordner selbst bleibt, wie er ist.

Unter macOS und Linux macht das Relay den Datenordner nur für dich lesbar (Modus 700) und die Config-Datei und die Datenbankdateien nur für den Besitzer zugänglich (Modus 600).

Eine alte Installation umziehen #

Vor der Umbenennung des Projekts lag der Zustand im Ordner server/ eines git-Checkouts, und Config-Datei und Logs des Launchers eines Checkouts in ~/.config/copilot-remote ($XDG_CONFIG_HOME/copilot-remote, wenn das gesetzt ist; Windows: %LOCALAPPDATA%\copilot-remote). Eine globale Installation kopiert Config-Datei und Logs dieses Ordners einmal in den Zustandsordner, bei ihrem ersten oar setup oder oar copilot. oar start migriert nicht. Um den Zustand eines Checkouts samt Datenbank zu importieren:

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

Der Ordner ist der Checkout selbst, nicht sein Ordner server/. Was passiert:

• Es kopiert die Datenbank (mit ihren Dateien -wal und -shm), die Config-Datei, die Cursor-Agent-Speicher, die in data/ lagen (nur wenn es eine Datenbank gab), den Ordner uploads und den Ordner logs, wenn dieser 50 MB oder kleiner ist.
• Es ändert die Quelle nie. Lösch den alten Ordner selbst, wenn du zufrieden bist.
• Es verweigert, solange noch ein Relay aus der Quelle läuft, und sagt das.
• Es prüft die Kopie, bevor sie zählt: Die Datenbank muss die Integritätsprüfung von SQLite bestehen und dieselbe Zahl an Konversationen und Nachrichten enthalten. Wenn nicht, entfernt es, was es kopiert hat, Neu in 0.9.14 nicht mehr den ganzen Zustandsordner, und hinterlässt eine Meldung.
• Neu in 0.9.14 Es überschreibt nie. Eine config.json, die schon im Zustandsordner liegt, bleibt. Die leere Datenbank, die das Relay eines Installers angelegt hat, wird nach backups/ verschoben (stopp vorher das Relay: oar stop); eine Datenbank mit Konversationen lässt es verweigern und sagen, was du stattdessen tun kannst. Während es eine Datenbank kopiert, hält es den Lock des Relays, damit währenddessen kein Relay darauf startet.
• Es schreibt eine Quittung nach backups/MIGRATION.md und eine Markerdatei .migrated in den Zustandsordner.

Neu in 0.9.14 Migrierte Uploads landen in data/uploads/, wo das Relay sie liest, und die Cursor-Agent-Speicher in data/cursor-agents/, das das Relay standardmäßig liest. Uploads, die eine frühere Migration in uploads/ des Zustandsordners hinterlassen hat, werden beim nächsten Start des Relays in data/uploads/ zusammengeführt; nichts wird überschrieben oder gelöscht. Ordner im Checkout, die Symlinks sind, werden als echte Ordner kopiert.

Was darin liegt #

Die Pfade sind relativ zum Zustandsordner. „Gefahrlos löschbar“ heißt, dass das Relay danach funktioniert; es sagt nichts darüber, was du verlierst.

Außerhalb des Zustandsordners liegt der Launcher oar des Installers in ~/.local/bin/oar (nur in den Fällen, in denen er nach ~/.oar/npm installiert), und der Linux-Dienst ist ~/.config/systemd/user/oar.service. Wie du sie entfernst, steht unter OAR entfernen. Neu in 0.9.15 oar uninstall entfernt den Dienst und das Paket und lässt den Zustandsordner, wie er ist; oar uninstall --purge löscht ihn, nachdem du delete eingetippt hast.

Ein git-Checkout hält dieselben Dateien in server/. Generierte Bilder liegen nicht im Zustandsordner, siehe Außerhalb des Zustandsordners.

Die Datenbank #

Die Datenbank ist eine einzelne SQLite-Datei, copilot.db. Das Relay legt sie beim ersten Start an. Sie enthält, was du deine Daten nennen würdest:

• Konversationen und ihre Nachrichten, mit dem Verlauf, dem Index der Anhänge und angepinnten Nachrichten
• die Nachrichten-Queue, eingereihte und wartende Nachrichten und Fragen, die ein Agent gestellt hat
• die Einstellungen des Relays, die du in der Weboberfläche änderst (die App-weiten Schalter, Provider-Einstellungen, die Wahl der Aufbewahrung, Update-Vorlieben, die Modelllisten)
• die API-Keys von OpenAI, Cursor und Neu in 0.9.17 DeepSeek, wenn du sie eingegeben hast
• gekoppelte Relays und ihre Tokens und die Abonnements, die Sessions beobachten, auf diesem und auf gekoppelten Relays
• die Web-Push-Abonnements deiner Geräte und die Push-Keys des Relays
• Links geteilter Konversationen
• Aufzeichnungen von Subagents und Workflows, Aktivität und Überlegungen pro Konversation
• den Index der hochgeladenen Dateien und welche Nachrichten sie nutzen
• Verbrauchs-Snapshots für die Plan-Anzeigen in Check Usage (Verbrauch prüfen), und Neu in 0.9.17 was die DeepSeek-Karte zählt: die Tokens und Suchen von DeepSeek-Turns pro Modell und Tag, die letzten Summen, die jede DeepSeek-Session gemeldet hat, und die Guthabenstände, an denen ihr Balken gemessen wird
• Bild-Chats: ihre Operationen und die Verbindungen zwischen generierten Bildern
• Preview-Karten

Migrationen laufen bei jedem Start des Relays von selbst. Sie legen an, was fehlt, und fügen Spalten hinzu, und ein erneuter Lauf ändert nichts. Du führst sie nicht aus und kannst sie nicht überspringen.

Sichern #

OAR hat keinen Befehl für Backups. Die Datenbank läuft im Write-Ahead-Modus von SQLite, neuere Änderungen können also in der Datei -wal daneben liegen. So sicherst du sie:

1. Stopp das Relay mit oar stop.
2. Kopier copilot.db und, falls vorhanden, copilot.db-wal und copilot.db-shm zusammen.
3. Starte das Relay wieder.

Zum Wiederherstellen stoppst du das Relay und legst die kopierten Dateien so zurück, wie sie waren. Kopier copilot.db nicht allein, während das Relay läuft, und misch keine Datenbankdatei mit der Datei -wal einer anderen Kopie. Ein Backup enthält deine API-Keys und Tokens, siehe Wo Geheimnisse liegen; halte es so privat wie den Zustandsordner.

Logs #

Die Copilot-Extension-Engine hat kein Worker-Log: Sie ist das eigene Terminal der Copilot CLI. Ein Relay, das als systemd-Dienst läuft, schreibt außerdem ins Journal, siehe Das Relay automatisch starten.

Ein git-Checkout, der mit npm start gestartet wurde, hält seine Logs in server/logs. Einer, der mit oar start oder oar copilot gestartet wurde, hält sie in ~/.config/copilot-remote/logs (Windows: %LOCALAPPDATA%\copilot-remote\logs), sofern COPILOT_WEB_RELAY_LOG_DIR keinen anderen Ordner nennt.

Wo Geheimnisse liegen #

Während ein Worker unter tmux startet, schreibt das Relay seinen Provider-Key (den Key von OpenAI, Cursor oder Neu in 0.9.17 DeepSeek oder ein CLAUDE_CODE_OAUTH_TOKEN aus der Umgebung des Relays für einen Claude-Cloud- oder, Neu in 0.9.17, einen Claude-Worker) in eine temporäre Datei im Temp-Ordner des Systems, nur für dich lesbar. Die Shell des Workers liest sie einmal und löscht sie. Jeder Worker bekommt nur den Key seines eigenen Providers.

Aufbewahrung #

Das Relay entfernt Folgendes von selbst. Sonst wird nichts gelöscht, außer du löschst eine Konversation.

Das Löschen einer Konversation entfernt ihre Nachrichten, Queue-Einträge, Fragen und Subagent-Aufzeichnungen aus der Datenbank sowie den Claude-Verlauf und die generierten Bilder, die zu ihr gehören. Neu in 0.9.17 Bei einer DeepSeek-Konversation entfernt es außerdem in data/deepseek-claude/ den Verlauf, die Ordner der Session, was ihr gestopptes Claude Code hinterlassen hat (seine Registrierung, die Hook-Umgebung und den Shell-Snapshot) und den Projektordner, sobald keine andere Session ihn nutzt, und aus der Datenbank die letzten Summen, die ihre Sessions gemeldet haben. Was sie zu den Summen und Tagen der DeepSeek-Karte beigetragen hat, bleibt. Was jeder Provider selbst aufbewahrt, steht im nächsten Abschnitt.

Außerhalb des Zustandsordners #

Vor 0.9.14 lagen die Cursor-Speicher standardmäßig in server/data/cursor-agents im Paketordner, den ein Update ersetzt, sodass eine Konversation ihren gespeicherten Agent verlieren und einen neuen bekommen konnte (siehe Cursor). Eine Konversation, deren Speicher noch am alten Ort liegt, nutzt ihn dort weiter, und eine mit einem Speicher an beiden Orten nutzt den zuletzt geänderten; nichts wird verschoben oder gelöscht.

Die Arbeit deiner Agents, die Dateien in deinen Projektordnern, liegt ganz außerhalb von OARs Speicher.

Ein Relay pro Datenordner #

Das Relay legt beim Start relay-server.lock im Datenordner an und entfernt die Datei, wenn es stoppt. Die Datei enthält die Prozessnummer des Relays, einen Hash seines Tokens und seine Startzeit.

Startet ein zweites Relay auf demselben Datenordner, während das erste läuft, gibt das zweite eine Zeile aus und beendet sich, Neu in 0.9.14 mit Code 78 (vorher Code 1), den der Linux-Dienst nicht neu versucht:

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 statt Relay already running heißt, dass das laufende Relay ein anderes Token hat. Lässt sich vom Halter nicht sagen, ob er ein Relay ist, lautet der Hinweis If no relay is running, end process 4242 or delete the lock. oar start gibt denselben Hinweis nach The relay did not come up aus. Das erste Relay wird nicht angefasst. Nachrichten bleiben ausstehend, wenn das Relay, das du erwartest, nicht das ist, das läuft; oar doctor zeigt die verwendete Config und Datenbank.

Nach einem Absturz oder Stromausfall bleibt die Lock-Datei liegen. Neu in 0.9.14 Ein Lock von vor dem letzten Hochfahren, oder dessen Prozessnummer jetzt einem später gestarteten Prozess gehört, ist veraltet: Der nächste Start legt ihn beiseite, protokolliert Recovered stale singleton lock und übernimmt den Lock. Das richtet sich nicht mehr nach der Uhr, ein Sprung der Uhr lässt ein laufendes Relay also nicht wie verschwunden aussehen, und zwei Starts, die denselben Lock übernehmen, laufen nicht beide. Ein Lock, der sich nicht lesen lässt (ein leerer, den ein Stromausfall hinterlassen hat), wird noch einmal gelesen und gilt als gehalten, außer seine Zeit weicht um mehr als 10 Sekunden ab. oar start entfernt einen Lock, den diese Version geschrieben hat, nicht mehr; einen einer früheren Version entfernt es weiter, wenn auf dem Port des Relays nichts antwortet.

Zwei Relays können nebeneinander laufen, wenn sie getrennte Datenordner und Ports haben. Wie oar das Relay findet, steht unter Der Befehl oar, und was ein Neustart behält, unter Neustarts und Fortsetzen.