Restarts and resuming

Every conversation has its own agent, running in a background process on the relay's machine. The conversation itself, its history, queue and draft, lives in the relay. This page explains how the two fit together, so you know what a Kill session, a relay restart or a reboot costs you and what comes back by itself.

The short version: nothing you wrote is lost. The next message to a conversation starts its agent again if it is not running, and the agent continues the provider's own session, not a blank one.

The agent process of a conversation #

OAR calls this process the session worker. You do not start it. The relay starts it when a conversation needs it, usually with your first message, and the worker connects back to the relay to receive messages and report the reply. On Linux and macOS with tmux installed, workers run in detached tmux sessions, and Inspect tmux console in the ⋯ menu shows one. Without tmux they run as plain background processes.

Added in 0.9.11 Workers run on the relay's own Node.js, by its full path, on every platform, so they start even when the relay's PATH has no node, as for a relay started by the Windows startup task before anyone signed in. COPILOT_WEB_RELAY_NODE sets another one (Environment variables). When a worker's PATH has no node, that Node.js folder is added at its end, so the CLIs and commands a worker starts find one too.

If the worker cannot be started, the conversation shows a 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.

The relay retries every minute for 10 minutes. After that the note says it stopped trying and shows a Retry button. Your message stays queued the whole time, and it is delivered as soon as a worker starts. On Windows a launch that fails or never returns fails at once and names the program, and the relay log names the command and the PATH it was started with.

Stopping by itself #

A Claude or DeepSeek conversation and a GitHub Copilot or OpenAI conversation on the SDK engine free their memory when nothing happens. After 10 minutes with no activity the agent's own program exits, and the next message starts it again and continues the same provider session. The worker process stays and keeps its link to the relay. The app has no setting for the 10 minutes.

The agent is not stopped while any of these is going on:

• a turn is running or queued for it,
• a question or permission card waits for your answer,
• a background task is running, or the continuation of one that just ended is still due.

Background tasks alone can hold it open only until the Background task timeout in Settings → General (default 4 hours; 0 means no limit).

Added in 0.9.17 A DeepSeek conversation also restarts its agent's program when you change its model or reasoning effort, because Claude Code reads both only when it starts. The restart happens before the next turn, when nothing is running in the program, and continues the same session. While background work still runs in it, the turn runs in the program as it is: a new model is switched there, a new effort waits for the restart.

The other providers have no such idle stop. A Claude Cloud, Cursor or Grok worker keeps running until you kill the session, archive the conversation or the machine stops. The Copilot extension engine keeps its Copilot CLI running as well. A Cursor worker that has been unused for 30 minutes closes its agent handle and reopens the same Cursor agent on the next message.

Kill session #

Kill session in the conversation's ⋯ menu, or in the menu of its row in the list, stops the worker and the processes it started. Use it when a conversation is stuck, when the agent does not react to Stop, or when you want the agent to start fresh so that it picks up new tools or settings, for example after you switched on agent sessions.

A confirmation opens first:

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

Afterwards a short notice says Session killed. If no live process was found it says Session state cleared; no live worker process was found. instead. If a process survives the attempt, an alert says Failed to kill session and nothing is cleared.

A turn that was running ends with a note in the conversation: This session was killed from the relay UI before the turn completed. Send the message again, or write a new one. The conversation, its history and its queued messages stay. The next message starts a new worker, and the provider session is resumed.

Archiving a conversation also stops its worker. See The conversation list.

When the agent is not reachable #

When no worker has reported in for 10 seconds, a banner appears above the conversation and the status line in the sidebar reads CLI offline:

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

The banner belongs to the relay, not to one conversation, and it can be normal on a relay that has been idle. Messages you send are kept. Send one: the relay starts the conversation's worker and the banner clears once it connects. If it stays, look at worker-<session>.log in the relay's log folder; see Files and folders for where that is.

A worker that lost its connection, for example during a relay restart, keeps trying to reconnect, waiting up to 8 seconds between attempts. Added in 0.9.13 It also gives up a connect that has not completed within 15 seconds, and does not wait for a relay that is shutting down to close the link, so a restart that hangs no longer leaves it without a next attempt. Each failed attempt writes a worker ws disconnected line with the reason to its worker-<session>.log: the first three, then at most one a minute. Added in 0.9.11 As a safety net, the relay replaces a worker that has had no connection for 60 seconds while a message waits for it: it stops the old process and starts a new one, which takes the message. It never does so while a turn or background work of that session runs, and it logs a WORKER DETACHED line when it does.

Restarting the relay #

Restart the relay to load a new version, a changed config file or a newly installed provider CLI. Choose 🌄 Restart web relay in the conversation's ⋯ menu, or run oar restart on the relay machine. oar update and the Update button in Settings → General restart it for you after an install.

What the restart would wait for Added in 0.9.13 #

🌄 Restart web relay first shows what a restart would wait for and what it would leave running:

• the sessions with a running turn, each with its title;
• how many messages it would hold until then;
• the sessions with background tasks (commands, monitors, sub-agents), each marked as keeping running or as may stop. A task the relay kept from an earlier restart, whose worker has not confirmed it yet, is listed as not yet confirmed.

When a turn runs, the window offers 🌄 Restart when idle, which queues the restart, and Restart now, which does not wait. When nothing runs, the button is 🌄 Restart web relay and the relay restarts at once.

The restart waits for running turns #

The restart does not interrupt a turn. Restart when idle queues it, and every page on every connected device shows a banner:

🌄 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.

The session names are links that open the conversation. A line Background tasks: follows when sessions have background work, with whether each keeps running. The banner has two buttons:

• Restart now asks first, names the sessions it does not wait for, and then restarts. Their workers keep running and report back to the restarted relay; the live output of their turns pauses while the relay is away, and a turn whose reply does not arrive has to be sent again. Under the Linux service the workers may stop with the relay, and the window says so.
• Cancel restart withdraws the restart. The held messages go out at once.

Only running turns hold the restart. While it is queued, messages you send wait in the queue and are not handed to an agent, so a busy relay cannot postpone the restart again and again. They run after the restart. A turn whose agent has gone silent is given up after the relay's inactivity window, 10 minutes by default (processingTimeoutMs), and then no longer holds it.

When the wait is long Added in 0.9.13 #

A queued restart waits at most Ask after a queued relay restart has waited in Settings → General: 30 minutes by default; 5, 10, 15 or 30 minutes, 1, 2 or 4 hours, or No limit. Then the banner turns into a question:

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

It offers Restart now, Keep waiting (30 min) and Cancel restart. Keep waiting waits another full period, counted from then, and asks again. Devices with notifications on also get one, titled Relay restart waiting.

The relay never restarts by itself while turns run, question or not, and it still restarts as soon as the last one ends. With No limit a queued restart, and the messages it holds, wait until the running turns end or you decide. A changed setting applies to a restart that is already queued.

When nothing is running, the banner reads Relay restarting now… and the relay is back within moments. A device that is open may show a short connection drop and, until the first worker has reported in, the CLI is offline banner.

oar restart behaves the same way when the relay was started by oar start or in a terminal: it queues the restart, so the banner and the question after the maximum wait apply to it too. It waits up to a minute and then says the relay is still busy and restarts by itself when its turns finish. oar stop waits up to 30 seconds in the same way. When the relay runs as the systemd service (oar service install), oar restart and oar stop go through systemd and act at once, without waiting for turns. A turn that is running then ends, and is handled as described below.

Added in 0.9.11 Any signed-in browser can queue or cancel the restart; it needs the access token and nothing else. If the relay refuses, the page shows its reason. From a terminal on the host, oar restart always works.

Added in 0.9.13 An agent you ask to restart the relay queues the restart the same way, and is told what the restart waits for, which messages it holds and which background tasks keep running, so it can tell you. Agents are told never to skip the wait: restarting without it is Restart now, and that is your decision.

What a restart keeps and what it loses #

Kept:

• Conversations and their history
• Queued messages, including those that waited for the restart
• Composer drafts and attachments
• Added in 0.9.11 Previews, checked again at the start
• Added in 0.9.11 The background tasks of workers that keep running
• Added in 0.9.13 The task consoles: finished rows for the rest of their hour, and the output of running commands
• Subscriptions that agents set up to watch other sessions
• The approval an agent got to start sessions
• A usage limit pause
• The provider sessions of the conversations

Lost:

• A queued Suspend host (Windows), which the relay drops and says so
• Background tasks of workers that the restart stopped (under the Linux service, see below)

When the relay was started by oar start or in a terminal, it does not stop the workers when it exits. They notice the link has gone and connect again to the new relay. The service of oar service install is different: systemd stops everything the service started, workers included, because the service asks for nothing else. The next message to each conversation then starts a new worker, and the conversation continues as described below.

A turn that was running when things went down #

A planned restart waits for turns, so this concerns Restart now, a crash, a kill, a power loss or a reboot.

The relay marks a turn as running until its worker reports. If the worker stops reporting, the relay waits for its inactivity window (10 minutes by default, processingTimeoutMs; 45 seconds at most when no worker is connected at all) and then puts the message back in the queue. The message is delivered again to a new worker, which resumes the provider session, so the agent has its earlier conversation. Files the agent already changed stay changed.

• A message is put back at most maxRequeueRetries times (default 5). Then it fails with Relay recovery limit reached … Send it again to retry.
• A turn that the agent started itself after a background task, a continuation, is not put back. It is dropped, because running it again would hand the agent its own notification as if it were your prompt.
• Copilot on the SDK engine keeps a finished reply that the relay could not take while it restarted, and offers it again for up to five minutes, so the answer is not lost and the prompt does not run twice.

A worker that kept running through the restart keeps its turn: it reports back to the new relay and the turn goes on.

Telling an interrupted session to carry on Added in 0.9.13 #

A few turns cannot run again, because the agent had already taken the message: a message you sent while it was working, a continuation, or a turn that had already started when its worker came back without it. Such a turn just stops, and the agent never hears that it was cut off.

Switch on After a relay restart, tell interrupted sessions to carry on in Settings → General (off by default, a setting of the relay) and such a session gets one note from the relay once it is back. It shows as a compact relay row in the conversation, and the agent reads:

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.

• Your message is never sent again, and a session gets at most one note per restart.
• Nothing is sent to idle sessions, for turns that run again by themselves, to archived conversations, or while a usage limit pause holds the session (its own follow-up carries the turn on).
• A message you queued meanwhile goes first; the note waits behind it.
• The note starts the session's agent like any message. Turns cut off within 30 minutes of the relay's start count.

Without the setting, send a short message such as "carry on" yourself.

By provider #

The conversation and queue are kept by the relay for every provider. What the provider keeps, and so what a resumed conversation continues from, differs. OpenAI Image conversations have no worker: the relay calls the Images API itself, so nothing on this page applies to them.