v0.9.163

Patch Changes

• #940 e52f624 A dead engine's exit.tail no longer ships raw terminal control bytes to API consumers. terminalRows — the one stripper behind get-task/collect/inspect and read-output — covered CSI and OSC escapes but not bare C0 (a shell's BEL, a spinner's backspace) or the ESC ( B charset select every full redraw emits, so all three reached pty-exits.json and every reader of it verbatim. Records already on disk are stripped on read, not just on write.

  .running and send now share one judgement about which tabs hold an engine. .running read the persisted kind label alone, so a live session the tab snapshot had lost — the unregistered rows get-task already renders — made a task report running: false while send delivered into it happily.

  Internal: the daemon stops guessing at values kobe owns. runAutoTitlePass / trackedWorktrees take the default vendor as a required argument instead of a dead "claude" literal that would not have followed DEFAULT_TASK_VENDOR, and the ui-prefs channel reports theme: null when state.json names no selection rather than naming a theme the daemon has no registry to validate. A duplicated UTF-8 chunk decoder in pr-status-collector.ts now calls its same-package twin, and the event-channel payload types moved out of the channel registry into channels-events.ts. — @Sma1lboy

• #934 fe2be33 Rove can now reload itself after an update — the amber DAEMON OUT OF DATE banner is an action instead of a chore list. Rove ships several times a day and the daemon is a long-lived process that outlives an npm i -g, so "new binary, stale daemon" is the ordinary result of updating; until now the only cure was quitting, running rove daemon restart, and starting Rove again by hand, because a running TUI keeps executing the bundle it launched with. Press ctrl+a r on the banner (proposed chord, awaiting sign-off) and Rove restarts the daemon and relaunches itself on the installed build after one confirmation. Running engine sessions are untouched — they live in the separate PTY host — and open tabs reattach to the same sessions. The chord is bound only while the two builds actually differ, so it never appears (or shows up in the command guide) on a Rove that is already current, and there is no auto-refresh: Rove offers, you decide.

  Settings → Dev → Restart backend now actually restarts. It used to destroy the renderer and exit, leaving you at a shell prompt to type rove again — which never reloaded the client's own code, the half the dev loop it exists for needs reloaded. It now stops the daemon and relaunches this window on the installed build, so an edit to daemon / orchestrator / engine code takes effect in one step.

  rove daemon restart tells attached windows why it is stopping. The daemon's daemon.stopping frame carries a reason (restart / stop / idle / socket-lost) and its own build version (protocol v5, additive — older daemons and older clients keep working unchanged). An attached Rove learns its code is about to be a build behind while the outgoing daemon is still on the wire, instead of inferring it from a socket close plus a reconnect under backoff. Plugins reading daemon.stopping can branch on the same field; see docs/PLUGIN-SDK.md. — @Sma1lboy

• #939 396be3c Windows sees its running engines again. Every task reported running: false, and every engine tab engineAlive: false with liveVendor: null, while Claude Code sat at the prompt inside it — so rove api send --tab tab-N refused with ENGINE_NOT_RUNNING ("it is a plain shell right now"), add fell into the pending-init branch instead of confirming a launch, and the sidebar showed live tasks as stopped. Two things were wrong, both Windows-only. The process snapshot ran ps -A, and the ps on a Git for Windows PATH is a Cygwin build that rejects -A and exits with empty output — which parsed to zero processes and was published as a confident "no engine anywhere"; Windows now reads Get-CimInstance Win32_Process instead. And an npm-installed engine launches through a .cmd shim whose cmd.exe exits immediately, leaving the engine's parent chain pointing at a dead pid, so no walk from the tab's shell could ever reach it — Rove now asks the tab's own ConPTY console which processes are on it (through the conpty_console_list addon node-pty already ships) and rebuilds the chain from that. macOS and Linux take and read the snapshot exactly as before.

  A process probe that fails now travels as unknown everywhere instead of as "no engine": a snapshot with no processes in it is a failed look, not an empty machine. Readers (collect, get-task, inspect, the sidebar) leave engineAlive/liveVendor unset and hold the last known running rather than reporting a live task as stopped, and rove api send refuses with ENGINE_PROBE_FAILED — which says "could not check", not "this tab is a bare shell". — @Sma1lboy