OAR aktualisieren Neu in 0.9.2

OAR aktualisiert sich nicht im Hintergrund. Ein Relay kann nach einem neueren Release suchen, es dir in Settings (Einstellungen) anzeigen und es installieren, wenn du Update (Aktualisieren) drückst oder oar update ausführst. Nichts wird ohne dich installiert, und die Prüfung, die ein Release findet, ist aus, bis du sie einschaltest.

Die Update-Prüfung #

Die Prüfung ist standardmäßig aus. Ein Relay, dem nie etwas anderes gesagt wurde, schickt nichts an oar.sh.

1. Öffne Settings → General (Einstellungen → Allgemein).
2. Schalte Check for updates automatically (Automatisch nach Updates suchen) ein.

Ist sie an, fragt das Relay oar.sh etwa zweimal am Tag nach der neuesten Version: alle 12 Stunden, plus oder minus bis zu einer Stunde, damit nicht viele Relays gleichzeitig fragen. Es fragt außerdem einmal, wenn du den Schalter einschaltest, und einmal bei jedem Start des Relays mit eingeschaltetem Schalter. Schaltest du den Schalter aus, hört das Fragen auf.

Der Button Check for updates (Nach Updates suchen) prüft einmal, egal, was der Schalter sagt. Die Zeile daneben lautet Last checked <date and time> oder Never checked.

Was die Prüfung abfragt #

Das Relay fragt eine Datei ab, das Manifest https://oar.sh/latest.json: ein einfaches GET mit einem Header Accept: application/json und, sobald es eine gibt, einem Header If-None-Match mit dem Tag der letzten Antwort, sodass ein unverändertes Manifest keinen Download kostet. Die Anfrage enthält keine Version, kein Token, kein Konto und keine Angaben zum Rechner. Sie wartet höchstens 5 Sekunden. Es gibt keinen anderen Kontakt zu oar.sh. Ein Update zu installieren spricht mit der npm-Registry, nicht mit oar.sh.

Das Manifest hat einen Eintrag pro Kanal mit der neuesten Version, ihrem Release-Datum, einem Link zu ihren Release Notes und einem Flag 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
    }
  }
}

Das Relay liest den Eintrag seines eigenen Kanals (siehe Kanäle) oder den stabilen Eintrag, wenn sein Kanal keinen hat. minNode nennt das älteste Node.js, auf dem das Release läuft; weder das Relay noch die Installer lesen es.

Eine automatische Prüfung, die fehlschlägt (kein Netz, eine Zeitüberschreitung, eine fehlerhafte Antwort), sagt nichts und versucht es beim nächsten Intervall wieder. Ein Klick auf Check for updates, der keine brauchbare Antwort bekommt, zeigt den Hinweis Update check failed — the update server could not be reached. Ein Manifest mit einer anderen schemaVersion als 1 hält die Prüfungen an, bis das Relay neu startet, und hängt The relay could not read the update feed — try updating manually. an die Zeile neben dem Button an.

Wenn eine Version gefunden wird #

Eine neuere Version erscheint als Zeile unter Check for updates in Settings → General:

OAR 0.9.19 available

mit einem Link release notes und den Buttons Update und Dismiss (Schließen). Es gibt kein Banner und keinen Badge anderswo, und mit ausgeschalteter Prüfung erscheint nichts, weil keine neuere Version bekannt ist. Dismiss blendet diese Version aus, bis eine noch neuere erscheint. Ein als critical markiertes Release lautet OAR 0.9.19 available — critical update, lässt sich nicht ausblenden und installiert sich trotzdem nie von selbst. Bei einem git-Checkout hat die Zeile keinen Button Update; sie sagt This relay runs from a git checkout — pull and restart to update.

Die Prüfung endgültig abschalten #

Setz OAR_NO_UPDATE_CHECK=1 in der Umgebung des Relays. Das Relay stellt dann überhaupt keine Anfrage mehr, auch nicht, wenn du Check for updates drückst: Schalter und Button sind deaktiviert, und eine Zeile sagt Update checks are disabled by OAR_NO_UPDATE_CHECK in this relay's environment. oar update ohne --to verweigert ebenfalls. OAR_UPDATE_MANIFEST_URL richtet das Relay und oar update auf ein anderes Manifest aus. Siehe Umgebungsvariablen.

Aus der Weboberfläche aktualisieren #

Drück Update in Settings → General. Das funktioniert bei einer globalen Installation, wie sie der Installer und npm install -g anlegen.

1. Das Relay führt npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar@<version> aus (Neu in 0.9.14 mit @oar-sh/oar in der Liste; siehe Mit npm installieren). Unter macOS und Linux nutzt es das npm neben dem Node.js, auf dem das Relay läuft, und installiert in den Ordner, in dem das Paket schon liegt. Das deckt alle drei Layouts des Installers ab: deinen eigenen globalen npm-Ordner, ~/.oar/npm, wenn dein npm-Ordner Root-Rechte brauchte, und ~/.oar/npm mit OARs eigenem Node.js. Unter Windows führt es npm.cmd aus dem PATH aus. npm hat 10 Minuten Zeit.
2. Die Statuszeile lautet Updating to <version>…, und ein Update log (Update-Log) klappt mit der Ausgabe von npm auf. Cancel update (Update abbrechen) stoppt npm.
3. Wenn npm fertig ist, lautet die Zeile npm finished — the relay restarts once the running turns finish. Das Relay fordert seinen eigenen Neustart an. Es wartet auf laufende Turns; Nachrichten, die du währenddessen schickst, warten in der Queue und laufen nach dem Neustart. Ein Banner auf jedem verbundenen Gerät zeigt das Warten an, mit Restart now (Jetzt neu starten) und Cancel restart (Neustart abbrechen). Neu in 0.9.13 Nach Ask after a queued relay restart has waited (Nachfragen, nachdem ein eingereihter Relay-Neustart gewartet hat) (standardmäßig 30 Minuten) fragt es, ob es jetzt neu starten, weiter warten oder abbrechen soll. Siehe Neustarts und Fortsetzen.
4. Das Relay startet neu, und die Seite verbindet sich von selbst wieder. Der Neustart läuft nicht über systemd oder einen anderen Dienstmanager; siehe Autostart.

Schlägt npm fehl, lautet die Zeile Update failed: <reason>, und das Log zeigt, warum. Das Relay läuft mit der alten Version weiter.

Wie das Relay das Ergebnis prüft #

Bevor es neu startet, notiert das Relay, welche Version es zu installieren versucht hat. Beim nächsten Start vergleicht es das mit der Version, die es ausführt. Stimmen sie überein, erscheint Updated to <version>. Weichen sie ab, zum Beispiel weil npm das Paket nicht ersetzt hat, erscheint Update to <version> did not apply. mit dem Ende des npm-Logs. Eine Notiz, die älter als 7 Tage ist, fällt ohne Meldung weg. Dismiss neben der Zeile entfernt sie.

Aus einem Terminal aktualisieren #

oar update

Es sucht die neueste Version deines Kanals im Manifest, installiert sie mit npm install -g und bittet ein laufendes Relay, neu zu starten, sobald seine Queue leer ist. Gibt es nichts Neueres, gibt es Already up to date (<version>). aus. Optionen und Exit-Codes stehen unter oar update.

Um eine bestimmte Version zu installieren, auch eine ältere, nenn sie mit einem Leerzeichen hinter dem Flag:

oar update --to 0.9.9

--to liest die npm-Registry und überspringt das Manifest, es funktioniert also auch mit OAR_NO_UPDATE_CHECK=1. Schreib --to 0.9.9, nicht --to=0.9.9: Die zweite Form wird ignoriert und installiert das neueste Release deines Kanals.

Der Installer ist ein weiterer Weg. Er installiert das Paket neu, ihn erneut auszuführen aktualisiert also; siehe Installation.

Kanäle #

Es gibt zwei Kanäle, stable und beta. Eine Beta-Version sieht aus wie 0.9.19-beta.1 und wird unter dem stabilen Release mit derselben Nummer einsortiert.

Ein Relay hat keine Kanal-Einstellung. Es folgt dem Kanal der Version, die es ausführt: Eine Beta-Version folgt beta, jede andere folgt stable. Das gilt für seine eigene Prüfung und für oar update.

Einem Beta-Relay wird angeboten, welche Version auch immer das Manifest unter beta listet, solange sie neuer ist als die laufende. Listet der Beta-Eintrag ein stabiles Release, wie es beide Einträge für 0.9.19 tun, wechselt ein Beta-Relay darauf und folgt ab dann stable. Für eine ältere Version brauchst du --to.

Was ein Update unberührt lässt #

Sessions, die liefen #

Der Neustart wartet, bis kein Turn mehr läuft, dann startet das Relay mit dem neuen Code. Agent-Prozesse, die vor dem Update gestartet wurden, haben den alten Code, bis sie neu starten. Der Agent einer Session lernt seine Tools beim Start. Das Release 0.9.10 ist ein Beispiel: Eine Session, die schon vor dem Update lief, bietet weder subscribe noch usage von remote_relay (jetzt relay_tool) an, bis ihr Agent neu startet. In 0.9.11 kann ein vor dem Update gestarteter Worker seine Hintergrund-Tasks nicht an das neu gestartete Relay melden. In 0.9.12 braucht die Konsole eines Befehls einen nach dem Update gestarteten Agent, und dasselbe gilt für die Terminals von Grok in der Task-Leiste. In 0.9.13 braucht die Markierung für einen Befehl, der in tail geleitet wird, einen nach dem Update gestarteten Agent, weil der Agent die Befehlszeile meldet. Kill session (Session beenden) auf einer untätigen Session startet sie neu, und die nächste Nachricht startet einen neuen Agent. Siehe Neustarts und Fortsetzen.

Provider-CLIs #

OAR aktualisiert nur sich selbst. Die Kommandozeilen-Tools von Claude, Grok und GitHub Copilot sind eigene Programme; siehe Die CLI eines Providers installieren oder aktualisieren.

Gut zu wissen #

• Cursor bei einer globalen Installation. Neu in 0.9.14 Die Cursor-Agent-Speicher liegen in cursor-agents im Datenordner des Relays, ein Update ersetzt sie also nicht mehr. Vor 0.9.14 lagen sie standardmäßig im Paketordner, und eine Konversation, deren Speicher ein Update entfernt hatte, bekam einen neuen Agent. Siehe Dateien und Ordner und Cursor.
• Windows. Eine globale Installation führt das Relay aus dem OAR-Zustandsordner (%APPDATA%\oar) aus, nicht aus dem Paketordner, ein Update kann das Paket also ersetzen, während das Relay läuft. Die Autostart-Einträge starten das installierte Paket; siehe Autostart.

Ein git-Checkout #

Ein Checkout aktualisiert sich nie selbst, und weder Update noch oar update funktionieren darauf. Pull, installiere und starte das Relay dann mit 🌄 Restart web relay (Web-Relay neu starten) im ⋯-Menü einer Konversation neu:

git pull
npm install

Siehe Installation.

Upgrade-Hinweise #

Schritte, die ein Update von dir braucht, das neueste Release zuerst. Nicht aufgeführte Releases brauchen keine.

0.9.19 Neu in 0.9.19 #

• Keine Migrationen. Die Rückkehr zu 0.9.18 braucht keinen Schritt: 0.9.18 ignoriert heapLimitMb, und der Ordner diagnostics bleibt, wie er ist.
• Das Relay hat jetzt ein Heap-Limit und schreibt einen Heap-Snapshot nach diagnostics im Datenordner, wenn es sich ihm nähert. Ein Snapshot enthält das Zugriffstoken und die API-Keys: Teile nie einen unverändert.
• Nach dem Update oar einmal stoppen und wieder starten. Der Prozess, der das Relay startet und überwacht, behält den Code, mit dem er gestartet ist: Ein Neustart durch das Update, aus der Weboberfläche oder mit oar restart ohne den systemd-Dienst startet nur das Relay in ihm neu. Bis dieser Prozess mit 0.9.19 startet, läuft das Relay ohne Heap-Limit, heapLimitMb und Heap-Snapshot, und ein Relay, dem der Speicher ausgeht, bleibt weiterhin gestoppt. Unter dem systemd-Dienst von Linux führ oar restart aus, sonst oar stop und danach oar start. Bei einem Relay, das oar copilot gestartet hat, beende diese Session und starte sie neu.
• Agent-Sessions, die vor 0.9.19 gestartet wurden, behalten ihre Provider-Liste. Ihre Worker laufen durch das Update weiter, mit dem relay_tool, mit dem sie gestartet sind. Diese Liste ist die von 0.9.19, also ändert sich jetzt nichts; ihr fehlen die Provider, die ein späteres Update bringt, bis der Worker der Session neu startet, zum Beispiel nach ☠️ Kill session im ⋯-Menü.
• Node.js 22.13 oder neuer reicht weiterhin.

0.9.18 Neu in 0.9.18 #

• Migrationen 0031 bis 0034 laufen beim ersten Start von selbst: 0031 versieht jede eingereihte Nachricht mit ihrem Provider, 0032 fügt die Spalten des Abrechnungswechsels hinzu, und 0033 und 0034 fügen die Tabellen der Verbrauchskarte von Claude API hinzu. Eine ältere Version ignoriert die neuen Spalten und Tabellen. Die zwei Trigger, die 0031 auf die Queue-Tabelle setzt, füllen dort weiter ihre neue Spalte, was nicht schadet.
• Das Agent-Tool heißt jetzt relay_tool. Wenn deine eigenen Anweisungen, Berechtigungsregeln oder Hooks remote_relay oder mcp__relay__remote_relay nennen, ändere sie auf relay_tool oder mcp__relay__relay_tool. Siehe Der Name.
• Bevor du auf 0.9.17 zurückgehst, stell Claude-Chats auf dem Claude-API-Key zurück auf Subscription (Abo). 0.9.17 kennt Claude API nicht: Es bindet einen Chat eines Providers, den es nicht kennt, an Copilot, ein Chat, der auf dem Key bleibt, läuft dort also als Copilot-Chat. Das gilt auch für einen Chat, der auf dem Abo gestartet und auf den Key umgestellt wurde.
• Zurück auf 0.9.17 schaltet Hooks in DeepSeek-Chats wieder ein. Sie führen wieder die Hooks und die Statuszeile ihrer Einstellungsordner aus; siehe Ordner-Einstellungen können DeepSeek nicht umleiten.
• Node.js 22.13 oder neuer reicht weiterhin.

0.9.17 Neu in 0.9.17 #

• Migrationen 0024 bis 0030 fügen die Tabellen der Verbrauchskarte von DeepSeek hinzu: die Ausgaben nach Modell und nach Tag, das Guthaben, an dem sie misst, und, in 0030, die Zahlen eines importierten Verbrauchsexports. Sie laufen beim ersten Start von selbst, auch auf einem Relay, das DeepSeek nie nutzt, und berühren keine Tabelle, die eine ältere Version nutzt. Eine ältere Version ignoriert sie.
• Ein Claude-Login-Token in der Umgebung des Relays (CLAUDE_CODE_OAUTH_TOKEN) erreicht nur Claude- und Claude-Cloud-Worker. Worker von Copilot, OpenAI, Cursor, Grok und DeepSeek starten ohne es, mit oder ohne tmux. Siehe Welche Variablen die Agents erreichen.
• ANTHROPIC_API_KEY und ANTHROPIC_AUTH_TOKEN in der Umgebung des Relays erreichen keinen Worker. Claude-Chats, die auf einem solchen Key liefen, laufen jetzt auf der Claude-Anmeldung des Hosts. Hat der Host keine, melde dich mit Relogin (Neu anmelden) unter Settings → Providers → Claude (Einstellungen → Provider → Claude) an. Siehe Umgebungsvariablen.
• Ein Relay, das aus einer Claude-Code-Session heraus gestartet wurde, gibt diese Session nicht mehr an seine Worker weiter. Ihre Variablen werden für jeden Worker entfernt, auch unter einem tmux-Server, der sie noch trägt. Deine eigenen CLAUDE_CODE_*-Einstellungen bleiben. Siehe Welche Variablen die Agents erreichen.
• Eine Session, die einer von Hand sortierten Gruppe beitritt, kommt zuerst in der Gruppe, nicht mehr zuletzt. Siehe Session-Gruppen.
• Node.js 22.13 oder neuer reicht weiterhin, und keine Einstellung und kein Key in config.json muss geändert werden.

0.9.16 Neu in 0.9.16 #

• Drei Datenbank-Migrationen laufen beim ersten Start von selbst: 0019 (die Abonnement-Optionen und die eigenen Prompts des beobachtenden Agents), 0020 für den Schalter Agents in this conversation may start sessions (Agents in dieser Konversation dürfen Sessions starten) und 0021 (welche Session-Gruppen ein Agent angelegt und welche deiner Gruppen ein Agent geleert hat). Sie fügen nur Spalten und eine Tabelle hinzu. Zurück auf eine ältere Version braucht keine Datenänderung: Sie ignoriert sie, behält die Regel mit nur einer Ebene und entfernt eine leere Gruppe wie bisher bei ihrem Start.
• Migration 0022 fügt die Tabelle für geplante Prompts hinzu, mit der Herkunft der Nachrichten jedes Zeitplans (origin_json, mit ihren Hops) und dem Zeitpunkt, ab dem eine Auslösung für dich zurückgehalten wurde (held_since). Sie läuft beim ersten Start von selbst, zusammen mit 0019 bis 0021.
• Migration 0023 fügt die Tabelle für Fragen, die nicht blockieren (relay_asks), hinzu. Auch sie läuft beim ersten Start von selbst. Eine ältere Version ignoriert sie.
• Abonnements, die question_asked nehmen, bekommen ab jetzt auch question_answered, deine Antwort auf eine Frage.
• Der Schleifenschutz zählt nur deine eigenen Nachrichten als deine. Vor 0.9.16 setzten ein Relay-Ereignis, die Nachricht nach einem Nutzungslimit oder die Notiz nach einem Neustart den Zähler der Prompts zurück, die ein Agent anderen Agents schicken darf, bevor du gefragt wirst, sodass zwei Agents, die sich gegenseitig beobachteten, ohne dich weitermachen konnten. Jetzt setzt ihn nur eine Nachricht zurück, die du schreibst, und Agents in einer solchen Schleife fragen dich früher. Siehe die Regeln.
• Agents, die Argumente übergeben, die eine Aktion nicht nimmt: create_session und update_session verweigern den Aufruf jetzt und ändern nichts; die anderen Aktionen laufen weiter und nennen sie in ignored. Siehe Aktionen.
• Ein beobachtender Agent, der auf die Antwort auf seinen eigenen Prompt gewartet hat, bekommt das turn_end dieses Turns nicht mehr zusätzlich als Ereignis.
• Node.js 22.13 oder neuer reicht weiterhin, und keine Einstellung und kein Key in config.json muss geändert werden.

0.9.15 #

• Von 0.9.14 mit einem selbst angelegten Autostart-Task unter Windows: Der Wechsel in den Modus beim Hochfahren konnte in 0.9.14 einen vorhandenen Task mit demselben Namen (oar-relay oder den von vor der Umbenennung) ohne Kopie löschen. 0.9.15 behält einen solchen Task und verlangt --replace, das vorher eine Kopie sichert. Ist ein Task von dir schon weg, hat OAR keine Kopie davon.
• Der Autostart-Wechsel ersetzt nichts mehr, was OAR nicht angelegt hat. Ein von Hand bearbeiteter Start-Task oder Launcher, ein Task, den jemand anderes angelegt hat, der Start-Task von vor der Umbenennung und ein selbst angelegter Autostart-Eintrag halten den Wechsel jetzt an, in der Weboberfläche wie in oar autostart, wo 0.9.14 sie ersetzt hat. oar autostart <mode> --replace ersetzt sie und behält von jedem eine Kopie. Siehe Einträge, die OAR nicht angelegt hat.
• Neue Befehle: oar autostart und oar uninstall, und oar setup fragt unter Windows nach dem Autostart-Modus. Siehe Der Befehl oar.
• Das Paket ist kleiner: Die Entwickler-READMEs, server/README.md mit der HTTP-API und das der Web-Relay-Extension, sind nicht mehr darin. Sie liegen im Repository auf GitHub.
• Node.js 22.13 oder neuer reicht weiterhin, und keine Einstellung und kein Key in config.json muss geändert werden.

0.9.14 #

0.9.14 kopiert diese Daten zuerst, während es installiert, nach rescued-package-data/<time>/ im OAR-Datenordner (%APPDATA%\oar\data, ~/.oar/data), und das Relay übernimmt die Kopie bei seinem nächsten Start. npm 10 und 11 führen diese Kopie aus (11.21 mit einer Warnung), und wenn sie fehlschlägt, stellen sie die alte Version samt Daten wieder her. npm 12 überspringt sie, außer @oar-sh/oar ist erlaubt: Die Installation gelingt dann, und die alten Daten sind weg. Mit strict-allow-scripts verweigern npm 11 und 12 die Installation und ändern nichts. Ein Eintrag allow-scripts in .npmrc hilft dem Button Update und oar update von 0.9.13 nicht, weil ihr eigenes --allow-scripts ihn ersetzt. Um sicherzugehen, mach dieses Update von Hand:

1. Schließ jede gh copilot-Session (ihre Extension startet das Relay wieder), führ dann oar stop aus und warte, bis oar status sagt, dass es nicht läuft. Wenn das oar stop von 0.9.13 ein Relay nicht stoppt, das der Launcher für den Start beim Hochfahren gestartet hat, beende das Relay vor der Installation: Beende die Prozesse des Relays im Task-Manager (node.exe, auf dem OAR läuft).
2. Führ npm root -g aus und öffne <that folder>/@oar-sh/oar/server (meist %APPDATA%\npm\node_modules\@oar-sh\oar\server). Kopier beide Ordner, data und uploads, mit allen Dateien darin an einen sicheren Ort.
3. Aktualisiere mit erlaubten Installationsskripten von npm: npm install -g --allow-scripts=@oar-sh/oar,better-sqlite3,koffi @oar-sh/oar. Aktualisiere nie mit --ignore-scripts: Das überspringt die Kopie und die nativen Module (better-sqlite3, koffi), sodass das Relay danach nicht starten kann.
4. Bevor du das Relay startest, kopier beide Ordner zurück in denselben Ordner server.
5. Führ oar start aus. Such in relay-console.log im OAR-Ordner logs nach [data] Brought over the database …: Deine Konversationen sollten wieder da sein. Eine Datenbank, die schon im OAR-Datenordner lag, wird in backups/<time>/ im OAR-Ordner (%APPDATA%\oar, ~/.oar) aufbewahrt. Der übernommene Ordner behält seine Datenbank als copilot.db.adopted-<time>; die anderen geprüften behalten ihre als copilot.db.older-<time>. Nichts wird gelöscht.
6. Stoppt das Relay mit [data] Not starting: each database has changes newer than the other's, enthalten beide Arbeit. Die Zeile nennt beide Ordner; einer liegt vielleicht unter rescued-package-data/<time>/data. Wähl den, den du behalten willst, verschieb copilot.db, copilot.db-wal und copilot.db-shm des anderen in einen eigenen Ordner (lösch sie nicht) und führ dann oar start erneut aus.
7. Hast du schon ohne Sichern aktualisiert und wurde nichts kopiert, kann OAR die Datenbank nicht aus dem Paket wiederherstellen.

Außerdem in 0.9.14:

• Ein Relay, das nicht auf seinen Daten laufen kann, stoppt mit Exit-Code 78: wenn ein anderes Relay seinen Lock hält, wenn zwei Datenbanken beide neuere Arbeit enthalten oder wenn sein Daten- oder Upload-Ordner nicht angelegt werden kann. Die Zeile vor dem Beenden sagt, was davon und was zu tun ist. Eine systemd-Unit, die oar service install von 0.9.14 geschrieben hat, startet es nicht neu; führ oar service install erneut aus, um diese Unit zu bekommen. Siehe Ein Relay pro Datenordner.
• Eine große Datenbank zu übernehmen dauert Minuten. Das Relay protokolliert ihre Größe, den Fortschritt mindestens einmal pro Minute und die Dauer jedes Schritts, und oar start sagt währenddessen, dass es sie noch übernimmt. Starte kein zweites Relay.
• Der Windows-Autostart wartet jetzt bis zu 5 Minuten auf %TEMP% und das Datenlaufwerk, und der erste Start nach dem Update bringt einen erzeugten Eintrag oder Launcher auf den neuesten Stand. Siehe Autostart.
• Cursor-Agent-Speicher ziehen nach cursor-agents im Datenordner um, und Uploads folgen dataDir; Uploads, die eine frühere Version in server/uploads oder in uploads/ des Zustandsordners hinterlassen hat, werden weiter dort gelesen, wo sie liegen. Siehe Dateien und Ordner.
• Node.js 22.13 oder neuer reicht weiterhin.

0.9.13 #

• Migration 0018 fügt die Tabelle hinzu, die die Task-Konsolen über einen Neustart des Relays hinweg behält, und läuft beim ersten Start von selbst. Die abgeschlossenen Zeilen, die das Relay vor diesem Update im Speicher hielt, gehen beim Neustart hinein ein letztes Mal verloren. Node.js 22.13 oder neuer reicht weiterhin.
• Neue Einstellungen in Settings → General: Ask after a queued relay restart has waited (standardmäßig 30 Minuten) und After a relay restart, tell interrupted sessions to carry on (Nach einem Relay-Neustart unterbrochene Sessions weitermachen lassen) (standardmäßig aus). Eine neue Benachrichtigung, Queued relay restart waited its maximum time (Eingereihter Relay-Neustart hat die Höchstzeit gewartet), ist standardmäßig an. Siehe Einstellungen und Wenn das Warten lang wird.
• Beobachtende Agents: Ein Abonnement, das keine Ereignisse genannt hat, lässt jetzt Shell-Befehle weg, die gut geendet haben; abgeschlossene Subagents und Fehler wecken es weiterhin. Eines, das seine Ereignisse genannt hat, behält sie. Nenn task_finished, um jedes Task-Ende zu bekommen. Siehe Die Standard-Ereignisse.
• Skripte, die eine Nachricht ohne Modell an eine bestehende Konversation schicken, bekommen jetzt das eigene Modell, den Effort und den Modus der Konversation statt des ersten Modells des Relays, oder ein 409 mit dem Code CONVERSATION_MODEL_UNAVAILABLE, wenn dieses Modell aus dem Katalog verschwunden ist. Siehe Modelle und Reasoning.
• Agents, die ein Modell an relay_tool übergeben, müssen eine ID nutzen, die das Ziel listet; eine unbekannte wird jetzt mit REMOTE_RELAY_UNKNOWN_MODEL abgewiesen. Siehe Welche Modelle akzeptiert werden.

0.9.12 #

• Migration 0017 fügt zwei Indizes für den Verlauf langer Konversationen hinzu und läuft beim ersten Start von selbst. Node.js 22.13 oder neuer reicht weiterhin, und keine Einstellung und kein Key in config.json muss geändert werden.
• Zwei neue Einstellungen in Settings → General: Mark a background task as quiet after (Hintergrund-Task als still markieren nach) (standardmäßig 10 Minuten, für das Relay) und Messages kept per conversation for switching back (Pro Konversation behaltene Nachrichten fürs Zurückwechseln) (standardmäßig 200, in jedem Browser). Siehe Einstellungen.
• Claude-Hintergrundbefehle dürfen standardmäßig 2 Stunden laufen und bis zu 8, wenn Claude darum bittet: Settings → Providers → Claude → Claude background command limit (Einstellungen → Provider → Claude → Limit für Claude-Hintergrundbefehle). OAR setzt jetzt BASH_DEFAULT_TIMEOUT_MS, BASH_MAX_TIMEOUT_MS und CLAUDE_CODE_AUTO_BACKGROUND_TIMEOUT_MS für seine Claude-Sessions, Werte davon in der Umgebung des Relays gelten also nicht mehr. Siehe Limit für Hintergrundbefehle.
• Sessions, die laufen, während du aktualisierst, behalten ihren Agent, bis er neu startet, und zeigen bis dahin keine Ausgabe in der Konsole eines Befehls. Siehe Sessions, die liefen.

0.9.11 #

• Hinter einem Reverse Proxy auf einem anderen Rechner setz trustProxy und allowedOrigins. 0.9.11 ist das erste Release, das die Herkunft der Live-Verbindung prüft und Client-Adresse, Host und Schema nur dann aus X-Forwarded-*-Headern liest, wenn dem Proxy vertraut wird. Einem Proxy oder Tunnel auf dem Rechner des Relays wird bereits vertraut. Für einen auf einem anderen Rechner oder einen, der den Header Host umschreibt, ergänze die zwei Keys in config.json und starte das Relay neu. Ohne sie lädt die Seite, bekommt aber keine Live-Updates, und alle Clients teilen sich die Adresse des Proxys und seine Anmeldesperre. Siehe Ein Proxy auf einem anderen Rechner.
• Zehn falsche Tokens von einer Adresse innerhalb einer Minute ergeben 429, bis die Minute um ist. Anfragen vom Rechner des Relays, die nichts weitergeleitet hat, werden nie gezählt. Siehe Schutz bei der Anmeldung.
• ?token= funktioniert nur auf der Seitenadresse. Skripte, die API-, Datei- oder Asset-Adressen mit ?token= abrufen, müssen stattdessen Authorization: Bearer <token> schicken, oder das Cookie; ein Socket.IO-Client übergibt es als auth.token. Siehe Wie du es vorzeigst.
• Restart web relay, das Abbrechen eines eingereihten Neustarts und Empty queue brauchen nur das Token, von jedem angemeldeten Gerät. Der Socket des Session-Workers und das Ausführen von Bildoperationen beantworten nur Anfragen vom Rechner des Relays, die kein Tunnel und kein Proxy weitergeleitet hat. Siehe Endpunkte, die nur der Rechner des Relays nutzen darf.
• Vier Datenbank-Migrationen (Previews, Session-Gruppen, der Platz in einer Gruppe, das Zugriffsprotokoll beim Teilen) laufen beim ersten Start von selbst. Node.js 22.13 oder neuer reicht weiterhin.
• Abhängigkeiten sind fest gepinnt. Die Pakete, die OAR direkt nutzt, darunter die SDKs von Claude, Copilot und Cursor, werden in genau den Versionen installiert, mit denen das Release getestet wurde; eine neuere kommt mit einem OAR-Update.

Was sich geändert hat #

Das Changelog steht auf oar.sh und im Repository als CHANGELOG.md. Jedes Release hat außerdem Release Notes auf GitHub, die der Link release notes in Settings → General öffnet. Schritte, die ein Update von dir braucht, stehen im Eintrag eines Releases unter Upgrade notes (Upgrade-Hinweise), wenn es welche hat.

Wenn es nicht funktioniert #