changelog

All notable changes to owlette are documented here. The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

owlette keeps its program files and its data under one folder, C:\ProgramData\Owlette, whose permissions let any standard Windows account on the machine modify what was inside it. Two things followed from that: the agent's program files — which the service runs with full system privileges — could be replaced by an account that has none, and the encrypted file holding the machine's owlette credentials could be read by any local account rather than only the person using the machine. A machine whose only accounts are administrators was never exposed; a machine anyone else can sign in to was. Upgrade every machine — 3.3.6 corrects the permissions and keeps them corrected.

The program folders (agent, python, tools, app, scripts), the documents in the install root and the uninstaller are readable and runnable by standard users, and writable only by the system account and administrators.
The installer applies this on every install and upgrade, and the service re-checks it and repairs any drift when it starts and when someone signs in, so a machine whose permissions have been changed corrects itself without a reinstall.
The machine's credential file is limited to the system account, administrators and the signed-in user. Each save now writes a new protected file and swaps it over the store in one step instead of rewriting it in place, so there is no moment at which it sits there half-written.
A self-update downloads into a folder only the service can write, and the installer's checksum is taken from the same open file the service hands to Windows to run: the file that was verified is the file that runs.
The service confirms who created a file before it acts on it — its stop signal, the update marker, the Cortex/hoot command queue and the result a process launch reports back. A file written by an account it cannot vouch for is logged and ignored.
The recovery watchdog can be switched off only through a registry value an administrator sets, HKLM\SOFTWARE\Owlette\WatchdogDisabled. The old tmp\watchdog_disabled file has no effect.
The agent sends its credentials only to the owlette.app API hosts. Any other configured address is refused rather than used.
Permission checks identify the Windows built-in accounts by their fixed identifiers instead of their English names, so they work on a non-English Windows.
Known limitation — the person signed in at the machine can still read its credentials. Pairing runs as that user, so the credential file stays readable by the account at the console; 3.4.0 moves pairing and credential storage behind the service and ends it. Every other local account has lost the access.
Known limitation — re-pair machines that had untrusted local accounts. 3.3.6 changes who can read the credential file; it does not invalidate a copy taken before the upgrade. On any machine where an account you do not trust could sign in, re-pair the machine after upgrading so it runs on fresh credentials.
Known limitation — the upgrade onto 3.3.6 is carried out by the agent already on the machine. A self-update runs from the version installed, so this one download still uses the old, unprotected staging folder; the protected folder applies to every update from 3.3.6 onwards. Running the 3.3.6 installer yourself skips that last step.
Known limitation — the desktop app resets one file's permissions. The tray app writes tmp\app_states.json itself, and its write drops the protected permissions the service had set on it; the service restores them on its next write.
Known limitation — configure_site.py --url no longer accepts a local development server. It takes https://owlette.app/api or https://dev.owlette.app/api and nothing else, so an agent can no longer be pointed at a development API running on the machine.
Known limitation — re-pairing from a remote session. After the service's permission repair, only the account signed in at the machine's console holds write access to the credential file, so re-pairing from a Remote Desktop session run as a standard user fails. Re-pair from the console, or from an elevated prompt in the remote session; 3.4.0 removes the need.

changed — a developer grant, and a record when permissions are repaired

-DevGrant for developers who deploy into an installed agent. Run from an elevated prompt, scripts/bootstrap-windows.ps1 -DevGrant gives the developer's own account — never every user — write access to the installed agent\src and app folders, so a local deploy hook keeps working against a hardened tree. -RemoveDevGrant reverts it. An agent install resets those folders, so the grant is re-run afterwards.
A repaired machine says so. When the service finds and fixes drifted install permissions at start-up, it records an install_permissions_repaired event naming the paths it corrected, rather than only noting it in the local log.

added — swoop, the remote screen, ships switched off

The dashboard gains swoop: watch a machine's screen live and, with a second factor, take its keyboard and mouse. It is off for every site until a site admin turns it on, and it has its own release to come; nothing changes for a site that leaves it off.

added — machines report their operating system

Each machine now reports its operating system and version. The machine card shows it under the hostname, and the machine list carries it as a second line.

added — filter the logs by several actions at once

The action filter on the logs page is a searchable list of checkboxes, so you can show, say, every start and stop together, and find an action by the name you see in a row. The filters sit on one row, with the custom date range joining it instead of opening a second one.

added — pin a metric to read it on its own

Clicking a stat card under a machine's metrics chart pins it: its line stays highlighted, the other cards dim, and the readout under the cursor lists only that metric while you scrub along the line. Click the card again to unpin.

changed — machine cards are easier to read

The metrics row lines up the same metric at the same place on every card, healthy temperatures are no longer coloured so colour only marks a crossed threshold, the online pill is a dot that shares the "last seen" tooltip, and the ping cell now shows whether the network interface is up. The labels in that row start at the same left edge as the display and process rows below it, instead of floating towards the middle of their cells on a wide card.

changed — docs search returns a usable number of results

A search of the docs now returns a bounded, ranked list instead of every matching section, and the pages carry keywords for the words you type that the prose never uses.

changed — groundwork for the agent on macOS and Linux

The agent's code now runs on all three operating systems and is tested on each in every build. Nothing changes on Windows, and there is no macOS or Linux installer yet; those ship with their own release.

changed — you can no longer demote or remove yourself

A site owner or admin who tries to change or delete their own membership now gets a refusal instead of locking themselves out, whatever the platform's capability enforcement switch is set to.

changed — the capability enforcement switch no longer covers swoop

Turning capability enforcement off, the break-glass step during an authorization misfire, no longer opens swoop's viewing, control and settings capabilities: during a misfire swoop stays locked rather than open.

fixed — every line on a metrics chart has a scale you can read

Temperature lines now read off their own °C scale instead of the percent labels, and a chart showing only network or disk throughput puts its scale on the left rather than beside an empty percent column. Each side of the chart carries at most one scale, and it always belongs to what you're looking at: a pinned or hovered card shows only its own unit, and with usage, temperature and throughput on one chart the labels follow the device under the cursor, keeping a CPU's or GPU's percent and temperature on their sides. Throughput scales now step evenly, so both sides line up with the gridlines, and their labels no longer wrap onto two lines.

A machine that crashed a process and never came back carried its restart-pending banner indefinitely, and dismissing it did nothing because it only queued a command the offline machine never collected. Dismiss now clears the flag in the cloud and relays the command to the agent as a courtesy.

[3.3.5] - 2026-09-15

changed — the agent's libraries are current again

The libraries the agent uses to watch processes and read GPU state had fallen years behind: the process library was from 2023 and the NVIDIA bindings were a major version old. This release brings both current (psutil 7, nvidia-ml-py 13) together with the crypto, error-reporting and timezone libraries, and the desktop app's Windows and Tauri crates. Nothing the agent does has changed; the installer simply ships the versions their authors maintain today. Every one of these was proven with a full installer build and a check against a real GPU and process table before it was tagged.

On the web side, the Next.js framework carries two critical security patches and a set of routine library updates.

changed — one support address

Support is now support@tridant.io everywhere: the dashboard footer, the docs, the terms and privacy pages, and the security policy. The old owlette.app mailboxes are retired.

fixed — the dashboard opens where you left it

Reloading the dashboard could land on a half-loaded site list instead of the site you were viewing. It now reopens the last viewed site.

fixed — two layout glitches

Between 1024 and 1065 pixels wide the machine list scrolled sideways, and a roost row's timestamp could sit under its action menu. Both are corrected.

[3.3.4] - 2026-09-12

changed — hoot runs on a current Claude Code CLI again

hoot drives the Claude Code CLI on each machine. A single pinned dependency had quietly held that CLI 138 releases behind: the agent pinned pywin32 to a version that capped mcp, which in turn capped the Claude Agent SDK, and nothing ever failed — the installer resolved a valid set of packages and reported success. This release lifts all three together, so hoot runs on the CLI the SDK was built against.

There is no change to how hoot behaves, what it can do, or the approval tiers. Machines pick up the new CLI on their next hoot start and keep the copy they already have if it still matches.

fixed — a conversation you open shows its messages again

Opening a saved hoot conversation could render it empty — the right title, the right machines in the header, and no messages. Nothing errored; the history had been loaded into the previous conversation rather than the one on screen. Switching away and back was the only way to see it.

[3.3.3] - 2026-09-12

added — a hoot chat talks to the machines you tick, and `@machine` narrows one turn

The machine selector in the hoot header is now a checkbox picker: tick as many machines as the conversation should talk to, or leave all machines ticked, which stays dynamic — a machine added to the site later joins the target on its own. Changing the ticks continues the conversation instead of starting a new one, so a chat can follow a problem from one machine to its neighbours without losing its history; changing the site still starts a new chat. Each row says whether a machine is offline or has hoot off, the trigger shows how many of the targeted machines are online, and the selection is stored on the conversation and remembered per site across your devices — reopening an old chat restores the machines it was talking to.

Typing @ in the composer completes a machine name and narrows that turn only: the chat's own ticks are untouched and the next message goes back to them. The parser is deliberately conservative, so a pasted PowerShell @(...), an @splat, an email address or a fenced code block is never read as targeting. Mentions come from the dashboard composer — the public conversations API, the SDKs, the CLI and chat-scoped API keys get no narrowing.

A ticked machine that is offline or has hoot off is skipped: the turn runs on the rest, the model is told which machines were left out, and the header warns before you send. A machine you named with @ is refused instead of skipped, so a mention can never quietly miss. A chat whose stored target cannot be read asks you to pick machines rather than falling back to the whole site.

changed — hoot off on a machine now means off on every path

A machine with the hoot toggle switched off has always been skipped by single-machine chats. It is now skipped by every dispatch: site-wide and multi-machine chats, scheduled follow-ups, site-wide talons, and the public conversations API's site mode. This changes behaviour for sites that never touch the new picker — a machine you switched hoot off on, which a site-wide chat has been reaching anyway, now receives nothing. A talon whose site has no online machine with hoot on records the run as skipped rather than failed, so it is not auto-disabled over it, and the run records which machines it skipped.

changed — a tier-3 approval is bound to the turn that asked for it

Approving a privileged call now runs it on the machines that turn resolved to, named on the approval card, rather than on whatever the picker happens to show when you come back to the chat — ticking more machines while a card waits never widens it. If another turn has run in the conversation since the approval was requested — a follow-up firing, or a message sent from another device — the approval no longer matches the turn it belongs to and is refused with "that approval expired — another turn ran in this chat. ask again."; nothing is queued on any machine and the approval is not spent, so the request can be made again. Bound machines are re-checked when you answer, and an approval with nothing reachable left is held rather than consumed.

A follow-up fires on the machines the turn that scheduled it was targeting, re-validated when it comes due; if none of them is still in the site, it is marked failed with the reason rather than dispatched somewhere else.

fixed — the hoot power toggle, and a follow-up's tool limit

The per-machine hoot toggle in the chat header could switch hoot off but never back on: the dashboard never read the machine's stored flag, so the toggle always believed hoot was already on. It now reflects what is stored.

A follow-up scheduled by a chat-scoped API key — a caller capped to read-only tools — fired later with the chat owner's tool tier, so a turn that could only read could schedule one that could act. A follow-up now fires with the lower of the tier its scheduling turn had and the tier its owner earns at fire time. Follow-ups scheduled before this release keep the old behaviour, since their records do not carry the limit.

changed — hoot runs on Claude Sonnet 5, and can consult Claude Opus 5

Hoot now defaults to Claude Sonnet 5 for accounts that haven't picked a model, and the model picker in settings starts a new key on it; an account that already saved a model keeps it until you pick another. Sonnet 5 thinks before it answers, and "thinking..." stays up until the reply starts. On a problem it judges hard, it can consult Claude Opus 5 partway through an answer — Anthropic's advisor tool, at most twice per reply — and the chat notes each consultation. They bill at Opus rates on your own Anthropic key. Claude Haiku 4.5, Sonnet 4.6 and Opus 4.6–4.8 can consult it too; Opus 5, the Fable models, older Claude models and OpenAI models don't.

A reply that comes back empty — for instance when the model declines the request — now says so instead of leaving a blank reply.

Hoot's conversation list can be dragged wider from its right edge — 200px to 560px, double-click to reset — and both that width and whether the list is collapsed are remembered for you across sessions and devices. The list starts wider than before, and a row's rename and delete controls now sit over the end of the title instead of beside it, so a conversation's generated name has the full width of the column to be read in.

The share dialog leads with the preview: what a link includes and leaves out is folded behind a "more" link, the expiry sits with the buttons that use it, and creating a link copies it to your clipboard and says so. Every link a conversation has can be copied from its row, and those rows now carry the time each link was made, not only the date. The dialog itself no longer scrolls — the preview absorbs the space as links come and go — and it renders the conversation on the same surface, with the same avatars and rails, that the live chat does.

A tool call's inputs and outputs slide open and closed rather than snapping, at every tier, and editing a message to resend it now opens a full-width box that grows with what you type.

A hoot conversation you started can now be published as a read-only page at /share/{token}, readable by anyone holding the link without signing in. The share dialog renders that finished page before anything is created, so what you preview is exactly what a reader gets.

What goes out is a snapshot, frozen at the moment the link is created: your messages and hoot's replies as text, plus each tool call collapsed to its name and outcome. Tool inputs and outputs — hostnames, paths, log lines, command output — are never published, and messages sent afterwards never join a link that already exists. Links expire after 30 days by default, with 7 days, 90 days, and never-until-revoked also on offer; every link a conversation has is listed in the same dialog and can be revoked there, and the page is marked noindex. Autonomous conversations have no author and cannot be shared.

fixed — offline machines and status badges are readable

In the list view, an offline or restarting machine's metrics were faded to 40% opacity, which dropped its device names and readings below the 4.5:1 contrast minimum for text. They are now dimmed to 80%. The red offline, restart, and failed-process badges use white text instead of near-black, a process on an offline machine reads as grey on grey instead of dark on dark, and hoot's sidebar group headers use the full muted text color.

security — dependency updates

@simplewebauthn/server 13.3.3: passkey registration checks that attestation certificates chain to a trust anchor.
ai 6.0.280 with matching @ai-sdk/* providers: fixes uncontrolled resource consumption in @ai-sdk/provider-utils.
vitest 4.1.11 in the desktop app's test toolchain: fixes a path traversal in @vitest/mocker (development only; nothing ships in the app).

fixed — email and pairing links always point at the configured site address

Alert, digest, and API-key-expiry emails, the unsubscribe confirmation, and the agent and CLI pairing links built their URLs from the host of the request that produced them. They now use the configured site address (NEXT_PUBLIC_BASE_URL), so a request served through another hostname — such as the failover origin — still sends people to owlette.app.

fixed — a process you close by hand no longer keeps reading as running

Close a managed app yourself and switch its launch mode to off before owlette's next check, and the process kept showing as running — a green dot and a "started N seconds ago" on something that had already exited. It corrected itself eventually, up to five minutes later, and not at all if Windows had recycled the process id onto something unrelated in the meantime.

owlette wrote a status when it launched a process and when it stopped one, but never when a process exited on its own: the stale status was only ever replaced as a side effect of relaunching. Take the relaunch away — by switching the mode off, or because a scheduled process had left its window — and nothing replaced it. Switching a launch mode off now checks whether the process is still alive and settles its status immediately, and the periodic cleanup verifies process identity rather than just asking whether the id exists, so a recycled id can no longer keep a dead entry looking alive.

A process that really is running is untouched, and keeps its stop and restart controls. Switching a launch mode off has never stopped a running process and still doesn't.

[3.3.2] - 2026-09-09

fixed — a failed display enumeration is no longer reported as monitors being removed

When the agent could not read the display configuration at all, it reported that as every monitor having been disconnected: one CRITICAL alert per panel, emailed immediately, naming displays that were still plugged in. The dashboard kept showing those monitors present the whole time, because the upload path already refused the bad reading while the alert path did not.

It also remembered the empty reading, so the next successful check announced every monitor as newly added — a disconnect/reconnect flap for each failure.

The agent now treats "I could not look" as its own case: no alert, no state change, and the reading is discarded rather than remembered.

This only affects alerts caused by a failed enumeration. A check that succeeds but returns an incomplete monitor list is a separate case and still alerts; if you are seeing these, the agent log records build_display_profile: enumeration failed at the moment of each affected alert when this fix applies.

changed — the service host is rebuilt with version metadata, after Defender began quarantining it

On 2026-09-08 Windows Defender's machine-learning classifier (definition set 1.459.111.0) started quarantining owlette-host.exe — the Windows service that supervises the agent — as Trojan:Win32/Bearfoos.B!ml. It was a false positive on the file's shape, not its behaviour: a small, size-optimised, stripped, statically linked executable with no version information is also what a malware dropper looks like. When Defender opened the file it removed both the file and the OwletteService registration. The agent's Python process survived as an orphan and kept reporting the machine healthy, so the dashboard did not notice.

Every installer from 3.2.3 to 3.3.1 ships that binary. 3.3.2 rebuilds it with a proper Windows version resource (company, product, description, file version) and an ordinary release profile; current definitions scan the result clean, including under real-time protection. The static CRT link introduced in 3.2.3 is kept — it is what lets the service start on a freshly imaged machine.

If a machine on 3.2.3–3.3.1 shows OwletteService missing while the dashboard still shows it online, this is why. Install 3.3.2 over it; the installer replaces the host and re-registers the service. No Defender exclusion is needed for owlette, and the installer does not add one.

[3.3.1] - 2026-09-08

This release removes a public API surface and changes who may do what on a site. Both are breaking changes; the version is a patch bump by release decision, so read the two breaking sections below before upgrading.

breaking — site roles are per site, and a global admin no longer grants access

Who can do what on a site is now decided by that person's role on that site, not by their account-level role. The same person can own one site, administer a second and be a plain member of a third.

Previously an account-level admin was treated as an administrator of every site it could reach. One role, granted once, applied everywhere — so adding someone to a second site silently handed them administrative rights there too. That is closed: an account-level admin role now grants nothing on a site by itself. Only a platform superadmin still reaches every site.

the three per-site roles

owner — everything an admin can do, plus deleting the site and transferring ownership. Every site has exactly one, and an owner cannot be demoted in place; ownership moves by transfer.
admin — machine commands and configuration, deployments, roosts, talons, webhooks, logs, and managing membership.
member — read-only: view machines, capture screenshots, open live view.

what changes for you

Adding a member as an admin now genuinely makes them an admin of that site. Before, the request was recorded and then quietly downgraded unless the account already held a global admin role — the dashboard, the API response and both SDKs all reported that downgrade even when a real site-admin grant had been written. Roles are also editable per site from the members page; the old advice to contact support to change a role no longer applies.

enrolling a machine now requires site-admin. Generating an installer, minting a setup token, or authorizing a pairing code all issue a machine identity plus a non-expiring refresh token, and revoking one has always been an administrator's job — so issuing one can no longer be less. A plain member who currently runs installers will receive 403 after this release. Promote the people who deploy your machines to admin on the sites they deploy to.

for operators upgrading

Membership rows are created by a one-time backfill that must land together with the security rules and the collection-group index — in that order, index first. Until all three are live, per-site access cannot be resolved. If you self-host, run scripts/migrations/backfill-per-site-membership.mjs (it has a --verify mode and a rollback path) before promoting the web release.

roleHonored in the add-member API response is now always true and is retained only so the response shape does not change. It previously reported whether an account's global role would make an admin request stick, which is no longer how any of this works.

fixed — agent: three faults that made the fleet quieter than it should have been

The roost kill switch had never actually stopped anything on an agent. The agent read the flag through a method its Firestore client does not have, swallowed the resulting error, and cached the failure as "enabled" for the full TTL — so no request was ever made and the switch was never observed, while the changelog said it was checked before every sync. Agents now read roostEnabled from the server-mediated /api/agent/site projection, and a disabled site genuinely halts new roost work.

A stalled display enumeration could stall the heartbeat, and the machine would read offline. Two watchdogs used a thread-pool context manager whose exit waits for the worker, so the timeout they advertised bounded nothing: the call blocked for the full duration of the very hang the watchdog existed to survive. One of them was the only bound on the heartbeat path. Both now abandon the stalled worker, as two sibling watchdogs in the same codebase already did.

A screenshot request could freeze process monitoring for the better part of a minute. The Cortex/hoot IPC pump ran on the 5-second service loop, and a single capture_screenshot takes around 55 seconds end to end. It now runs off the loop, one at a time, with the same result contract.

breaking — the legacy by-URL distribution path is removed

roost is now the only way to get files onto a machine. The v1 "point the fleet at a hosted ZIP and let the agent download and extract it" path is gone in one clean cut — no deprecation window, no compatibility shim. An agent that receives a distribute_project command now logs and skips it.

removal surface

API routes: POST|GET /api/sites/{siteId}/project-distributions, GET|DELETE /api/sites/{siteId}/project-distributions/{distId}, and POST /api/sites/{siteId}/project-distributions/{distId}/cancel all 404. Their OpenAPI paths and the listProjectDistributions / createProjectDistribution / getProjectDistribution / deleteProjectDistribution / cancelProjectDistribution operations are dropped from the published spec.
Agent commands: distribute_project and cancel_distribution no longer have handlers, and agent/src/project_utils.py (download, ZIP extract, verify, cleanup) is deleted. The agent no longer extracts archives at all.
Dashboard: the roost dialog's by url source picker and its project-URL field are gone — uploading a folder is the only source. Saved distribution presets are unaffected; a stored project_url on one is simply no longer read.
Security rules (2.9.0): the sites/{siteId}/project_distributions/{distributionId} block is removed, so the collection falls through to default-deny for every verb.

data at rest — existing project_distributions documents are not deleted. They stay in Firestore, unreachable from any client or server route. Nothing reads them; no archival or purge job was run.

migration — recreate any recurring by-URL deployment as a roost: open /roosts, click new roost, drop the project folder, and pick the same target machines. You get content-addressed chunking, resumable uploads, immutable versions, and one-click rollback, none of which the URL path ever had.

[3.3.0] - 2026-09-05

changed

owlette now only ever manages processes it launched or deliberately inherited. every launch — and every deliberate adoption of an already-running instance — writes a durable identity record: the PID plus the process's creation time and the executable it runs. every kill, restart, stall recovery, schedule-window stop, and deployment close the agent performs first proves the live process still matches that record, and refuses rather than guesses — a PID that Windows has recycled, a process whose identity cannot be read, or a record belonging to a different entry comes back as a plain Error: result naming the reason. previous versions never re-verified a PID before terminating it.
where owlette previously adopted an arbitrary same-image instance, it now launches a fresh one it can identify. several instances of one executable with nothing configured to tell them apart used to be resolved by picking one — and picking wrong meant monitoring, and eventually killing, a process owlette never launched. ambiguity now means a fresh launch. this is safe because the identity record makes owlette re-recognise its own child after every service restart: an entry can produce a duplicate at most once, ever, and then converges on the instance owlette launched. setting the entry's path/args tells instances apart up front and avoids even that one duplicate.
upgrading re-verifies every supervised process; most carry over untouched. state files written by earlier versions carry no identity records, so on its first start after the upgrade owlette does not trust recorded PIDs. an instance it can still identify unambiguously — the entry's path/args in the process's command line, or the only instance of its executable on the machine — is inherited in place and recorded: no restart, no interruption. an entry whose instance cannot be told apart from look-alikes launches fresh instead, and the unidentifiable instance is left running unmanaged — owlette will not terminate a process it cannot verify — so close such stragglers by hand, or set path/args before upgrading so there are none. every service restart after that re-adopts exactly the instances owlette launched or inherited.

v0.4.2b feature	v2.0.0 equivalent
Gmail notifications	Web dashboard alerts + email via Resend
Slack notifications	Web dashboard alerts
Local GUI only	GUI + Web dashboard
Manual configuration	GUI or web-based config
Single machine	Multi-machine, multi-site
N/A	Remote deployment
N/A	Project distribution
N/A	Cortex AI chat