v2.2.5

Fixes from a week of running the fleet: two timing bugs that made a healthy device look slow or silent, a false clock alarm on sleeping laptops, and a small console convenience. Every component is 2.2.5.0; there is no schema change. This release also covers 2.2.3 and 2.2.4, which ran on the maintainer's fleet but were never tagged.

Highlights

• Tunnels no longer wait out ssh's ConnectTimeout. The OpenSSH 8.1 client that Windows 10 (and Server 2016/2019) ships sleeps through the whole ConnectTimeout before it notices the connection is up, so every tunnel from such a device took 8 seconds to come up on a 1 ms link (measured: 8.0 s with the option, immediate without). The device's reverse tunnel and the operator's local forward no longer set it; the agent's own deadlines bound a dead port.
• A device that answers fast is no longer "not answering". The server bound the requester to the command only after delivery, so an agent that answered before that bookkeeping finished had its answer overwritten: the console polled into "the device did not answer" while the tunnel was open, and the audit row said "?". The answer is now kept, and the audit names the real operator and device.
• A tunnel start is safe from the idle watchdog, which used to close a tunnel that was only just coming up (No process is associated with this object), and the agent logs where a slow start spends its time: launch, resolve, connect, authentication. The console's status line shows how long the device took to answer and how long the tunnel plus VNC took after that.
• A sleeping laptop is not a clock error. A report that a dozing laptop delivered late looked exactly like a clock that is behind, and the device stayed marked Error until it woke again. The server now reads the clock from the freshest of a device's recent reports and needs two agreeing ones before it calls a clock slow.
• Click a telemetry value to copy it. Hostname, addresses, make and model, serial number, device id: click the value, it is on the clipboard. The panel refreshes in place, and the public IP and its reverse name are separate rows.

Upgrading

1. Server: upload RemoteServer-linux-x64.tar.gz in Server settings → Server update, then Update server. No SQL.
2. Agent: roll it out. The idle-watchdog fix matters on every device; the ConnectTimeout fix on devices and operator PCs running Windows 10 or Server 2016/2019, where each tunnel used to take 8 seconds to come up.
3. Console: needed for click-to-copy and the connect timing in the status line. Updater, Lite and the Linux console carry the aligned version; the Linux console also gets the separate public IP / reverse name rows.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows, self-contained, signed with the maintainer's Open Source Developer code-signing certificate and timestamped.
• RemoteServer-linux-x64.tar.gz — the server package for the console's Server update tab.
• remoteclient_2.2.5_amd64.deb — the Linux operator console.

v2.2.2

Hardening that came out of a real fleet move: a server restored onto a new box, and a batch of new devices enrolling over poor mobile links. Every component is 2.2.2.0; there is no schema change. This release also covers 2.2.1, which was merged but never tagged.

Highlights

• MSIs keep one ProductCode. Every generated MSI used to get a fresh ProductCode, so Intune, GPO or SCCM saw each rebuilt MSI as a different product and pushed it onto machines that already ran the agent, where the shared UpgradeCode turned it into an uninstall and a re-enrollment. The code is now constant (Server:MsiProductCode overrides it); only the PackageCode changes per build.
• No silently smaller MSIs. After a restore the package rows exist but the files may not, because the package directory is not in the backup. A missing agent, updater, client or TightVNC file now refuses the build and names the file, instead of producing an MSI without TightVNC.
• Package files in the snapshot. Diagnostics lists current packages whose file is missing, the server logs them at startup, and restore.sh ends with the reminder.
• VNC provisions itself when TightVNC arrives. First-time provisioning only ran at agent start, so a device that got TightVNC through a later rollout had no VNC password until its service was restarted. The watchdog now does it within 30 seconds, backing off on real failures.
• racctl: diag and status print the server's JSON verbatim, get works from Git Bash, devices shows the TightVNC version and the last hour's reconnects.

Upgrading

1. Server: upload RemoteServer-linux-x64.tar.gz in Server settings → Server update, then Update server. No SQL. Afterwards take a Diagnostics → Snapshot and check that packages lists nothing as missing, especially on a server that was restored from a backup.
2. Agent: roll it out to get the VNC self-heal. Console: needed for the new MSI messages. Updater, Lite and the Linux console carry the aligned version only.
3. MSIs: rebuild them after the server update so they carry the fixed ProductCode, and re-point deployment-tool detection rules at it once. In Intune set Ignore app version to Yes: the agent updates itself through the release channels, so its version moves on without the MSI.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows, self-contained, signed with the maintainer's Open Source Developer code-signing certificate and timestamped.
• RemoteServer-linux-x64.tar.gz — the server package for the console's Server update tab.
• remoteclient_2.2.2_amd64.deb — the Linux operator console.

v2.2.0

A release about seeing and running the server without a shell on the box. Every component is 2.2.0.0.

Highlights

• The server's own log, readable from the console. A daily-rolling log file under /var/lib/remoteserver/logs (14 days, configurable), served over the admin session: Server settings → Diagnostics shows the newest records with level, time-window and text filters, with Copy and Save as. No root needed on the box.
• A health snapshot. Version, uptime, memory and load, disks, database latency and table sizes, fleet counts, the log's state, public DNS versus the box's own addresses, the certificate the public 443 serves and its expiry, and the self-update state.
• Access tokens for tooling. An admin mints tokens for their own account; shown once, only the hash stored, attributed to the admin in the audit log. Read-only by default (never a secret); a second scope adds exactly the server self-update routes. Accepted only through the device tunnel.
• racctl. A command-line client (src/RemoteClient.Cli, build it where you use it): logs, diag, status, devices, events, audit, get, and with an update token update, apply, rollback.
• A server stop takes a second, not thirty. Agents get a close frame on stopping instead of holding the host until its shutdown timeout. Measured with 11 connected agents: a self-update went from 37 s to 8 s, and every agent was back within two seconds of the new server listening.

Upgrading

1. Server: in the console's Server settings → Server update upload RemoteServer-linux-x64.tar.gz, then upgrade-2.2.0-api-tokens.sql (the tar first: uploading a tar clears a previously staged SQL), then Update server. The SQL is idempotent and safe to apply again. On a server installed with setup.sh the log directory is created automatically; otherwise make /var/lib/remoteserver/logs writable by the service user, or set Server:LogDir.
2. Console: 2.2.0 is needed for the Diagnostics tab and token management. Older consoles keep working.
3. Agent, updater, Lite, Linux console: no functional change; the version is aligned. Roll out at your own pace.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows, self-contained, signed with the maintainer's Open Source Developer code-signing certificate and timestamped.
• RemoteServer-linux-x64.tar.gz — the server package for the console's Server update tab.
• upgrade-2.2.0-api-tokens.sql — schema upgrade for this release.
• remoteclient_2.2.0_amd64.deb — the Linux operator console.

v2.1.8

RemoteAppClient 2.1.8 — signed releases

A release about how RemoteAppClient itself is built and shipped. The Windows executables attached below are code-signed, a server installed with setup.sh identifies its devices again, and one script covers every build. There is no database schema change.

Component versions are not aligned. Server and Windows console: 2.1.7.0. Agent, updater, Lite and the Linux console: 2.1.6.0.

Signed releases

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe and RemoteClient.Lite.exe are signed with an Open Source Developer code-signing certificate and timestamped, so the signature stays valid after the certificate expires. Windows can now verify who published them: Smart App Control accepts a valid signature, and SmartScreen reputation builds up on the certificate instead of starting from zero with every new file.
• The signing key lives in the cloud and needs the maintainer present, so CI keeps building unsigned. build.ps1 -Tag rebuilds the tagged commit, signs it and swaps the assets — which is how these got here.

A fresh server that tells its devices apart

• The server identifies a device by its client certificate, whose name nginx forwards as X-Client-Dn. deploy/steps/07-nginx.sh set that header for the command channel but not for /api/, so a server installed with setup.sh filed the telemetry of every device under a single device called unknown, answered VNC password reports with 401, and showed every real machine as reporting only.
• Hand-built configurations were not affected. It surfaced when a server was restored onto a new machine.

One build script for every job

• .\build.ps1 without parameters now explains itself. -Fleet builds agent, updater and console signed with the fleet certificate (-Deploy replaces this machine's installation), -Tag makes the signed release build, -Msi signs the MSI the server generated, -ServerOnly builds the server package, -Unsigned is for development.
• The server package can be built on Windows: RemoteServer-linux-x64.tar.gz, ready for the console's Server update tab, packed with explicit Unix file modes — only the apphost and createdump are executable — because a mode guessed by a Windows tool only fails once it reaches the Linux box.
• Signing scripts and folders are machine-specific and live in build.local.psd1 next to the script, which git ignores. The public script carries no accounts, certificates or paths.
• A build no longer stops this machine's agent services unless it is really about to overwrite them (-Deploy).

Also

• The server logs executed SQL at Debug instead of Information; the journal had become mostly SQL text.

Upgrading

No schema change, no SQL. The server update is optional — it only quiets the log.

If your server was installed with setup.sh, fix its nginx site configuration even if you do not update anything else:

F=/etc/nginx/sites-available/<your-domain>
awk '/location \/api\/ \{/,/^[[:space:]]*\}[[:space:]]*$/' "$F" | grep -q 'X-Client-Dn' || sudo sed -i '/location \/api\/ {/,/^[[:space:]]*}[[:space:]]*$/ s|^\([[:space:]]*\)proxy_set_header X-Client-Verify \$ssl_client_verify;|&\n\1proxy_set_header X-Client-Dn $ssl_client_s_dn;|' "$F"
sudo nginx -t && sudo systemctl reload nginx

Devices sort themselves out within a minute. Then delete the device whose Telemetry tab shows deviceId unknown — it only ever collected other machines' data.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows x64, self-contained single-file, signed
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_2.1.6_amd64.deb — Linux operator console

v2.1.7

RemoteAppClient 2.1.7 — bulk note import

Two things a fleet needs before it grows: a way to attach notes to hundreds of machines at once, so a live record can be told from a stale one — and a status badge that stops calling a switched-off machine flaky. There is no database schema change.

Component versions are not aligned in this release. The Windows console is 2.1.7.0; the server, agent, updater, Lite console and Linux console are 2.1.6.0. The agent and updater have no code changes.

Notes for hundreds of devices at once

• Import notes (admin-only, the new button next to Refresh): open or paste a hostname;note list — a CSV saved from Excel, or two columns copied straight out of it — and see line by line what would happen before anything is written: New, Overwrite, Not found, Invalid line, Repeated, Empty note, Unchanged.
• It writes only to devices already enrolled. An unknown name is reported and skipped, never created, so the same list can be run again as more machines arrive — and Copy unknown names puts exactly the missing ones on the clipboard.
• A name shared by several devices goes to the one seen most recently. The others are usually stale re-enrollments, and leaving them without a note is precisely what makes them easy to find and delete.
• Nothing is lost by accident: a blank note never clears one, and overwriting an existing note stays off until you switch it on. The preview shows the current note next to the new one, and Save asks once more with the counts.
• Excel is taken as it comes: the Windows code page its plain CSV is written in, UTF-8 with or without a BOM, UTF-16 Unicode text, quoted cells, the trailing empty columns of a sheet that once had more, a header row, fully qualified names. The detected encoding is shown, so a garbled accent comes with an explanation.
• The console sends device IDs, not names, so the server writes exactly the rows you approved instead of repeating a lookup that could land elsewhere. Every changed note is committed together with its own audit entry (Note imported, filterable in the log); the note text itself stays out of the log, since notes are stored encrypted.

Offline means offline

• A machine switched off at the end of the day could still show as flaky half an hour later. Flaky means three or more reconnects within the last hour, and it was checked before offline — so a device that reconnected a few times on its way out kept the badge for the whole hour.
• Now a device that has stopped reporting is offline, whatever its link did before; flaky is kept for a machine that is still sending data over a bad connection. The server, which writes the device history, and the consoles decide it the same way, and the status column sorts by liveness instead of by the online flag alone.

Also

• Single-column lists — audit log, users, groups, device history — no longer grow a stray horizontal scrollbar that hid the last row once the rows overflowed.
• build.ps1 -SignScript <script> signs every exe before it is hashed or deployed. Agents verify an update's hash, so signing afterwards would make every agent refuse the update. Accounts and certificates stay in your own script, out of the repository, and a failed signature counts as a failed build.

Upgrading

No schema change, no SQL to run. Update the server first if you want the import: against an older server the console says so plainly instead of failing with an HTTP error. The wire contract is additive, so older consoles keep working with the new server, and nothing here needs an agent update.

Artifacts

• RemoteClient.exe (2.1.7.0), RemoteClient.Lite.exe, RemoteAgent.exe, RemoteAgent.Updater.exe — Windows x64, self-contained single-file
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_2.1.6_amd64.deb — Linux operator console

v2.1.5

RemoteAppClient 2.1.5 — minor fixes

A device could be online, green and reporting every minute while silently discarding every command sent to it — and nothing, anywhere, said so. That is exactly what a live machine did: its clock ran 88 seconds fast, the agent correctly refused every command as a replay, the console showed a healthy device, and the server logged each command as delivered. It cost an afternoon to find. This release makes the fleet admit it in under a minute, and then repair itself. All components are 2.1.5.0.

Database schema change. Two nullable columns are added to Devices. Apply the idempotent upgrade-2.1.5-device-problem.sql (see Upgrading); a fresh install gets them from schema.sql.

A device that admits what is broken

• A new error state, with the reason. Devices carry a Problem, and the console shows a red badge and the concrete fault instead of a reassuring green one. The first fault it knows is clock skew, because that is what bit us: an agent refuses any command whose timestamp is more than 60s from its own clock, so a machine running 88 seconds fast is completely unreachable while looking perfectly healthy.
• The server detects it on its own, with no agent update at all. It compares the telemetry's own CollectedAtUtc against arrival. Telemetry is not signed, so it still arrives from a device whose every command is being thrown away — which makes it the only channel that can report this fault. The threshold is 30s, half the command window: it warns while there is still time to act. Verified in production against a machine running the previous agent.
• The problem is stored as a language-neutral code and rendered by each console in its own language. An unrecognised code is shown raw rather than hidden, so an older console cannot swallow a fault whose name it has not learnt yet. Transitions land in the device history like any other state change.

An agent that fixes its own clock

• Time sync runs at startup, periodically, and — the part that matters — whenever the skew is demonstrated. Two independent signals trigger it: a command carrying a valid server signature but an out-of-window timestamp (proof the fault is ours, not a forgery), and the Date header on every telemetry response, which catches it within one 60-second cycle without any command needing to arrive.
• Neither signal is ever trusted as a time source; both only prompt the agent to consult a real one. A domain-joined machine is left alone — its time comes from the domain hierarchy, and overriding that fights the DC — and an existing NTP configuration is never overwritten; only a machine with no source at all is given one.
• The correction is measured and logged ("the clock was stepped by −180s"). A system that quietly moves a machine's clock by three minutes should leave a record that it did.

Fewer confident wrong answers

• The console no longer puts up "waiting for the user at the device to approve" when nobody was asked. It could not tell before: it sees only the device's own tri-state consent setting, while the effective value comes from group inheritance — so the server now returns it. When consent really was requested the wait is unchanged; when it was not, a silent device is reported as a silent device.
• Show VNC password (admin-only, right-click). The console hands the secret straight to the viewer and never displays it, so reading one previously meant decrypting the database by hand. Every read is written to the audit log — that record is the point, which is why it re-fetches rather than using the copy already in the device list.
• "nem vezérelhető" is now "csak jelent", which fits the badge.
• build.ps1 -Deploy replaces a live installation in one step: stops the services, kills the console, swaps the binaries while everything is down, verifies each copy by hash, and only then restarts. The script is now in English.

Upgrading

Server first, with upgrade-2.1.5-device-problem.sql (attached below, also in src/RemoteServer/Data/Migrations/) — through the in-app Server update → choose SQL upload, or manually. It is idempotent (ADD COLUMN IF NOT EXISTS), so running it twice is harmless.

The wire contract is additive, so nothing breaks in either direction. Most importantly, the fault reporting works across the whole fleet without updating a single agent — that is the point of deriving it from unsigned telemetry. The 2.1.5 agent adds the prevention (self time sync) on top; roll it out at your own pace.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows x64, self-contained single-file
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_2.1.5_amd64.deb — Linux operator console
• upgrade-2.1.5-device-problem.sql — the schema upgrade, idempotent

v2.1.0

RemoteAppClient 2.1.0

An honesty release. The console stops asserting things it cannot know: Online now means a device is genuinely reachable, a machine that only looks dead gets labelled instead of buried, and — for the first time — you can ask a device where it has been. All components are 2.1.0.0.

Database schema change. The per-minute telemetry snapshot is replaced by an event log. Apply the idempotent upgrade-2.1.0-device-events.sql (see Upgrading); a fresh install gets the table from schema.sql.

Online that means online

• The badge could stay lit for hours after a machine fell off the network. The server's WebSocket had a keepalive interval but no timeout, so a socket whose peer had vanished was never torn down — the connection registry kept the dead handle and reported it as connected. One device sat "Online" with a four-hour-old last report while six commands were "delivered" into that dead socket. Sockets now time out (KeepAliveTimeout), and the badge cross-checks the last report, so a lingering handle cannot outlive the truth.
• Because of that, starting a session against an unreachable device raised a consent prompt nobody could answer. Commands now report whether they actually reached the device, and say so plainly when they did not.
• New state "nem vezérelhető" — telemetry is arriving but the command channel is not up. This used to render as plain offline, which is why a demonstrably alive machine could show up as dead. Liveness is defined in exactly one place now, so the badge, the filters and the history cannot drift apart.
• Both consoles now answer the same question the same way. The state decision moved into shared code, so the Windows list badge, the Windows detail panel and the Linux console can no longer disagree about one device — and they did: the detail panel still said offline while the badge beside it said nem vezérelhető, and the Linux console, which knew only online/offline, said offline for both. Failing to connect now names the actual state instead of asserting the machine is offline. (The telemetry panel's second Állapot row is renamed Jóváhagyás — it is the approval state, not liveness.)
• The agent's command loop can no longer die quietly. An unhandled exception ended the background service for good: the device kept sending telemetry — so it looked perfectly healthy — but never accepted another command until someone restarted the service by hand. The loop now catches itself and retries every 60 s.

A fleet with a past

• A new Előzmények tab (also on the right-click menu): when a device changed state (online / ingadozó / nem vezérelhető / offline), and when its IP moved. The reverse DNS is resolved and stored at write time — once a device has moved on, nothing can recover the name a past address used to have.
• The old DeviceTelemetry table wrote every device's full payload once a minute. It reached 755 MB across fifteen devices in three months, and no endpoint and no client had ever read a single row of it — every current value already lives denormalised on the device row. It is replaced by DeviceEvents, which records only transitions and is pruned at 90 days; a device that stays put and stays online now writes nothing at all. The database went from 811 MB to 4 MB.
• Deleting a device no longer times out. One machine had accumulated 63,574 snapshot rows — enough to push the cascade past the request limit. The event log removes the cause, and the delete clears it too.

Smaller things

• Hozzáférési napló: the log tab and its context-menu entry now say what they actually show.
• The public IP is shown with its reverse DNS beside it, in the list and in the history.
• Console broker reconnects are serialized, and a port forward always resolves the current broker rather than one disposed mid-reconnect.
• The Linux operator console is fully localized — its device list, status messages and settings panel used to stay English while the rest of the UI switched language; nearly all of it reused keys the Windows client already had. Two long-standing slips came out with it: an uptime under an hour printed a hardcoded Hungarian word on the English UI, and the link-quality row the Windows panel shows was missing entirely.
• Dependency bumps (NuGet + GitHub Actions); the Avalonia family is aligned at 12.1.2 across the Linux console.

Upgrading

Server first. Apply src/RemoteServer/Data/Migrations/upgrade-2.1.0-device-events.sql — through the in-app Server update → choose SQL upload, or manually against the database — then deploy the server. It is idempotent, and it drops the old DeviceTelemetry table, which is where the reclaimed space comes from.

The wire contract is additive, so nothing breaks in either direction: a 2.0.x agent talks to a 2.1.0 server unchanged (there is no agent protocol change), and a 2.0.x console ignores the new field. A 2.1.0 console against a 2.0.x server is the one degraded combination — the Előzmények tab has no endpoint to call, and no device is ever shown as nem vezérelhető — so upgrade the server before the consoles.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows x64, self-contained single-file
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_2.1.0_amd64.deb — Linux operator console

v2.0.0

RemoteAppClient 2.0.0

A survivability release. The fleet now rides out the things that used to need a human — a network blip, a lost report, an expired session — and, for the first time, an OS swap under the server. All components are 2.0.0.0.

No database schema change since 1.9.0 — nothing to migrate.

Surviving the server's own OS

• deploy/backup.sh + deploy/restore.sh capture and re-adopt the fleet's identity: the CA that issued every client certificate, the command-signing key, the bastion SSH host key each agent pins, and the database. Devices are never "imported" — their identity lives on the device. Restore these and an OS swap is invisible to all of them; miss the SSH host key and every tunnel breaks.
• The order is the trick: 04-server only generates secrets that are missing and rebuilds bastion.env from whichever host key is present, so restoring first makes the installer adopt the fleet instead of locking it out.
• The same backup from the console (Server settings → Backup). A root helper does the privileged part — the server cannot read the host key — and the archive is always passphrase-encrypted: it leaves the box through an 8-hour admin session, and the keys inside cannot be revoked. The server keeps no copy of the passphrase and drops the archive as it hands it over.

VNC that comes back on its own

• A network blip no longer kills VNC for ~6 minutes. The bastion released a dropped session's reverse-forward port only after a 120s × 3 keepalive, while the agent gave the link up in 45s — so a returning agent could not rebind its own (deterministic) port and ExitOnForwardFailure killed the fresh tunnel. Now the bastion mirrors the agent (15 × 3), the agent retries across the window, and the console waits for the RFB greeting instead of launching a viewer at a tunnel that isn't there.
• The VNC-secret report retries until the server confirms receipt. A lost one-shot report used to leave a device with TightVNC running but no server-side password until someone restarted the agent — the failure mode of fresh installs on mobile / CG-NAT links.

Fewer dead ends

• Restart RACD (Devices → Commands): restarts VNC → Helper → agent, in that order, and verifies the Helper is alive before the agent goes down — it is the only thing that can revive a stopped agent. Windows is not rebooted.
• An expired session says so and returns to sign-in, instead of surfacing a raw 401.
• Dependency bumps (NuGet + GitHub Actions, Avalonia 12.1) and a warning-free Linux console build.

Upgrading

Server and agents are backward compatible; there is no schema change. The bastion keepalive lives in deploy/steps/05-bastion.sh — a box built before 2.0.0 should get ClientAliveInterval 15 / ClientAliveCountMax 3, or re-run ./deploy/setup.sh 05-bastion 12-backup.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows x64, self-contained single-file
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_2.0.0_amd64.deb — Linux operator console

v1.9.0

RemoteAppClient 1.9.0

A client redesign and power-telemetry release. All components are 1.9.0.0.

Schema change — first since 1.8.0. Four nullable power columns are added to Devices. Prod applies the idempotent upgrade-1.8.9-power.sql (ADD COLUMN IF NOT EXISTS) through the in-app server update; fresh installs get the columns from schema.sql. The script is attached to this release for hand-upgrades from 1.8.5.

Operator console redesign

• Token-based visual overhaul of the Windows client: compact, Hungarian-localized sidebar, tighter device stat cards, an icon-only refresh on the Devices page, and a polished deep-dark login screen.
• Bundled IBM Plex UI fonts (OFL), embedded in the single-file exe — no system install needed.
• Dark, click-to-sort list headers throughout: the Devices list and the Channels/MSI device list sort on any column (version-aware); the old white native ListView header is gone in dark mode.
• The Devices page auto-refreshes every 10 s, so "last seen" and online state stay live.

Power telemetry (battery & sleep)

• The agent reports battery charge %, charger (AC) state, and the configured sleep timeout on mains and on battery. Charger state is event-driven (a GUID_ACDC_POWER_SOURCE notification), so plug/unplug shows on the next telemetry beat instead of a stale Session-0 poll.
• Opening a VNC session to a machine that may drop off raises a sleep warning — on battery, or on mains with sleep still enabled — with the idle-to-sleep time. New Akku/táp and Alvó mód telemetry rows.

Quality of life

• Device notes accept multi-line input (Enter inserts a newline); one-line list/header previews collapse newlines to spaces so wrapped notes no longer smear together.
• Dependency bumps (NuGet + GitHub Actions) via Dependabot.

Compatibility

The new power columns are nullable and the telemetry fields are additive: a 1.9.0 server stays compatible with older agents (they report no power data) and the 1.9.0 client renders older devices with the power rows blank. No forced agent rollout required.

Artifacts

• RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe — Windows x64, self-contained single-file
• RemoteServer-linux-x64.tar.gz — server
• remoteclient_*.deb — Linux operator console
• upgrade-1.8.9-power.sql — idempotent DB upgrade from 1.8.5

v1.8.5 — pipe heartbeat & flaky-link detection

Fleet reliability + observability release. All components → 1.8.5.0. No database schema change since 1.8.0.

Named-pipe agent heartbeat

• The Helper (updater) reads agent liveness over the agent's read-only status pipe (RemoteAgent.status → LastHeartbeatUtc) instead of a heartbeat file — fixes a file-race that could report a bogus ~9.2e11-second "stale heartbeat" and force a needless agent restart.
• A two-poll confirmation keeps a single transient blip from restarting a healthy agent. The legacy heartbeat file is still written for an older, file-based Helper during a rolling update and self-retires once the co-located Helper is the new pipe-aware build.

Flaky-link detection (observability only)

• The device list now tells "alive but on a poor network" (frequent C2 reconnects → amber ◐ flaky) apart from "offline / dead" (○ offline), with the reconnect count in the tooltip and a Link row in the telemetry panel.
• Computed server-side from in-memory C2 connection churn (last hour). Pure observability — never triggers a restart. Backward/forward compatible (older clients ignore the new field; an older server leaves it dormant).

Database

• No schema change in 1.8.5. The only column added since 1.7.0 is Users.KeylessOperator (1.8.0). The attached upgrade.sql applies it idempotently (ADD COLUMN IF NOT EXISTS) when upgrading a 1.7.x database — a no-op where it already exists. Fresh installs get it from schema.sql.

Assets

• Windows (self-contained, single-file): RemoteAgent.exe, RemoteAgent.Updater.exe, RemoteClient.exe, RemoteClient.Lite.exe
• Linux: RemoteServer-linux-x64.tar.gz, remoteclient_1.8.5_amd64.deb
• upgrade.sql — optional, idempotent DB upgrade