HVAIA Privacy Policy

Version

This Privacy Policy version is 2026-10-privacy-v93. It supersedes 2026-10-privacy-v92. This version requires fresh acceptance after you sign in.

Browser preferences

HVAIA saves your Browser tools on/off choice in the active profile’s local browser preferences. Turning it off stops the agent from starting Browser tool actions; it does not close your manual browser tabs or remove saved site data. HVAIA also saves your full-URL display and bookmarks-bar choices in those profile preferences. If you turn it off, the unfocused address bar shows the website’s origin; focusing the address reveals its complete editable URL. These choices and their revision may be read or changed from a paired iPhone through the existing encrypted Desktop-bound Settings connection. The public relay cannot read the choice or the Settings content, and the phone receives no browser page, URL, password or cookie value from these controls. The preferences are removed with their profile or local device data. These settings use the existing profile preferences and encrypted iPhone Settings transport, with no new recipient, storage root or retention purpose beyond this policy version.

On a paired iPhone, Browser Download location Settings sends only the profile’s saved ask-each-time choice and settings revision through the existing end-to-end encrypted connection. An immediate change result may say Desktop still needs to apply the choice; a later read shows the saved preference, not a verified native application state. File paths, destination picker prompts, and downloaded files remain on the desktop.

You can choose independently whether ordinary web links and local development links open in HVAIA or your default browser. If you choose the default browser, HVAIA hands the link’s address to your operating system for that browser to open. The paired iPhone can change these choices for its paired desktop through the same encrypted Settings connection; changing a choice does not send the link address to the phone.

Browser bookmarks

When you choose Save in the Browser star editor, HVAIA saves the page title and full web address as a bookmark for your active profile. You can organize bookmarks into folders, search, rename, move, reorder and delete them in Browser settings. You can choose to show a bookmarks bar in the Browser. The title and address are encrypted on this device with the profile’s Vault-backed key; the local index keeps only opaque record identifiers, folder order and versions. Bookmarks stay until you delete them or remove the profile or local HVAIA data. Removing a chat, clearing cookies or deleting browsing history does not remove bookmarks. Opening a bookmark sends its address to the selected website through the in-app browser. Bookmark contents are not sent to the model or logs by this manager. The paired iPhone can receive bookmark titles, addresses and folder information only through the existing end-to-end encrypted Settings connection to its paired desktop; it can organize bookmarks and request that the desktop open a saved page in a selected chat. The public relay cannot read those contents. The phone does not keep a durable bookmark cache. If Vault is unavailable, HVAIA cannot read or save bookmarks. When you choose a supported bookmarks HTML export or Safari export ZIP for import, a native file picker gives HVAIA temporary access to that exact file. HVAIA reads it locally, shows counts and conflicts without exposing the file contents to the general interface, and changes only the categories you select after you confirm Import. A Safari ZIP can also include a separate History export for each Safari profile. Where the protected native chooser is available, it shows the export’s own History filenames, which may include Safari profile names, and returns only your selected profile numbers to the ordinary import screen. Other desktop shells show numbered profiles. All start selected, and you can deselect any of them. It imports only the latest valid visit for each exported History item, so a visit count does not create additional visits. HVAIA leaves the original export untouched and does not stage a plaintext copy. Imported bookmarks and History follow the same encrypted storage and deletion rules as manually saved bookmarks and Browser visits. Passwords use the separate protected file-import flow described below. Cookies, contact information, payments, identity documents, vehicles and travel records remain unavailable in this file-import flow until their protected paths are ready. To check an interrupted import after a restart, HVAIA keeps the operation’s opaque identifiers, selected category/profile numbers, safe counts and content-free result in the encrypted profile Browser stores. It does not retain the selected file path, Safari profile filenames or a copy of the export. Category results can be checked without repeating an uncertain import. These recovery records are removed with the profile or local HVAIA data. A paired iPhone can request that its paired desktop start this import flow and can view the import’s opaque operation ID, status, available category names and counts through the end-to-end encrypted Settings connection. The export file, its path, parsed contents and browser permission prompts stay on the desktop. File selection and final Import confirmation happen on the desktop; the phone does not keep a durable import cache or send these details to the public relay in readable form. A lost phone response is checked using the original request ID rather than starting another import. Before opening a bookmark or history visit requested from iPhone, the paired desktop records a one-use, profile-bound claim. It keeps keyed digests and a safe outcome only, without the page address or chat identifier. An interrupted claim is shown as uncertain and is not opened again automatically. These claims remain until profile deletion or local-data reset.

For a large cookie jar, HVAIA records a content-free restore intent in the same profile’s Vault before committing bounded pages to the native browser. It contains the exact profile and chat, random transfer and browser-context identifiers, cookie generation, engine epoch and pending or completed phase; it contains no cookie name, value or website address. After a crash or lost reply, HVAIA checks the original native transfer in the same context and does not automatically repeat an uncertain restore. A new in-memory browser context can safely start a fresh restore from the committed Vault generation. A later cookie generation can still be restored after an earlier completed transfer. The intent is replaced by a later restore or removed with the exact profile’s Browser Vault data.

In a source development build, you can opt to use a separate Browser Import Helper extension in Chrome or Edge. It is distinct from the regular Chrome Specialist extension, which does not copy cookies. The migration helper asks for temporary Cookies and broad HTTP(S) website access so it can show a searchable website checklist; all available websites start selected, and you can deselect them. Its popup holds the selected source-cookie snapshot in memory only, without logging or saving cookie values to disk. It removes its requested permissions after Send or Cancel and on popup disconnect or browser startup. If permission removal fails, the helper tells you to remove the extension manually. The source browser and its extension provider also process the permissions under their own controls.

HVAIA gives you a one-use pairing code that expires after ten minutes. The helper sends only the cookies you selected through a same-user local native host connection bound to that code, source and import operation. HVAIA keeps the candidate in private native memory for at most ten minutes, with a 64 MiB global limit, then erases it after claim, cancellation, profile removal or expiry. The local Browser owner privately reviews bounded pages and shows website names and counts, without sending cookie values through the ordinary interface, model, iPhone, support report or public relay. You select websites again and explicitly confirm Import; HVAIA preserves existing cookies unless you choose to replace a website’s conflicts. Selected compatible cookies are merged into this profile’s local Vault-backed Browser cookie jar. Imported cookies may still leave a website asking you to sign in.

HVAIA keeps a content-free, exact-profile Vault receipt with the original operation identifiers, status, revision, generation, digest and category counts so an interrupted import can be checked without blindly importing again. It contains no cookie values or website names and remains until profile deletion or local-data reset. Optional user-scope Chrome and Edge native-host registrations contain only HVAIA’s executable and exact helper identity; they remain until you remove the helper connection or those browser registrations. The separate helper is not offered in packaged builds until its own extension distribution identity is qualified. You can use supported exports or sign in normally when this source path is unavailable.

Browser history and downloads

HVAIA’s in-app Browser stores committed top-level visits for the active profile, including page address, title, visit time and whether the visit came from you, an agent or an import. It excludes privileged local previews and does not create new visits merely from page-title changes or status checks. History is encrypted on this device with the profile’s Vault-backed key and kept until you delete it or remove the profile or local HVAIA data. You can search, open and delete selected visits or a reviewed time range. Deleting Browser history does not erase page information previously shared in chats. When Browser tools and Agent history access are on, HVAIA’s Browser specialist can search a bounded set of visits relevant to its current task under the current chat permissions. Those results can be sent to your selected model provider: each result can include the page title, address scheme, host and path, visit time and human/agent/import source. Search results omit URL query parameters and fragments, blocked websites, chat identifiers and the raw number of matching visits. Turning off Agent history access stops that agent search; it does not stop Browser history from being recorded for you.

Websites can offer tools to AI agents through the browser’s WebMCP interface. When Browser tools and Website tools are on, HVAIA’s Browser specialist can list the tools offered by the page open in its task, read one tool’s description and input format, and ask the website to run a tool with input the specialist chose. The website decides what a tool does and may change data on that site. Your chat’s permission mode decides whether HVAIA asks you before each call. Tool names, descriptions, input formats and results come from the website and can be sent to your selected model provider like other page content. HVAIA keeps only bounded tool summaries in memory for the current page and discards them when the page changes. Tools on sites blocked for agent browsing, and on pages protected after a saved password or form fill, are not listed or run. Turning off Website tools stops agent tool use without changing your own browsing.

HVAIA also keeps an encrypted record of in-app Browser downloads, including filename, destination, progress and outcome, until you delete that history or remove the profile or local HVAIA data. Removing a download-history entry does not remove its downloaded file. Files you saved outside HVAIA’s profile remain in your chosen location after profile deletion or local-data reset. Browser downloads you start ask where to save by default. You can choose the system Downloads folder instead. Opening a completed download or showing it in its folder hands the saved file location to your operating system only when you choose that action. The human history and download managers do not send these records to models, logs or the public relay. If Vault is unavailable, these managers cannot read or write their encrypted records.

In Browser settings, an all-time cache clear removes HTTP cached images and files from the selected profile’s embedded browser. HVAIA cannot show an exact cache size or delete that cache by date. A protected, content-free local receipt records whether the native clear completed; an uncertain result stays pending for review and is not repeated automatically. When you review another cache clear, HVAIA first checks the same profile’s pending receipts and offers to check the original result. These receipts contain no cached page content. Pages still open may download their files again. This does not remove downloaded files, saved passwords, bookmarks or Browser history.

HVAIA stores your per-website camera and microphone Allow or Block choices under the active profile. The website address and decision are encrypted with the profile’s Vault-backed key; the local index has keyed digests and versions. The choices remain until changed, cleared through Browser settings, or removed with the profile or local HVAIA data. A website-setting clear keeps a protected operation receipt so HVAIA can check an interrupted result without deleting newer choices. Clearing a choice may not stop a camera or microphone stream that is already active. A paired iPhone can view these choices for its paired desktop through the existing end-to-end encrypted Settings connection. Changes from iPhone are enabled only when the paired desktop confirms that browser enforcement is available. Operating-system camera and microphone permission still applies.

From a paired iPhone, you can review and confirm deletion of the desktop profile’s Browser history, download history, cached images and files, and website settings. The request, category counts, signed review and result travel through the existing end-to-end encrypted Settings connection. The public relay cannot read the selection or result, and the phone receives no page addresses, download destinations, website origins, passwords or cookie values from this clear-data flow. Reviews and results stay in iPhone process memory; the paired desktop keeps protected, profile-scoped operation receipts so an interrupted result can be checked without repeating the deletion. An earlier uncertain cache clear must be reviewed on desktop before the phone can start another cache clear. The phone cannot clear cookies/site data or autofill form data until those complete deletion paths are available. If the paired desktop is offline, the phone cannot review or delete browsing data.

When you block an agent from browsing or downloading at a website, HVAIA saves that website origin and the blocked action for the active profile. These rules are encrypted with the profile’s Vault-backed key, remain until you remove them or delete the profile or local HVAIA data, and do not restrict your manual browsing. A paired iPhone can view the rules through the end-to-end encrypted Settings connection; phone changes are enabled only when the paired desktop confirms that both browser engines enforce them. The public relay cannot read the website origins or rules.

Recorded file changes and offline local previews

Regular chats can record changes to specific files you authorize without creating or attaching a project. HVAIA stores supported files’ bounded before/after contents and file identity in the originating chat’s existing encrypted local Changes history. A terminal command may explicitly declare files for this capture; HVAIA does not infer a folder or scan arbitrary command effects. Capture starts after the operation is authorized and remains pending until its owned execution ends. Sensitive or unsupported files remain excluded or metadata-only. Uncertain captures do not become invented snapshots. This history follows the existing chat/profile deletion and reset rules and is not sent to a public relay or support export. Reviewing or restoring it does not reverse effects outside the captured files, and simultaneous edits from another app may be part of a captured state. Terminal restoration requires review, confirmation and unchanged-file checks. Later edits, including changes to a different line, prevent terminal restoration; they are not merged into a restored snapshot.

When you click a local HTML link, HVAIA may read that exact page and bounded statically referenced local assets beneath its directory to run an offline preview inside the Browser pane. Approved agent preview operations name their exact files. HVAIA does not expose the whole directory, automatically share those files with a model, or allow the preview to contact the internet or other local services. The preview uses an isolated in-memory browser context without your normal cookies or saved logins. Its native access credential is temporary and never appears in page JavaScript, URLs, saved browser history, model results or logs. Closing the tab, leaving its owner, deleting/resetting its chat/profile or exiting releases the preview resources, including when an agent closes a tab whose browser view was paused in the background. After browser recovery, a delayed close applies only to its original preview and leaves a newer preview open. Reopening validates the files again and creates a fresh session. Any saved native file capability stays in your profile’s Vault; ordinary encrypted metadata is not itself permission to read a file. An agent’s separately authorized page observations and frames follow the existing Browser and selected-model rules below.

To prevent a delayed preview request from running twice, HVAIA keeps a bounded history of request identities and outcomes in native process memory. It can retire that history together with the old authorization when the limit is reached, without closing existing previews. A new explicit click or a new chat run can obtain fresh authorization; an uncertain request is never automatically repeated. The human click proof and authenticated run creation identity stay within the local app and backend, separate from the preview page and its transport credential. This bookkeeping is not saved, logged, shared with a model, sent to another device or included in support reports, and disappears when the owning app process exits. It adds no file content, external recipient, storage root or consent purpose.

For protected sign-in troubleshooting, the local browser can report only bounded counts of forms and credential-related controls, plus fixed stage, refusal and Google input/continuation layout-match labels, to the existing local Saved Logins interface. This inspection does not read account text, field values, cookies, network payloads or URL parameters, does not start password capture, and writes no new browser-history marker. These temporary structural diagnostics stay on the device and are not added to model traffic, support exports or logs. They do not establish Google-flow or passkey support. Expanded account/password and native passkey handling requires renewed privacy acceptance before it is enabled; it is not enabled by this diagnostic.

After you accept this version, supported Google account and password pages can use a separate protected sign-in flow. HVAIA may temporarily hold the account identifier you submit, or an already-authorized saved account, inside the private native browser connection. It follows a qualified transition before capturing a password you enter and submit. If that account link is unavailable, you can select Choose account to open a protected native chooser. It temporarily reads eligible Google account identifiers from your active profile’s Vault and preselects a saved account. Choosing Fill password rechecks the exact saved record and current page before filling; you submit Google’s form yourself. For another account, enter the exact Google email once. Account labels are painted privately inside the native chooser, inline with the browser where supported, without accessible account values or clipboard copy. The chooser contains no password preview; its bullets are a fixed placeholder. Closing, cancelling or losing the current page discards the private picker buffers. No account value crosses application interface state or the local HTTP API. This human-opened presentation uses the same private native memory and capture protections. It adds no file, log, recipient, saved setting or retention period and does not require renewed consent beyond this version. This is your confirmation of the current account, not proof of Google authentication. Page or owner changes cancel it. The account binding and any password candidate share an original lifetime of at most 60 seconds. Changing accounts, unrelated navigation, expiry, profile loss or browser shutdown discards this temporary state. Unknown page variants remain available for manual browsing without credential capture or release.

Routine Google sign-in checks discard their temporary execution permissions as soon as the check finishes. Confirming an account likewise retains no password execution permission; using a saved login requires fresh page and account checks. This cleanup adds no collected data, storage location, recipient or longer retention, and does not require renewed consent beyond this version.

Only choosing Save or Update writes the Google password to your profile’s local HashiCorp Vault. It belongs to Google, never the website using Google sign-in. Saved reuse sends only your account identifier at the account step and releases the password only after private account and page checks. Human-selected reuse fills the fields for you to submit. Saving or submitting does not establish that Google accepted the password or that verification is complete. Account values, passwords and temporary native bindings are not sent to models, application interface state, logs or support exports. This password flow does not copy or store passkeys and does not establish external-authenticator support.

Browser Password manager on a paired iPhone

Your paired iPhone can show the saved website and account labels, record state, and version from the selected desktop profile through the existing end-to-end encrypted Settings connection. It does not receive a saved username or password. After you confirm Delete on the phone, the paired desktop checks the exact profile, pairing, saved record and version before deleting the password from its local Vault. This does not sign you out of websites or remove their cookies. Adding, editing, revealing and copying a saved password remain desktop actions.

Before sending a Delete request, the iPhone saves one encrypted Keychain recovery reference containing the original request ID, opaque account reference, record version and exact profile and pairing identifiers. It contains no account label, username or password. If the connection or phone app stops before the result arrives, the phone can check that original request without deleting again. The phone removes the reference after confirmed deletion or when that pairing is removed or replaced; an unresolved reference blocks another phone password deletion. The desktop keeps a content-free receipt with one-way owner, pairing and request digests until verified profile credential cleanup. Ordinary local reset preserves an unresolved receipt so a delayed request cannot delete twice. The public relay sees only encrypted Settings traffic and cannot read password labels, deletion details or the recovery reference.

Browser password-file import

If you choose a supported Chrome, Edge or Firefox password CSV or a Safari export ZIP, a protected desktop picker gives HVAIA temporary access to that exact file. The native credential owner reads and parses it locally without creating a plaintext staging copy or changing the original. The file bytes and parsed passwords stay outside the ordinary Browser interface, backend responses, model context, logs and support reports. A one-use picker ticket expires after 60 seconds; a prepared selection and its private candidate values remain in native process memory for at most 15 minutes.

Before you confirm Import, HVAIA shows only counts of new passwords, exact matches, conflicting records and invalid or repeated rows. Existing HVAIA passwords are preserved; this file flow skips conflicts instead of replacing them. Confirming Import writes only the new passwords to the selected profile’s local HashiCorp Vault. Each imported record keeps its website and account label, but cannot fill a website until the native owner binds it to a freshly qualified sign-in form for that exact website. The website decides whether a password is correct when you submit it; HVAIA does not verify the account.

The Vault also keeps a content-free operation receipt with its owner, operation ID, counts, status and revision so an interrupted import can be checked by its original ID. An uncertain import is never repeated automatically. These receipts and imported records remain until the owning profile is removed or its local credential data is cleared. The original export remains your file to protect or delete separately. This password-file import currently starts and finishes on the desktop; the paired iPhone’s Browser import request starts the separate bookmarks and History export flow. Neither the password file nor its values are sent to the phone or public relay.

Browser Contact info

When you choose to add or edit Contact info in the Tauri-based Mac desktop, HVAIA collects the name, organization, email address, phone number, country code and postal-address fields that you enter in a protected native editor. It stores those fields only in the selected profile’s local HashiCorp Vault. The Browser Settings interface and ordinary local management responses receive only the nickname you chose, an opaque record reference and its version; they do not receive the contact fields. A nickname can itself contain personal information. HVAIA keeps each record until you delete that exact record or the owning profile, or clear the applicable local device data. The contact manager supports listing and deletion on other desktop platforms, but its protected Add and Edit editor is currently available only in the Tauri-based Mac desktop. On a qualified HTTPS page, HVAIA can offer a saved Contact label when you focus a compatible form field. If you explicitly choose Fill, the protected native owner reads that exact record from Vault and inserts its values into empty matching fields in the current page. The form must use standard field labels, submit to the same website over HTTPS and remain the same document and form through the fill. HVAIA does not submit the form for you. The website and its page scripts can read inserted fields immediately, including before you submit, so review the website and fields before choosing Fill. A cancelled or uncertain fill is not retried automatically. During a Browser task, Ibn Battuta can also fill the form field it focused, but it receives only the safe nickname, opaque reference, version and the form’s field kinds. It names a record by that reference; the protected native owner rechecks the task, chat, website, document, form and record version, then fills the same empty fields without submitting. In Control asks you before each such fill; Human in the Loop and HVAIA Mode fill without a separate card. After any Contact fill, HVAIA keeps that website’s pages away from agent observation in this profile, so page text that repeats the values cannot reach the model, and the task asks you to review and submit the form. Payment form filling has the separate limits below; Identity, Vehicle and Travel form filling is unavailable. Contact values stay outside React, ordinary local API responses, chat, model input, diagnostics, support reports and the public relay; the selected website receives the values through its form.

On a paired iPhone, Browser Settings can show only those safe nicknames, opaque record references and versions for the selected desktop profile. The phone cannot add, edit, reveal or copy Contact fields. After you confirm Delete, the paired desktop checks the exact profile, pairing, record and version before removing the Contact record from its local Vault. Offline lists are marked stale and cannot change the desktop. Before dispatch, the phone keeps one content-free Keychain recovery reference with the original request ID, record reference and version, and profile and pairing scope. It contains no nickname or Contact field and is removed after verified completion or pairing removal. If a result is uncertain, the phone checks that original request rather than sending Delete again. The desktop retains a content-free deletion receipt until exact profile cleanup so an accepted request cannot be repeated after a restart. These management requests and safe results use the existing end-to-end encrypted Settings connection; the public relay cannot read them.

Browser payments, identity, vehicle and travel records

When you choose to add or edit a payment method, identity document, vehicle or travel record in the Tauri-based Mac desktop, HVAIA collects the fields you enter in a protected native editor. Depending on the category, these can include card and billing details, document numbers, vehicle identifiers, membership and traveler numbers, and flight reservation details. Card security codes are collected only after you turn on Save card security codes in Browser settings and confirm it; that choice starts off and is stored with the profile’s non-secret Browser preferences. With it on, the payment editor offers a masked optional security code field; the code is stored with that card and is never shown again. Turning the choice off deletes every saved security code for the profile; if removal cannot finish, Browser settings says so and offers to try again, and no saved code is filled while the choice is off. HVAIA stores those fields only in the selected profile’s local HashiCorp Vault. The ordinary Browser Settings interface receives only the category, the nickname you chose, an opaque record reference and its version. A nickname can itself contain personal information. The private fields are excluded from chat, model input, ordinary local API responses, diagnostics, screen capture and the public relay. Unused native editor tickets expire after one minute; active editor windows close after fifteen minutes or when the profile is invalidated. Records remain until you delete the exact record or owning profile, or clear the applicable local device data. Protected Add and Edit are currently available only in the Tauri-based Mac desktop; other desktop hosts can list safe nicknames and delete records. No private values are sent to a paired iPhone.

On a qualified HTTPS payment form, HVAIA can offer the safe nickname of a saved payment method when you focus a compatible card field. If you explicitly choose Fill, the protected native owner reads the exact Vault record and inserts its cardholder name, card number and expiration into empty matching fields in the current page. The form must use standard field metadata, submit to the same website over HTTPS, and remain the same document and form through the fill. HVAIA does not insert billing contact and does not submit the form. It inserts a saved security code only while Save card security codes is on, only into an empty matching security code field, and never during a Browser task by HVAIA’s agent. The website and its page scripts can read inserted card values immediately, including before you submit, so review the website and fields before choosing Fill. A cancelled or uncertain fill is not retried automatically. The private card values remain outside React, ordinary local API responses, chat, model input, diagnostics, support reports and the public relay. A Browser task can fill a focused payment field with a saved payment method by its safe reference under the same task rules, confirmations and protected-observation limits described for Contact info; the card values never reach the model. Identity, Vehicle and Travel form filling is not available yet.

On a paired iPhone, Browser Settings can show the category, safe nickname, opaque record reference and version from the selected desktop profile through the existing end-to-end encrypted connection. These labels may themselves contain personal information. The phone cannot add, edit, reveal, copy or fill the private fields. An offline list is marked stale and cannot change the desktop. A confirmed Delete checks the exact profile, pairing, category, record and version again in the native owner before removing that Vault record. The phone keeps one content-free encrypted Keychain reference to the original request while its result is unresolved; it checks that request rather than sending Delete again after a disconnect. The desktop keeps a content-free original-request receipt under the owning credential lifecycle until verified profile cleanup. Neither the record values nor the phone recovery reference are readable by the public relay.

An all-time Autofill form data clear covers HVAIA-managed Contact, payment, identity document, vehicle and travel records in the selected desktop profile. It does not delete saved passwords, bookmarks or website sessions. HVAIA first shows a count-only review; it deletes only after you confirm. The desktop keeps an encrypted profile-scoped operation journal with the exact opaque record references and versions needed to check an interrupted deletion without repeating it. It contains no form values or nicknames. An unresolved native delete can leave those encrypted references in the journal until the profile or local HVAIA data is removed; it is reported as unresolved rather than counted as deleted. Completed operation receipts retain only counts and status until that cleanup. The paired iPhone cannot start this category’s clear flow.

Passkeys in the HVAIA browser

When a website asks for a passkey in the HVAIA browser on a Mac, the browser shows its own passkey window. It stays open only while that website’s tab is visible in the Browser panel. Switching tabs, hiding the panel, pressing Stop, closing the tab or leaving the page cancels the request. The window is excluded from screen capture, so account names, security-key PINs and phone QR codes are not included in screenshots, Computer Use, Visual Memory or model input. You choose the account and approve with your phone or security key yourself; the agent cannot do it for you.

HVAIA does not create, copy or store passkeys. Their private keys stay on your phone or security key, and HVAIA keeps no passkey record, list or log. Passkeys saved only on the Mac itself, such as in Apple Passwords, are not available in the HVAIA browser; use your phone or Open in default browser instead.

If you choose to use a phone or tablet, macOS asks once for Bluetooth permission. Bluetooth is used only during that sign-in, to confirm your phone is nearby. The browser then exchanges the encrypted passkey request and response with your phone through Google’s standard passkey relay service, which cannot read them but, like any internet service, sees network details such as your IP address. Security keys connect directly over USB and use no relay. The website receives the same passkey response it would receive from any browser. This adds no stored data, log or retention period.

Optional Uber app

The optional Uber app, installed from Settings → Apps, adds a local helper and ride instructions for Ibn Battuta and the Chrome Specialist. It connects no Uber account: HVAIA stores no Uber password, code, cookie, payment detail, developer key or ride history for it.

When you ask one of those agents to use Uber, it types the pickup and destination you gave into Uber’s website in the browser you selected — the in-app browser or your chosen Chrome profile — and chooses the ride you asked for. If you ask, it also sets a later pickup time, chooses one of your saved Uber payment methods, or books for someone else by choosing a saved rider or typing the name and phone number you provide into Uber’s new-rider form. Uber receives what is entered or chosen on its website under its own terms, as with any website you use. Signing in happens in that browser, and the final request follows the chat’s permission mode. Adding a new card uses the in-app browser’s existing saved-card autofill: the card is filled privately, is never shown to the model or the helper, and you review and submit Uber’s card form yourself; in Chrome you add the card yourself.

The helper runs on this computer, makes no network requests of its own and has no direct browser access. If you connect System One, HVAIA itself — not the helper — also sends in-app Uber pages to TypeSafe as described in System One (Jev by TypeSafe) below. HVAIA sends it only your ride request text — including a pickup time, rider name and phone number or payment choice when you give one — and bounded page observations needed for the current step: control labels, place names, ride options, displayed fares and times, pickup time, rider and payment-method labels as Uber shows them (such as a card brand and last four digits), and trip status. It never receives passwords, codes, passkeys, card numbers or security codes, cookies, profile folders, full page addresses or their query strings. The selected agent’s model receives the Uber results — route names, ride options, estimated fares and times, pickup time, rider, payment-method label, choices and trip status — under the same model-provider and Chrome data-destination rules as other browser observations.

Tab binding, prepared-quote handles and the safeguard against sending a second request while the first one’s outcome is unknown live only in HVAIA’s process memory. Temporary page references used to check that a quote still belongs to the same page also stay in process memory; they are not stored in chat history or sent to a model. Uber requests and results are kept with ordinary chat and run history like other tool calls and results. A request result can retain the intended route, ride, fare, pickup time, rider and payment label needed to check whether Uber accepted that booking. After a restart, HVAIA reads that existing run history to remember an unresolved request and recover the intended booking details for checking its outcome; it never resends a booking from that history. These follow the existing chat deletion and retention rules and create no separate ride store. The app’s files and instructions use the existing Apps storage, or your source checkout in development, and its local tool registration stores the helper’s launch command and local package location. Logs, support reports, notifications and Settings or paired-iPhone status contain no addresses, fares, rider details, payment labels, trip details or page addresses — only content-free installation and readiness status.

The in-app browser specialist can use one helper call to prepare, request and verify a ride. HVAIA checks the passenger count, pickup timezone and any spending limit and currency you supplied along with the booking details. These constraints can remain with the intended-booking evidence in the same ordinary chat and run history for checking the outcome after interruption; they do not grant permission to send another request. This combined call adds no separate ride store, recipient or retention period, and the final request still follows your chat’s permission mode.

Uninstalling Uber removes its helper registration, installed app files and instructions. It does not sign you out of Uber, delete browser data, saved logins or chats, or cancel a ride. Without System One, this optional feature adds no cloud recipient, storage root, retention class or public-relay-readable content beyond Privacy Policy version 2026-09-privacy-v90.

Wake Up tasks

When a manual task run defers, HVAIA preserves the independent scheduled occurrence under the existing task rules. Chat recovery also preserves newer helper activity while applying a verified final result to the same chat and run. These reliability corrections use the existing private task records and encrypted chat storage; they add no data category, recipient, storage location, retention period, or renewed consent requirement.

For an optional “Only when new files appear” condition, HVAIA stores the chosen folder path, hidden-file preference, initial filenames, acknowledged filenames, and pending occurrence batches in the existing private local task database. It checks immediate regular filenames without reading file contents or following child symlinks. Existing files form the baseline; hidden files are excluded unless you include them. Unchanged checks do not contact a model. On a change, bounded new filenames are supplied as untrusted context to the execution chat’s selected local or hosted model under the same provider terms as chat. Checkpoints remain until the condition is removed or changed, or the task is deleted. They are not sent as readable relay data or copied into scheduler error diagnostics. Folder configuration sent to a paired iPhone stays inside the existing encrypted envelope. Command-enabled model turns also receive the execution computer’s host name, operating system, and default execution shell so commands match that computer.

When the agent leaves a command running in the background, such as a local dev server, HVAIA keeps watching it on this computer so the chat can show its status and output and you can stop it or start it again. Its live output stays in app memory. In the chat’s existing encrypted storage, HVAIA keeps at most 32 of these records per chat: the exact command it recorded, the folder the command started in, its status and exit code, who stopped it, and up to 16 KiB of final output. These records are deleted with the chat, your profile or local data, are not copied when you fork a chat, and never leave this computer through exports, support reports, your iPhone or the relay. The agent’s next turn receives only counts, such as one running and one stopped by you. It receives commands, folders and up to 4 KiB of recent output only when it asks, and only through your selected model provider, like other terminal results. This adds no data category, recipient, storage location or retention period, and requires no renewed Privacy Policy acceptance.

This also covers children started with &, nohup or similar commands while they remain inside HVAIA’s owned terminal session or process job. HVAIA checks local process identity and membership in temporary native memory to keep the existing status and Stop controls accurate. It does not adopt unrelated processes or automatically read redirected files such as nohup.out. The same bounded encrypted record distinguishes the launcher’s exit status from an unavailable child exit status; no new storage location, recipient or retention period is introduced.

Saved scheduled instructions are execution context, without a repeated synthetic human chat entry on each tick. Agent-created tasks leave a compact creation receipt in the source chat’s existing tool history. Pending approvals, questions and plan reviews remain in the owning chat while the scheduler continues. The desktop discovers updates using task/run/chat identifiers and status; these notices contain no filenames, prompts or model output. Removing the Run History interface does not remove the existing task diagnostic retention or deletion rules.

When the model asks how to configure HVAIA, large capability replies use compact operation names and explicit reads for complete operation inputs. Capability health can similarly use a names-and-states index followed by a requested diagnostic read. The complete local tool receipt remains available under the existing chat history rules. Rejected Wake Up setup calls may return field names and permitted input shapes so the model can correct its request; those repair hints do not repeat your task instructions, folder paths, or invalid supplied values. These corrections use the existing model provider and local diagnostic storage boundaries, add no recipient or retention period, and do not change approval authority or require another Privacy Policy version.

Wake Up is the one current feature for asking HVAIA to act later. A Wake Up can run at a chosen time, after one of HVAIA’s listed lifecycle events, when a matching Gmail message arrives, or when an authenticated webhook arrives. Each task has an ordinary home chat. It runs in that chat, in one dedicated ordinary chat, or in a fresh ordinary chat for each occurrence. A dedicated chat initially copies the authoring chat’s settings if there is one. A fresh run chat copies its selected source chat’s permission mode, model, and applicable project settings when that run chat is created; later source changes affect future chats only. Each new chat has an empty transcript. HVAIA sends the saved task instructions and permitted trigger context to the chosen model under the same local or hosted provider terms as an ordinary chat. Existing and dedicated chats use their own current settings. Wake Up does not store a separate permission mode, model override, pre-approved action list, or Otto authority. Ordinary chat approvals still govern protected actions. An exact self-continuation resumes its source chat under that chat’s current permissions. The backend verifies the active work and its pending scheduling call before registering a one-time continuation without another scheduling confirmation. This does not grant permission for later tool actions or ordinary scheduled-task changes.

HVAIA stores each task’s owner, home chat, destination, instructions and verified digest, trigger configuration, notification choice, state, and occurrence history in the existing profile-owned local task storage. A lifecycle Hook carries only allowlisted event identity and metadata, not raw prompts, tool arguments, output, or notification bodies. Gmail matching retains the existing mailbox history cursor, ownership, subscription, message deduplication data, and message-received time. A task also retains when its current Gmail subscription became eligible so mail received before creation or while paused cannot start new work after activation. HVAIA passes bounded Hook, Gmail, and webhook identifiers and allowlisted metadata as untrusted context to the chosen model for that turn, then retrieves any email content through ordinary chat tools and permissions. This trigger context is not added as a separate saved chat message. A webhook is verified in memory with a time-bound, task-bound signature. HVAIA does not retain or send the arbitrary webhook body to the model; it keeps only bounded authenticated event identity, allowlisted metadata, and delivery diagnostics. Signing secrets remain only in local HashiCorp Vault and are never shown back to the model, interface, logs, traces, or receipts. Configuring a local webhook endpoint does not make that endpoint publicly reachable. Paired iPhone requests, task details, metadata, and results remain inside the existing encrypted desktop-bound relay envelopes; the public relay receives no readable task content or webhook body and is not a Wake Up executor or durable webhook queue.

For Gmail push matching, HVAIA reads each message’s received timestamp, sender, subject and labels from Gmail metadata before applying your filters. This step does not read message bodies or attachments. Metadata is processed in memory; the existing local match records retain message identity and received time, without adding sender or subject content to task history. All history pages must finish successfully before the saved mailbox checkpoint advances. A failed read retains the checkpoint for retry, with existing duplicate protection. The existing local mailbox record keeps a content-free retry diagnosis until processing succeeds; it does not copy provider exception text or email content. Separate approval, input and plan-review alerts use content-free request identities; notification choices and encrypted iPhone delivery remain unchanged.

Task diagnostics and attempt history remain until the Wake Up is deleted; there is no age-based task-history purge. Stop cancels current work and its owned continuation timers while leaving future user-created triggers enabled. Pause stops future automatic admission without deleting history. Deleting a task cancels its work and removes its task-owned instructions, history, subscriptions, and secrets through retryable cleanup, but preserves ordinary chats and their chat-owned Changes. Deleting its home chat first stages deletion of the dependent Wake Ups, then removes that chat and its content. Deleting an independent result chat preserves the task and only non-content occurrence metadata; it removes that chat’s content and Changes, and task history must not keep a hidden copy. Shared Gmail resources remain until their other owners or subscriptions no longer need them. Profile deletion completes only after both Wake Up and exact-owner retired Automation task data, including task-owned secrets, have been cleaned up; incomplete cleanup remains visible and retryable. Obsolete Automation notification intents and their discovery receipts are removed from the local notification store at owner-validated initialization, while current and unrelated notifications remain. A development task-only cutover removes old Scheduled and Automation task records and proven task-owned resources while preserving ordinary chats, projects, connector accounts, shared watchdog resources, and chat-owned Changes.

Before a continuation resumes, HVAIA saves its exact source-run and result-chat link in local task history. While a chat waits for an exact continuation, HVAIA keeps its display current through the existing local authenticated run-update stream. Update notices carry only opaque run identifiers, state versions, timestamps, and a fixed readiness label used to suppress repeated updates after chat storage is ready; the owning desktop retrieves the answer through the existing profile-protected chat and publication storage. These notices contain no prompt, answer, tool arguments, or tool output. They follow the existing run-journal and chat-deletion boundaries.

The earlier Scheduled and Automations descriptions below document prior policy versions. Where they differ from this section, the current Wake Up rules above govern. This change lengthens task-history retention and changes chat-linked deletion behavior, so it requires the fresh acceptance stated above.

This version adds optional uploaded meeting recordings: transcription by Alibaba through HVAIA’s private temporary VPS storage, speaker-labelled transcripts, same-profile cross-chat retrieval, and separately consented local reusable voiceprints. Recording processing remains off until you enable it and confirm its transfer consent in Speech-to-Text settings. Accepting this policy does not enable recording uploads, install a speaker model, save an API key or enroll anyone’s voice. The detailed recipients, retention, deletion and confirmation rules appear in the recording sections below.

Chat activity time is used to order your chats. New chats and forks receive an initial activity time, and fresh direct prompts retain their activity update. Queue changes, run and Plan status changes, suggested titles, project renames, document processing, saved computer-use evidence, Voice transcripts and task linking, delegation, background timeline updates, recovery, and linked-chat deletion repairs save without changing an existing chat’s activity time. Working and unread indicators do not promote chats or projects. Existing encrypted chat revisions and record timestamps still track saved changes and protect concurrent writes. These metadata changes use the same protected local storage and end-to-end encrypted paired-device projections; they add no data category, recipient, storage root, retention period, or relay-readable content. Privacy Policy version 2026-09-privacy-v85 remains current, with no additional consent requirement for this narrowing of activity metadata updates.

Opening a chat or viewing a newly finished response clears its completion or failure badge. HVAIA saves the existing content-free activity acknowledgement identifier in the protected chat record. A paired iPhone sends that identifier to Desktop inside the existing end-to-end encrypted chat intent. This changes when existing acknowledgement metadata is saved and sent, without adding a data category, recipient, storage location, retention period, or consent purpose.

Choosing Open in Chat for a Studio output is an explicit durable Files action. If the selected destination is the untouched startup New chat, HVAIA first creates that chat’s ordinary encrypted local capsule, including its existing unsent draft, before requesting any authenticated file-open session or per-chat viewer state. If that scoped save fails or the active profile or chat changes, HVAIA opens no file session or Files workspace. The resulting capsule uses the existing chat retention, deletion, profile-reset, encrypted paired- device, and public-relay-blindness rules; this adds no data category, storage root, external recipient, retention period, or renewed-consent requirement, so Privacy Policy version 2026-09-privacy-v85 remains current.

The Desktop Still working elapsed label is temporary presentation computed from the existing tool start time. Progress updates do not create timer events, trigger extra polling, or persist elapsed labels. Generic running narration is filtered from contextual tool-card summaries; raw tool summaries and output retain their existing protected storage and retention. This changes only derived presentation metadata and adds no data category, recipient, storage root, retention period, or consent purpose; it requires no additional Privacy Policy acceptance.

If an approved Plan cannot proceed within its allowed scope, HVAIA retains its model-authored blocker explanation, unfinished step statuses and failure reason in the existing protected plan and tool history. Paired-device presentation uses the existing end-to-end encrypted chat projections. Explicitly retrying keeps the failed source and its reviewed Plan intact. This adds no separate storage, telemetry, recipient, retention period, relay-readable content or consent purpose, and requires no additional Privacy Policy acceptance.

When you ask HVAIA to stop checking and conclude an approved task, its existing protected chat and tool history retains the model-authored explanation and unfinished steps marked Stopped at your request. Content-free run, reviewed-plan and applied-steering identifiers bind that outcome to your request for recovery and duplicate-publication prevention. These records follow the existing ownership, encryption, paired-device projection, deletion and retention rules. No new recipient, storage service, retention period or consent purpose is added; no additional Privacy Policy acceptance is required.

An ordinary chat’s execution plan may also retain a validated blocker explanation, unfinished step statuses and failure reason in that same protected history, without becoming a reviewed Plan or an attached project. Regular-chat file work uses the existing terminal permissions and history; shell edits do not create filesystem Undo snapshots. Corrected terminal outcomes and actor labels use existing evidence. These clarifications add no storage, recipient, retention period, readable relay content or consent purpose and require no renewed Privacy Policy acceptance.

Steering an already approved execution preserves its existing reviewed Plan and approval in that protected history. Terminal recovery preserves the actual command outcome and existing download actions; concurrent polling retains ordered unread output within the existing bounded process logs. The terminal drawer reads the same chat-owned process records used by background-process controls, without treating an older transcript as authority over a later restart. A Stop request with a mismatched session and command leaves the actual process’s existing protected record and output unchanged. An internal Stop that selects the current command keeps that identity throughout cancellation, so a later command cannot receive the earlier command’s Stop or have its output and status attributed to that earlier record. These repairs add no data category, storage location, external recipient, retention period, readable relay content or consent purpose, and require no additional Privacy Policy acceptance.

When delegated work finishes after an approval pause, Desktop uses the existing local completion event and verified publication receipt to recover the answer into the same protected chat. Approval audit receipts do not create additional tool calls. Recovery may remove a duplicate display row proven to contain only an approval receipt, while preserving the underlying audit events and every actual model-issued call. Status-only delegation views use generic labels that distinguish visible chats from inline helpers without exposing private task titles or instructions. These corrections use existing local and encrypted chat storage, add no recipient or storage root, and change no retention period, deletion boundary, or consent purpose; no renewed Privacy Policy acceptance is required.

When you answer an inline specialist’s question, its local settlement event keeps only the existing tool, call and request identifiers and whether an answer was received. The answer itself is not copied into that event. This uses the existing local run-history retention and deletion rules, adds no recipient or storage location, and requires no renewed Privacy Policy acceptance.

After email verification, HVAIA refreshes the verification status already stored for your active local profile. While its Google connector is running, HVAIA may periodically recheck the hosted broker’s public OAuth client identity using the existing authenticated relay connection and restart its own local connector if that identity changes. This check does not request the Google OAuth client secret or transmit your Google content, and it does not remove your saved OAuth tokens. The public client identity remains in process memory. This clarification adds no data category, recipient, storage location, retention period, or consent purpose.

This revision requires renewed consent for explicitly started continuous primary-desktop task video. Settings only allow recording; you must choose the task’s scope, opt into video and click Start recording. Primary desktop captures what is visible on the display selected as primary at Start, including intervals with no computer-tool calls or only app actions. Protected windows are excluded before capture, and fresh native protection checks gate every admitted frame. Temporary privacy gaps pause video and retry safely; permission loss, credential entry, owner loss or unrecoverable capture failure stops it. Changing the primary display requires a fresh Start. Selected-window recording remains the scope for an obscured application window. Both choices exclude other displays, audio, microphone and camera input, retain the five-frame-per-second ceiling and 2048-pixel maximum edge, and keep the existing 24-hour and 256 MiB video limits.

Continuous primary-desktop video adds one bounded recording stream beneath the existing exact-task native capture owner, alongside that task’s selected-window preview or capture-recovery stream. It creates no new helper process, storage root, external recipient or public-relay-readable content. The existing private recording manifest may additionally retain a successful encoded-frame count and a finite content-free video failure or pause reason. These diagnostics synchronize during existing status operations, not on every frame. Historical missing footage, counts and reasons are not reconstructed or backfilled. Incomplete initial privacy checks keep recording paused and retry without starting an unfiltered stream; you can stop this wait. A stream that cannot encode its first frame within five seconds after acknowledgement fails with the available specific cause; a successful Start alone is not proof that video exists.

Primary-desktop protection also excludes system decorations owned by macOS WindowServer, which is not a normal app. HVAIA first verifies that exact live process against Apple’s signature and WindowServer identity, then excludes all of its captured surfaces. It also excludes native screen-sharing badges whose exact window identity is verified by the existing app-window safety checks. The capture helper’s own presentation windows remain excluded using its exact current process and verified live signing identity, even when that executable has no app-bundle identifier. Those checks remain in temporary native memory and grant no control over system UI. Unknown or unverifiable owners still pause capture; no app names, window content, paths or raw ownership diagnostics are added to the recording manifest.

Task completion, failure, cancellation and shutdown save or safely terminate the exact-owner recording without requiring its panel to be open. Unconfirmed Stop remains visible and retryable. Watch video is an explicit authenticated, size-bounded local MP4 fetch into the Recording panel, with ordinary playback, seeking and fullscreen controls. Closing the panel, deleting the recording or changing its owner releases temporary player data and aborts stale requests. The existing recording, export, chat/profile/device deletion and encryption boundaries remain unchanged. Continuous video does not manufacture observation snapshots or before/after evidence, so a playable recording may correctly contain zero task views.

The v83 disclosure remains in effect: HVAIA offers optional Visual Memory. It is off by default and begins only after you enable it; HVAIA does not backfill images from older chats. For each new completed ordinary-chat publication while enabled, HVAIA may send up to eight eligible new user-sent or successfully committed assistant-generated images to Alibaba Model Studio’s fixed tongyi-embedding-vision-plus multimodal embedding service. For an eligible later text prompt, HVAIA may send one query of at most 1,024 UTF-8 bytes to that service. These requests use your shared Alibaba API key, may consume provider quota or incur charges, and are processed under Alibaba’s terms and privacy practices. Side Chat, delegated prompts, Automations, Scheduled runs, Telegram, Computer Use frames, Shared Files screenshots, Studio assets, video, documents, cancelled runs, and uncommitted tool output are excluded.

Chat deletion removes local Memory session, document, keyword, manifest, and Visual Memory derived data through the existing profile-owned storage boundary even when an embedding provider is unavailable. HVAIA may make one bounded reopen/reprobe for a recognized transient local-store failure; it does not repair, recreate, migrate, or quarantine storage during a delete request. Missing, corrupt, pending-recovery, or concurrently owned storage fails closed and keeps the chat. A preflight failure says the chat was kept; a failure after the deletion tombstone says cleanup is incomplete. Storage-unavailable guidance tells you to free disk space or restore local access before restarting and retrying. Support diagnostics retain only finite, content-free reason, diagnosis, retry, outcome, and phase metadata and never include chat content, paths, secrets, response bodies, or raw exceptions. This clarification changes no recipient, storage root, retention period, or consent version beyond Privacy Policy version 2026-09-privacy-v85.

HVAIA stores only content-free image references in the existing canonical chat-scoped Memory session and 1,152-dimensional derived vectors in the existing profile-owned Qdrant root. Each reference retains a source digest solely to verify that the current encrypted source is still the exact captured image; the derived vector payload does not contain that digest. HVAIA does not create a second image cache or store image bytes, Base64, filenames, absolute paths, captions, prompt text, profile identity, or secrets in those references or vector payloads. Original user images and generated images remain under their existing encrypted chat/materialization or visual-artifact retention rules. Eligible still JPEG, PNG, WebP, and BMP sources are revalidated locally, orientation-corrected, stripped of metadata, and transiently normalized to a bounded RGB JPEG before provider transmission; corrupt, MIME-mismatched, animated, decompression-unsafe, or still-oversize images are skipped.

When a later text prompt has a sufficiently strong match, HVAIA may transiently send at most one recalled prior-chat image to the chat provider you already selected, but only if that selected model accepts images and the request remains within its media/context limits. HVAIA does not switch models or invoke another vision fallback. The provider receives a concise warning that the prior image is untrusted historical context, not instructions or a new attachment. The image and warning are excluded from durable run checkpoints, caches, logs, events, support reports, relays, and UI state; only the content-free reference remains. After a prior image is prepared for the selected vision model, the existing encrypted chat/run metadata retains one content-free event with the source chat and message identifiers. Desktop and a paired iPhone can show “Image from Visual Memory” and open the source chat from that event; the iPhone receives it only inside the existing end-to-end encrypted channel, and the public relay cannot read it. Lookup, source, provider, or hydration failure removes the unresolved reference and lets ordinary text chat continue with a finite degraded Memory status.

Disabling Visual Memory stops new indexing and recall without deleting existing dormant references or vectors. Deleting the shared regional Alibaba key removes it from the profile’s Chat slot when Chat uses a regional endpoint, and from the regional speech, image, video, Memory, Visual Memory, and uploaded-recording Vault slots. A Coding Plan Chat key remains separate even if its text matches a regional key. Switching Chat between Coding Plan and a regional endpoint removes only its saved Chat key after confirmation; the other Alibaba keys remain available, and you must save a key valid for the new Chat endpoint. Deleting a shared regional key stops hosted indexing and recall while preserving your Visual Memory enablement choice and existing derived data. A publication with captured image references is acknowledged without repeated retry while the key is absent; restoring a verified Singapore key can index those references through background repair and resume the enabled feature. Saving a shared key or changing its region aligns supported Alibaba endpoints only after confirmation, and an incompatible selected model blocks the change. Re-enabling it does not discover or import uncaptured historical images; derived visual collection repair uses only references captured while the feature was enabled and revalidates each retained source. That repair runs in the background rather than on your prompt: while it is pending, chat starts immediately and simply recalls no image until the rebuilt collection is ready, and sending more prompts does not start extra work. Repair keeps only a bounded in-memory position and a content-free change counter, rechecks your live opt-in, the current configuration, deleted chats, and each retained reference before every send and before writing any result, and stops if you opt out, delete the key, change the region, or close the profile. These changes add no cloud recipient, storage root, or retention period beyond the disclosures above. Chat rewind immediately prevents recall of removed sources and cleans their references and points; chat deletion verifies and removes the exact session references and points, while profile deletion and local-data reset remove the visual collection through the existing profile-scoped Memory lifecycle. A recalled image remains subject to the original source’s retention: Visual Memory itself does not preserve a deleted or rewound source.

The v82 disclosure remains in effect: after app authorization, Computer Use can return a bounded title hint and recovery condition for up to 32 windows belonging to that exact app, including minimized, hidden, offscreen, or not-currently-onscreen windows, and can recover the selected entry through a short-lived catalog index. The selected model receives that bounded catalog as an ordinary Computer Use tool result; any resulting local tool transcript follows the existing encrypted chat/run retention and deletion rules. HVAIA creates no separate durable window catalog and exposes no process identifier, native window identifier, window bounds, display identifier, or Space identifier. The ephemeral catalog authority is discarded on use, replacement, accepted Computer Use mutation, app-access revocation, task end, or process exit and is excluded from logs, support data, encrypted metadata history, recordings, paired-device state, and public-relay-readable data. A hosted model processes the bounded title hints under that provider’s policy; a local model processes them on this device.

The same authorized capture may now use one bounded ScreenCaptureKit stream frame when the ordinary ScreenCaptureKit screenshot manager fails or times out for an allowlisted backend reason. It never falls back to the screencapture command or another capture backend, never requests a new permission, captures no audio, microphone, or camera input, and cannot create a second stream beside an active preview. A single-display regional zoom may be processed at native pixel density in memory before the same protected-content checks, secure-region redaction, 2048-pixel longest-edge limit, 16 MiB PNG limit, and final target proof are applied. Raw and fallback frames are not written to disk or exposed before proof; only the already permitted final privacy-filtered observation follows the existing tool-result, selected-model, evidence-save, and optional recording boundaries.

The v81 disclosure for optional encrypted Computer Use history retaining and locally returning one bounded app display name with a Vault-keyed pseudonymous app identifier remains in effect. That history still excludes canonical app identities, provider references, window or page titles, paths, URLs, inputs, clipboard data, screen content, credentials, secrets and arbitrary errors. The v80 disclosure for the one best-effort post-deletion receipt, the v79 disclosure for confirmed Computer Use launches, the v78 disclosure for explicit primary-desktop scope, bounded clipboard access, separately enabled action/step recording and protected video, and optional encrypted metadata-only history remain in effect, as does the v77 disclosure for temporary macOS accessibility projection. Earlier Computer Use interaction with authorized terminal apps and embedded terminals, independent-cursor feedback, checked-file transfers and supported existing-login submission retain their protections. Computer Use remains Experimental and off by default.

Optional Computer Use expansion

Reliability corrections now preserve the exact recording owner through a rejected native Start, keep interrupted recording cleanup durable and retryable, and leave disabled-history deletion retryable. Expired encrypted metadata history is removed before its storage quota is applied. Browser failures may retain only registered, content-free first-party reason codes through the existing local tool-result and durable-event lifecycle; page content, URLs, raw errors, credentials, and arbitrary code-shaped values remain excluded. A completed profile deletion whose local recovery checkpoint cannot be cleared is still treated as completed and asks you to restart instead of submitting deletion again. When an app launch cannot confirm that the app started, HVAIA now remembers that single fact in temporary memory for that task only and clears it after a later verified look at the same app, so routine work can continue without repeating the launch. It also names a few more finite, content-free failure labels for launches, stale window selections, and window repainting. These labels are fixed words chosen by HVAIA, never app content, window titles, screen pixels, paths, URLs, or your text. These corrections enforce the existing storage, retention, deletion, and diagnostic boundaries and add no recipient, storage root, or retention period, so Privacy Policy version 2026-09-privacy-v85 remains current.

On macOS, Voice screenshots and Computer Use now use one lazy signed capture-helper process owned by the existing Rust runtime instead of launching competing same-identity helpers. They remain separated by opaque in-memory contexts: each Computer Use task retains its own authorized target, protected frames, preview, recording writer, Stop state, temporary credentials, and cleanup, while Voice has screenshot-only authority and cannot type, click, access credentials, record, or receive another task’s pixels or grants. Up to four Computer Use contexts and one pending Voice capture may coexist. A fatal helper retirement can interrupt all of those current captures, but ordinary Voice End and Computer Use Stop close only their exact contexts. Recovery retains only bounded content-free helper generation, opaque context and request identifiers, retirement kind, one of four finite timeout causes, operation class, and deadline facts; it does not retain screen content, target identity, input, credentials, paths, or arbitrary native errors, and it does not enable unrestricted helper logging. A settled unhealthy physical-input monitor is repaired in the same helper through a transient status-only context; before that attempt, HVAIA advances only its existing content-free unknown-input/activity counters so observations that overlap the blind interval become stale. This neither records keys or pointer coordinates nor allocates another task context. Existing per-task temporary-frame prefixes and storage roots remain unchanged, and cleanup still deletes only proven owned files. Recording remains separately opt-in; an unrecorded completed task continues to have no recording artifact. This internal reliability change adds no data category, external recipient, storage root, retention or deletion period, relay-readable field, or renewed-consent requirement, so Privacy Policy version 2026-09-privacy-v85 remains current.

Computer Use history search text travels only in the authenticated local POST body, not in a URL. If a malformed client nevertheless places a search value in a query string, HVAIA rejects it as history criteria and redacts it from access-log and incident-metadata query fields. This prevents the newly retained bounded app display name from entering operational logging and does not add a recipient, storage root, retention period, or consent change beyond Privacy Policy version 2026-09-privacy-v83.

When action/step recording is enabled, up to four different owned Computer Use tasks may record at the same time. Starting a second recording for the same exact task is rejected before native capture begins, and each recording has its own Stop, finalization, export, and deletion boundary. An unconfirmed active manifest still occupies one of the four places until HVAIA can prove that exact native owner inactive; this avoids starting unbounded capture after a crash or ambiguous restart. These recordings retain the same owner-only roots, fields, limits, and deletion rules described below.

When you explicitly choose Repeat adaptively on a completed recording, HVAIA starts a new ordinary task immediately. The recording itself remains local. HVAIA sends the model already selected for the new task only a bounded privacy-filtered guide: target scope; up to 128 coalesced action categories; each category’s finite outcome, effect, count, and total duration; a source-turn count; a one-way guidance digest; and instructions to observe the current screen first, re-resolve current targets, apply current permissions, and never replay literal prior input. It does not send recorded arguments, app or account identity, labels, coordinates, typed text, key names, paths, URLs, clipboard data, captures, credentials, tokens, or secrets. The submitted guide becomes an ordinary user message in that chat and follows its existing model-recipient, encrypted history, retention, and deletion rules.

An enabled protected-video export may burn a cursor marker and content-free click cue into frames that have already passed the recording’s capture, target, protected-content, and redaction checks. It may also derive a bounded crop/zoom presentation and compress long idle intervals in the video timeline. These presentation choices use only already accepted pixels, accepted action coordinates, and monotonic timing in temporary encoder memory; they create no separate cursor, click, crop, or timing artifact, add no audio, and never admit a suppressed protected or credential frame into the encoder. The encoder can retain only one normalized cursor, click, zoom, and action token plus at most eight coalesced activity windows; that state cannot represent text, key values, clipboard data, paths, URLs, credentials, arbitrary errors, action payloads, raw event logs, or pixels that have not passed the capture filters. Online composition adds no second capture or export process, recipient, storage root, retention/deletion rule, or export boundary.

Protected autofill is limited to Apple Passwords and can run only after that exact signed provider route and release build have separate local qualification evidence. 1Password and Bitwarden are not integrated providers; they remain protected from ordinary Computer Use. During probe and fill, HVAIA pauses every Computer Use capture path for the task and keeps it paused through completion, error, or manual handoff. HVAIA may pass the qualified provider only an opaque, freshly validated secure-target token and the requested provider kind. It does not read, return, log, record, retain, or send to a model any credential, account choice, secure-field label or value, screenshot, clipboard item, or provider content. A locked provider, MFA, ambiguous selection, stale target, unavailable route, missing qualification, or uncertain result returns control to you and is never reported as completed automatically. The release-default qualification registry remains empty until physical qualification succeeds. This provider removal adds no data category, recipient, storage, retention, or deletion behavior, so Privacy Policy version 2026-09-privacy-v85 remains current.

Computer Use must be enabled before it can act. Multiple authorized tasks may progress at the same time, but HVAIA serializes shared physical input, foreground focus and clipboard transactions. The preview shows one selected task at a time; switching the selected preview never pauses, retargets or cancels another task. Stop applies only to the selected task. Computer Use does not continue after normal app shutdown, does not add background-on-close or autostart, does not install a standalone service, and does not control a locked screen.

Source and packaged HVAIA processes coordinate those shared resources through one private per-user operating-system temporary directory. It has a fixed maximum namespace: four empty global lock files, 256 empty app-lock shards, and 256 target-generation shards. One global lock ensures only one source or packaged process can create native Computer Use authority; the other three serialize physical input, foreground focus and clipboard transactions among concurrent tasks inside that owner. A contender starts no Computer Use helper or capture and reports that Computer Use is busy. Each target shard stores only one small unsigned generation counter used to make an older observation stale before another action can be sent. Its filename identifies only a fixed shard, not an app or window; collisions can delay work or require a fresh observation but cannot authorize or retarget an action. These files contain no profile, account, chat or run identity, app/window identity, screen or clipboard content, action argument, timestamp, outcome or diagnostic. They are not sent to a model, relay, log, support report, recording or metadata history. Operating-system advisory ownership ends only when every still-running owned Computer Use worker exits or its process exits or crashes; bounded files may remain for reuse or be removed by operating-system temporary cleanup. HVAIA data reset does not unlink this shared directory because another current process may still hold a lock there. This adds only one empty content-free coordination file inside the already disclosed temporary namespace and no new content category, recipient, or retention purpose, so Privacy Policy version 2026-09-privacy-v85 remains current.

Each task normally observes its exact selected app window. A task may observe and control the whole primary desktop only after that exact scope is explicitly selected; exact app-window work on another display remains available. HVAIA does not add an all-display capture scope. The ordinary protected live preview remains local and temporary and is shown in HVAIA by default. An optional movable, always-on-top detached preview uses the same local protected frames and exact selected-task binding. Neither preview mode by itself records frames, sends them to a model, adds them to chat or events, or writes a preview cache. Explicit Save evidence retains only the selected still under its existing lifecycle.

Action/step recording is a separate opt-in that is off by default. When it is available and you explicitly start it, an owner-only local JSON artifact may retain up to 10,000 settled actions or 8 MiB for the selected task. It can include the ordinary app reference, menu labels, semantic target or coordinates, window geometry, ordinary text and key names you asked HVAIA to enter, bounded cursor-sample count, timing, result and finite execution evidence. While that explicit recording is active, HVAIA also retains task views by default: up to 512 owner-only local PNGs, each no larger than 16 MiB or 2048 pixels on its longest edge, with a 256 MiB total limit. It copies only an already accepted privacy-filtered observation for the exact selected window, or an already filtered primary-desktop observation when you explicitly chose that whole-primary-desktop recording scope. It never starts a second capture or retains a raw or pre-filter image or accessibility-state copy for these views. Ordinary visible text can appear in a retained view. Exact recording-turn, target and observation-generation evidence links an available before view and the first later same-target after view; timestamps are not used to infer the link. If that exact evidence is missing, stale, stopped, replaced, ambiguous or over quota, the view remains unavailable instead of being guessed. A protected or credential-bearing action suppresses every context-bearing argument before reservation, binds no task-view pixels and retains only finite action, result and count facts. Passwords, credentials, tokens, clipboard payloads, raw errors, raw file paths, complete launched URLs, URL queries and fragments are excluded. You can view or save each retained task view through its exact local recording, while the JSON export contains only its metadata and before/after references. Deleting the recording or its owning chat, profile or device data removes its retained task views; a copy you explicitly save is user-owned. This durable task-view retention is included in renewed consent at Privacy Policy version 2026-09-privacy-v81.

Protected video is another opt-in nested under action/step recording and remains off until separately enabled. On macOS 15 or later, you may request it for either the exact selected window whose protected live preview is already active or an explicitly selected primary desktop. Selected-window video consumes only images that already passed fresh before-and-after native target and protected-content checks and secure-region redaction in that existing live-preview stream. Primary-desktop video is continuous after explicit Start: a dedicated display stream beneath the existing task owner excludes protected windows before capture. Fresh matching desktop protection plans, exact display/window identities, geometry and unchanged-human-activity checks gate frame encoding. A protection change discards queued frames, updates the stream filter, and requires fresh proof before resuming. App switching does not retarget the display. Selected-window video reuses its existing preview stream; primary video adds one recording stream alongside the existing preview or recovery stream, never another helper. The encoder preserves its existing cursor/click presentation and idle speed-up, and holds only the latest accepted safe image through Stop. The local H.264 MP4 has no audio, microphone or camera input, no all-display scope, and is bounded to 24 hours and 256 MiB. An unavailable encoder, changed target, protected credential transition, incomplete protection or activity check, missing safe frame or finalization failure cannot produce an available-video claim.

The manifest and optional MP4 are owner-only local artifact files, separate from encrypted metadata history, and are bound to the exact current profile, account, tenant, workspace, chat and Computer Use run. Before asking the native runtime to start, HVAIA writes a deletion-blocking manifest containing only that ownership, requested scope/video state, content-free native-lifecycle and helper-handoff states, and a random process nonce in addition to the recording fields described above; both states and the nonce are never exported. At that pre-native reservation point, the manifest contains no settled turn, screenshot, video, page or accessibility content, typed text, key, coordinate, clipboard payload, path, URL, credential, or other captured app content; capture begins only after the reservation succeeds. If Start becomes uncertain, HVAIA may retain that content-free manifest solely to make cleanup safely retryable. A persistent content-free owner-only lock in the existing visual-artifact folder makes the recording-capacity check and reservation one local operation across backend instances; it contains no recording or identity data. If the backend restarts or native status is temporarily unavailable, HVAIA does not infer that capture stopped and does not mark the manifest interrupted merely because its process nonce changed. It keeps the recording visible and undeletable as possibly active until a complete response from the exact same native owner safely rebinds it. A bare not-found, not-active or unavailable error cannot confirm Stop. Only a complete exact-owner inactive status or Stop response, or a not-found/not-active result immediately following such a successful exact inactive status check, can prove native inactivity; an available helper MP4 must also be consumed or discarded and that cleanup fact durably saved before the manifest can become terminal. After an authenticated native Stop, the private manifest journal may retain its random Stop nonce, the native helper session, a finite terminal reason, the native completed-turn count, whether acknowledgement was attempted, and, for an available MP4, its exact helper path, byte size, duration, filesystem device/inode identities, SHA-256 digest, destination artifact identifier, disposition, random same-directory deletion-stage name and prepared/removing/staged/cleared transaction phase. The exact source is first preserved behind that staged name and flushed, then the original name is removed and flushed; the sole staged link is removed only after its receipt is durable. Ambiguous, changed or substituted source/stage state blocks recovery. Native status and its returned turn page are saved together atomically. Temporary recording manifests, task views and video publication files use exact reserved names in the same owner directory. On load, retry or recording/chat/profile cleanup, HVAIA validates and removes interrupted stages and task-view images that never entered the manifest, while preserving every declared image; unsafe filesystem substitutions block cleanup. A partial initial manifest stage can be removed because capture cannot start before that manifest is durably committed. If saving a cleanup fails after removing a file, HVAIA keeps only a temporary owner-directory retry marker in process memory until cleanup is confirmed; where directory flushes are supported, a new process verifies the owner directory on its first recording reconciliation, and no additional recovery file is created. This owner-only recovery metadata never enters a recording export, model context, log, support report or relay payload. The journal is cleared atomically after confirmed acknowledgement or when confirmed terminal publication requires none. An exact terminal pending receipt can treat an authenticated missing native session as retired only after a recorded prior acknowledgement attempt or a proved native-session replacement; while acknowledgement or safe handoff remains pending, it follows the manifest’s existing local retention and deletion-blocking rules. These files have no automatic expiry and remain until you delete the recording, delete its owning chat or profile, or use the applicable device-data reset. Direct recording deletion requires it to be stopped first. Chat, profile and device-data cleanup stop and fence an active or possibly active owned recording before deleting its files and fail closed without deleting the owner when native Stop or helper-output cleanup cannot be confirmed. JSON and MP4 export are separate explicit actions. An exported file is user-owned and follows the storage, sharing and deletion choices you make outside HVAIA.

Independently of that optional recording, an ordinary Computer Use tool result may keep a finite action_execution receipt in the existing encrypted local run ledger and may show it to the selected model. The receipt contains only bounded route, delivery, effect, evidence and escalation classifications or counts. It contains no app, page or user content, raw error, coordinate, text, path, URL, title, clipboard payload, credential or secret. It follows the existing ledger retention and deletion rules and creates no new storage root or recipient.

If an action may have happened but Computer Use cannot read the screen afterward, HVAIA gives Al-Jazari the classified read failure without adding a new screen image. Al-Jazari may try another permitted observation or write that the result remains unverified. Its model-authored report may describe app information it saw earlier; it can appear in the delegated task’s history and pass to the original chat and its selected model as the task result. That text follows the ordinary encrypted chat/run retention, deletion and authorized delivery rules for delegated work. This clarifies the existing model-authored result and chat boundary; it adds no new data category, recipient, storage root, retention period or raw screen pixels in the result. The new uncertainty marker’s payload contains only a fixed reason code, not the report or screen content; this path creates no separate recording, metadata-history copy, diagnostic-log field or support-report field. A support report you submit may include the published answer through its existing conversation snapshot. The public relay cannot read the chat content. This clarification does not independently advance this Privacy Policy version.

Encrypted metadata history is a separate optional setting that is off by default. When it is available and you enable it, HVAIA keeps only bounded action, app, outcome, timing and health metadata for the exact local HVAIA identity, for no more than 7 days or 100 MiB, whichever limit is reached first. Enabling or disabling the setting updates every active Computer Use task for that profile before HVAIA reports the save complete; later settled actions follow the new choice without requiring you to restart a task, and an unreadable setting fails closed as disabled. It contains no screenshots or video, page or accessibility content, typed content or other action inputs, clipboard payloads, paths, URLs, window or page titles, passwords, credentials, tokens, secrets or arbitrary error text. Its encryption key is available only through local HashiCorp Vault; HVAIA does not use Keychain or a plaintext fallback, and history fails closed when the required Vault state is unavailable. Before creating a history key, Vault records only fixed-size one-way profile and namespace identifiers so profile cleanup can find and destroy every owned key even when its ciphertext folder is missing; no raw profile identity or Computer Use content enters that index. Before a history event reaches encryption, HVAIA may keep one saturating dropped-event count and its latest fixed reason for that exact one-way namespace in current-process memory, so a full queue, stopped writer, invalid metadata or unavailable Vault is visible instead of silently losing the event. This health state has no action details, app identity, content, key material, path or arbitrary error; it is not written to disk, logged, included in support data, sent to a model or relay, and ends with the app process. A recovered writer can save later events while keeping that count visible for the current session. For an app-targeted event, the exact run worker may resolve its opaque app reference against only its provider-private registered-app table and transiently hand the result-correlated canonical identity and bounded app display name to the history writer. The writer derives a pseudonymous app digest with that namespace’s Vault-held key and encrypts the display name with the event; the canonical identity and opaque app reference are not stored. An explicit authenticated local query can return only that digest and display name so you can identify and search the app. Neither field is logged, sent to a model or relay, or included in support data. Missing, stale, forged or uncorrelated target facts omit app metadata instead of guessing it. Search and result filters are applied locally before bounded pagination, each query is explicitly requested and audited, and HVAIA returns no queried records unless its required audit entry is durably committed. You can delete this history directly, and deleting its owning profile or using the applicable HVAIA device-data reset destroys the matching keys before removing ciphertext and index records under the local-data reset contract.

When the encrypted history manager starts, it authenticates the retained records once and keeps only total ciphertext bytes, file count, expiration times and opaque filenames in process memory so a normal append does not repeatedly read prior history. It still rechecks current Vault authority before every append, and any uncertain write or deletion requires a verified rebuild before another append. No history index or database is added. Computer Use settings updates likewise merge only the choices you explicitly submit under the existing local transaction lock; omitted choices and app authorizations remain, and an incompatible recording/video choice changes neither the settings file nor native enablement. These reliability changes add no content category, recipient, durable history copy, or retention purpose, so Privacy Policy version 2026-09-privacy-v85 remains current.

Computer Use may read bounded clipboard text only after the task-scoped decision required by the current permission mode; HVAIA Mode can supply that decision for the exact authorized task. It may write text, images or checked file links. An omitted or explicit disposition intentionally leaves the new content. A temporary disposition first makes a complete bounded snapshot of the prior clipboard only in the exact task’s signed macOS helper memory, then holds HVAIA’s shared clipboard lane until that task stops or ends. The helper restores the snapshot only if the clipboard’s native change counter and exact item, type and value fingerprint still match HVAIA’s last temporary write; your change or another application’s change cancels restoration and is never overwritten. Repeated temporary writes keep the one original snapshot, while an explicit write supersedes it. An unreadable, changing or over-limit snapshot blocks the write before it starts. Normal task Stop/End and cooperative helper shutdown restore; an abrupt helper crash or forced kill cannot restore because HVAIA does not write recovery clipboard content to disk, so the temporary value may remain on the system clipboard. Temporary ownership does not enable a paste shortcut. Clipboard payloads are never included in Computer Use logs, model-visible receipts, action or video recording metadata, metadata history, support data or relay data. Clipboard payloads and snapshot fingerprints are never included in disk storage; snapshot fingerprints are also excluded from every preceding destination.

After the current permission mode authorizes the exact launch, HVAIA may ask one selected signed app to open one task-authorized checked document, up to four specified external HTTP(S) URLs, or an optional additional app instance. The model supplies only the checked document’s opaque task reference, never a raw filesystem path; HVAIA resolves and rechecks that grant privately, and the selected app necessarily receives the document and can process or retain it under that app’s own practices. For an external URL, the selected app and the specified HTTP(S) service may receive the complete URL, including any query values, together with ordinary network metadata. The confirmation shows only the normalized scheme, host, port and path. Query values and fragments are excluded from HVAIA’s Computer Use approval presentation, operational logs, action_execution evidence, action/step recording metadata and encrypted metadata history; URL fragments are rejected before launch. The URL list is bounded and rejects user information, local or private-network targets, non-HTTP(S) schemes and remote-debugging-style flags. HVAIA does not claim that a redirect was safe or that a document or URL was delivered merely because the operating system acknowledged the launch, and it does not repeat a launch whose dispatch may already have occurred.

Immediately before a macOS URL launch, HVAIA resolves every distinct hostname across IPv4 and IPv6 under one shared two-second deadline and launches nothing if resolution fails, times out, is cancelled, is incomplete, returns no address, or includes any local or private address, including a mixed public/private answer or a private IPv4 address represented as IPv6. HVAIA then rechecks the selected signed app, checked document, URLs and cancellation before dispatch. This is validation at launch time only: after the original URL is handed to the selected external app, that app controls later DNS lookups and redirects, so HVAIA does not claim protection against address changes or redirection after handoff. The check adds no stored hostname, address history, log field, recipient, or retention period, so Privacy Policy version 2026-09-privacy-v85 remains current.

HVAIA may perform ordinary supported work in System Settings, including supported privacy and security settings, under the current permission mode. Operating-system authentication, administrator approval, security-agent interfaces, credential reveal or export, and security bypasses remain blocked. Computer Use may operate HVAIA’s own ordinary interface only when a structured tool cannot complete the task; it cannot approve itself, change its own permission mode, increase its authority, expose secrets, or operate protected approval, security or reset controls. To carry that exact failure into the delegated Operator, the local backend keeps a content-free receipt containing bounded owner, run, call, generation, status and time metadata in process memory for no more than 60 seconds; it is not stored, logged, relayed or sent to a model provider, and is cleared on profile release, sign-out or shutdown. Password-manager work is limited to separately qualified protected autofill routes. Unlock, ambiguous account selection, MFA and unsupported routes return control to you, and secrets remain outside model requests, chat, recordings, clipboard history and action history.

Structured browser work remains owned by Ibn Battuta in HVAIA’s in-app browser or by the selected connected regular Chrome profile. HVAIA does not add alternate or disposable Chrome profiles, Safari or Firefox Computer Use providers. Browser actions retain fresh document and element proofs, the current permission mode and per-tab serialization. Websites and Chrome retain their own data practices and operating-system-visible behavior as described elsewhere in this policy.

During an authorized Computer Use run, HVAIA may temporarily ask an Electron or Chromium app to expose its macOS accessibility tree. HVAIA still restricts the resulting controls to the selected authorized window and its existing control-count, nesting, text, protected-field and screenshot bounds. Those controls may reach only the model recipient already selected for that task through the existing temporary observation lifecycle. Enabling the tree can affect the target app’s performance and can make the tree available to other software you have already trusted through macOS Accessibility permissions. HVAIA restores only projection settings it changed when the run ends normally, you press Stop, the owned helper is torn down, or the target app exits. An uncatchable helper or operating-system termination can prevent restoration until the target app exits. HVAIA adds no activation journal, app-content store, telemetry, support payload, or durable screenshot store for this feature, and previous privacy acceptance is not upgraded automatically.

When your task authorizes terminal work, HVAIA may type commands and interact with the terminal through its existing app-scoped Computer Use controls and your current permission mode. Visible commands, output and file paths may reach your selected model in ordinary selected-window observations. Terminal output is ordinary screen content: sensitive text printed there is not necessarily identifiable as a protected password field. Existing native protected-field masking still applies. The separate live preview stays local and temporary; explicit Save evidence can retain the selected image, and model-written summaries can remain in ordinary chat history. Terminal support itself adds no terminal log, recording service, storage root, retention period or relay-readable content path; if you separately enable the v78 recording options, the action/step or protected-video rules above apply to terminal work too. The terminal app may keep its own history, and commands may create files or contact services under that shell’s existing operating-system permissions. App authorization is not a shell sandbox. Stop ends further HVAIA input and capture, but cannot undo or guarantee termination of a command already submitted to another app. HVAIA does not adopt or erase that app’s history or command-created files at Stop. Password-manager and OS-security surfaces remain blocked; saved-password entry still requires a separately verified terminal-free receiver. Previous privacy acceptance is not upgraded automatically.

Saved logins offers to remember passwords in the Chats in-app browser after a qualified human sign-in submission. Before you choose Save or Update, the private browser/native boundary temporarily holds the submitted username and password in memory, with at most one candidate per tab for no more than sixty seconds. The candidate is discarded on dismissal, expiry, unrelated navigation, tab closure, profile loss or browser-host replacement. Its own sign-in redirects can retain it under the original receiving website or identity provider; an SSO destination does not become its owner. Temporary capture does not write a password to Vault before your decision and does not establish whether sign-in succeeded. Before enabling a qualified sign-in watcher, HVAIA may save or reuse destination-only protection metadata in Vault and a content-free local recovery obligation, so conflicting native screen capture is stopped before entry. This metadata contains no submitted username or password. For a human-selected saved-login fill, HVAIA clears its temporary Needs attention marker when the fill is known not to have started; an uncertain fill keeps the marker for recovery. After a Save write has been attempted, HVAIA may retain bounded private operation metadata to verify an uncertain outcome without retaining or resubmitting the temporary candidate. This behavior requires acceptance of this version; earlier acceptance does not enable it.

Browser settings’ Offer to save and fill choice starts on and is stored with the profile’s other non-secret Browser preferences. When it is off, the in-app browser offers no Save or Update and does not suggest saved passwords, Contact info or payment methods for your own filling. A candidate that the qualified sign-in watcher already captured is discarded at the next check without being offered or written to Vault, and an offer that was open when you turned the choice off is withdrawn. Sign-in watcher protection, saved records, and sign-in that you authorize for an HVAIA task are unchanged. A paired iPhone can show and change this choice through the encrypted Settings broker; only the on/off value and its settings revision cross that connection.

Sign in automatically starts off. When you turn it on, and a verified sign-in form in the in-app browser matches exactly one saved login, HVAIA fills that saved username and password from Vault and submits the form once for you, without a separate click. Google sign-in and ambiguous forms stay manual. HVAIA keeps only an in-memory note of the saved login it tried, for 15 minutes, so a rejected password is not retried automatically; the note contains no username or password and is discarded when the app quits. Submitting does not prove that sign-in worked; the website decides. Upgrade to passkeys automatically is not available yet; HVAIA stores no passkeys, and passkeys you create stay with your passkey provider.

Choosing Save stores the submitted credentials only in local HashiCorp Vault, bound to your exact profile/account/tenant/workspace and qualified receiving website. In Browser settings, you can also choose Add for a currently qualified sign-in destination and enter a username and password in the protected native window before signing in. HVAIA saves the exact details you enter without testing whether the destination will accept them; the destination decides that when you sign in. The general interface sees only the destination, account nickname and safe result, never those values. You may choose an account nickname; otherwise HVAIA uses a numbered account label. A different username is a separate account, and replacing a saved password requires your explicit Update decision. A human selection of a saved account fills the qualified fields for you to submit. Settings lists saved accounts, lets you update an existing saved copy through a protected native entry window, and offers individual and bulk deletion; deleting saved passwords does not clear browser sessions or site data. In the Mac app, Reveal password first asks macOS to confirm you are the device owner for that exact saved login and version, then shows the password briefly in a native protected window. HVAIA pauses its own screen capture while that window is open, and the window closes when you finish, the confirmation expires or the profile changes. The password is read from Vault only after that confirmation and is never returned to the general interface, a backend response, logs, a model or a paired iPhone. HVAIA does not offer copying a saved password, so it never places one on your clipboard. Existing saved credentials for ordinary Chrome and native apps retain their authorized execution and deletion paths. Automatic capture outside the in-app browser and passkey storage are not part of this feature.

HVAIA’s interface and model-facing tools receive only account labels, opaque references and safe status from this private credential path. Credential values are excluded from HVAIA model requests, chat history, ordinary tool traffic, logs, support bundles and renderer storage. When you open Password manager on a paired iPhone, the paired desktop sends only saved-login account and website labels, record versions and safe status through the existing end-to-end encrypted Settings connection. The separate username and password fields are not sent to the phone. An account nickname is shown as you entered it and can itself contain personal information; use a neutral nickname if you prefer. The list remains in phone memory for that Settings session, is cleared when the pairing or profile changes, and is marked stale while offline. A confirmed, exact-record password deletion can be requested from the paired iPhone as described above; private-value actions remain on the desktop. HVAIA does not import credentials from chat, screenshots, browser password stores or other password managers, does not use the clipboard to transport them, and keeps Chromium’s separate password storage disabled.

Local Vault recovery uses a dedicated authentication role inside your existing local Vault. HVAIA derives its authentication secret in privileged process memory from the operating-system-protected unseal key; it is registered only with local Vault and is never written to configuration, logs, chat, model requests, or additional operating-system credential entries. Recovery tokens are restricted to loopback, expire within sixty seconds, and are explicitly revoked after use. The ordinary app token receives no administrative permission. This adds no external recipient or new data directory. HVAIA does not enable unauthenticated recovery or reset an existing Vault when authentication is unavailable.

Before initializing a newly created HVAIA-managed Vault, HVAIA writes one owner-only, non-secret bootstrap receipt beside its data directory. Its version-2 contents include only schema/state, a random transaction identifier, one-way runtime and canonical directory-path identifiers, directory device/inode, a transaction-derived quarantine name while an interrupted rename is pending, and, on macOS, a one-way identifier derived from the persistent disk-volume UUID. It contains no raw path or volume UUID, key, token, credential, profile identifier, or user content. A completed macOS receipt uses the path, inode and volume identifier across normal reboots, while an active initialization or interrupted quarantine still requires the exact current device/inode. It remains unpublished until recovery login, scoped-token validation, readiness, and verified root-token revocation succeed, then is retained as ready. An existing version-1 completed receipt is upgraded only after HVAIA authenticates the exact initialized, HVAIA-owned Vault with the operating-system-protected bootstrap material, revokes the temporary authentication grant, and revalidates the receipt and directory. This upgrade does not initialize, quarantine or replace data and does not rotate credentials; pre-publication failure preserves the original receipt, atomic publication leaves either intact version 1 or fully written version 2, and every failure preserves the Vault data. After interruption, only an intact receipt matching that exact never-admitted directory permits HVAIA to stop its own Vault process and quarantine the directory before retrying. Missing, corrupt, mismatched, completed, external, or already initialized stores are preserved for explicit recovery. This content-free local safety proof adds no storage root, external recipient, user-content category, or new purpose, so Privacy Policy version 2026-09-privacy-v85 remains current.

Saved use requires a fresh, qualified receiver and authentication flow. In Control asks you to confirm sign-in; HITL and HVAIA Mode permit an unambiguous enrolled account for an already-authorized task. Background tasks keep their own exact owner and permission mode even when another profile is foreground. Account enrollment, adding a destination, ambiguous account choices and uncertain password-change recovery remain human decisions. In Control and HITL require separate consent for supported password changes; HVAIA Mode can supply that consent for the exact account through its current native run authority. MFA, CAPTCHA and other human challenges are handed back to you securely.

When a task first needs password changes for a qualified service, enrollment requires a separate native confirmation at the point of use and fresh task authority afterward. Background work needing new enrollment waits for your attention. HVAIA verifies the saved account through a private HTTPS connection to the exact approved service and stores its service binding in Vault. The service receives the current credential during that verification. Each later password change uses the selected mode’s consent requirements; HVAIA sends the current and generated candidate passwords only through that private native connection. A temporary service session stays in native process memory and is not shared with your browser, model, chat, ordinary tool traffic or logs. Only a qualified independent check of the exact account can establish that the candidate works. Unsupported service versions or authentication flows return a limitation before a remote change.

For supported saved use, credential values travel only through Vault, HVAIA’s native authority, the minimum private browser or native input component, and the destination you approved. The receiving app or website necessarily receives the password. This protection covers HVAIA-controlled data paths; it assumes the native host and receiving destination behave honestly. It does not protect against a compromised destination, a privileged extension, an administrator, an independent screen recorder or software with equivalent operating-system access. HVAIA’s full-user terminal is not an operating-system security sandbox. Browser isolation and screenshot masking do not make a malicious receiving site safe.

For the qualified in-app flow, HVAIA blocks observation during private password entry and unresolved dispatch. Once native checks establish a subsequent document or a verified same-document transition out of password entry, the already-authorized task may automatically resume ordinary redacted browser observation without another handoff click. Authenticated page content may then reach the local or hosted model selected for that task under the same provider terms as ordinary browser observations. Native authority binds this access to the current owner, task, tab, document and permitted destination; it neither proves successful authentication nor approves further actions. MFA, CAPTCHA, failed authentication and additional permissions retain their existing human-input and approval rules. Declining Save does not prevent this continuation. Raw script evaluation, network inspection, unrelated native screen capture, and legacy or unresolved exposures remain restricted. Acceptance of this version is required before enabling automatic access to authenticated pages.

HVAIA pauses and drains its affected capture paths before private entry and keeps affected contexts protected afterward, including related same-origin contexts and restored sessions. Clearing a field or changing a page URL alone does not make observation safe. A context may remain unavailable for screenshots or arbitrary page inspection until qualified cleanup is established. Regular Chrome may request an optional debugging permission to verify the current document’s connection security. Chrome’s debugging transport can transiently deliver sensitive network fields to the private extension worker; the verifier does not inspect, retain or forward request bodies, headers or cookies. It uses only the necessary connection and document facts, and waits for its network monitors to stop before requesting and entering a saved credential. Known protected contexts cannot restart that monitoring to recover missing connection evidence; HVAIA instead offers manual sign-in. This does not promise erasure from Chrome-owned or JavaScript memory, or that unrelated-context verification receives no transient sensitive fields. Authentication request bodies and credential values are excluded from this monitor’s model traffic, chat, tool transcripts, screenshots and logs.

The in-app browser retains a content-free qualification marker when HVAIA has run arbitrary page scripts, changed network handling, or restored browsing state whose prior handling cannot be established. It contains only a profile digest, schema and safe status, never script text, website addresses or credentials. This marker survives browser restart and ordinary local reset, and can prevent saved use when earlier scripts might have retained access to the receiving page. Ordinary browsing remains available. When that marker blocks saved-login capture, HVAIA reads it locally and shows a finite recovery status in the Chats browser and Settings → Browser. The blocked offer returns no password candidate or saved-account details, and the mounted Browser view pauses repeated offer checks; reopening it or changing its tab or host makes one fresh check. This adds no new stored content, model or external recipient, public-relay data, or retention period; resetting the affected browser profile still requires your separate native confirmation.

Supported browser recovery requires a separate native confirmation before resetting the in-app browser for the selected HVAIA profile. It closes that profile’s in-app tabs and removes their site sessions, site data and encrypted browser continuity data. Saved credentials remain in Vault. Other HVAIA profiles and regular Chrome are outside this reset. Content-free reset records preserve the pending restriction across interruptions; version-bound cleanup receipts in Vault allow observation protection to retire only after HVAIA verifies the affected context was replaced safely. Another protected account or browser context on the same origin keeps its protection. A timeout or an unavailable browser is not proof of cleanup.

Browser recovery also retains local ownership records containing opaque browser/session identifiers, profile digests, process creation and operating-system boot identity where applicable, and verified exit status. These records survive ordinary local reset and contain no website addresses, usernames or passwords. They let HVAIA distinguish the actual browser that received a credential from an unrelated or replacement process. When only its native controller restarts, the Electron browser retains its existing sessions and protection while HVAIA reestablishes the private connection. Missing or uncertain ownership proof keeps the affected recovery pending.

Saved passwords are retained in Vault until you delete them or remove their owning profile. During a password change, Vault temporarily retains the current and candidate passwords so an interruption does not lose the recoverable value. HVAIA does not repeat an uncertain remote change, assume a timeout means failure, or automatically restore an old remote password. Unresolved candidates remain until reconciliation or your explicit authorization to destroy recovery material. Superseded secret versions are permanently destroyed after verified promotion and cleanup. If removal of obsolete copies is interrupted, saved use stays blocked until Vault confirms cleanup. Recover retries that local cleanup without changing the destination password. A non-secret version cutoff stays in the Vault record until deletion so HVAIA can verify that obsolete copies are gone after a restart. Deletion remains pending if Vault cannot confirm it.

Revoking saved use stops future credential entry. A small native revocation or profile-removal journal contains only opaque owner/account and operation identifiers, versions and safe status, allowing the restriction to survive Vault outages and restarts. Content-free native records also identify the exposure restrictions that must be restored from Vault. On a previously exposed installation, HVAIA withholds observations during startup until it can restore every recorded protected context; a Vault outage or missing recovery record keeps that protection in place. These records survive ordinary local reset and contain only opaque record references and safe status, never destinations or credential values. Repeated use can reuse existing protection metadata after HVAIA verifies the exact owner and destination again in Vault; the observation restrictions remain in place. Regular Chrome applies these restrictions to the actual selected tab regardless of how it was selected. Toolbar capture obtains current native protection before reading a page, including after the extension restarts. Independent protected-context metadata may remain until safe observation is established; deleting the saved password does not prove that a receiving page has forgotten it. Saved-password deletion does not sign out existing browser or app sessions, change the remote password, delete the remote account, or erase external backups. Saved-login values are not exported or synchronized to paired devices or the public relay.

When you explicitly enable HVAIA mode, its full-access choice also covers Computer Use app-access and action-confirmation prompts for that task. HVAIA uses the same exact native checks and temporary task-scoped app access without asking you to approve each click; it does not create an Always-allow grant. Guarded mode retains individual prompts. OS permissions, protected-content masking, checked-file authority and Stop still apply. A step that requires your actual input, including an unenrolled password or unsupported saved-login flow, remains a handoff and is never recorded as completed automatically. This corrects Computer Use to honor the existing full-access mode; the separate Saved logins choice and data boundaries are described above.

During native macOS actions, HVAIA has its own visible cursor without moving, hiding, capturing, restoring or suppressing your pointer. It prefers supported background actions, including a coordinate click whose point is freshly exposed and owned by the exact authorized window, and can bring that exact window forward before input when required; it does not restore focus over a later choice you make. On a supported macOS version, ordinary key and text input may be sent directly to the exact authorized app without bringing it forward only after HVAIA proves the current app process, selected window, nonsecure focused control and private operating-system delivery capability. HVAIA repeats those target checks for each key or text chunk. If the capability or proof is unavailable on a supported macOS version, HVAIA uses protected foreground focus before input. It never switches delivery routes or repeats the action after an event may have been sent. This is not a second independent keyboard, and an operating-system delivery receipt is not proof that the app completed the requested effect. Some native hover-revealed controls, drags that require shared mouse-button state and native drag-and-drop remain compatibility limitations. macOS may also deliver a related movement notification to another window of the same app under your pointer; this does not authorize redirected clicks, scrolling, dragging or cleanup. These route choices send the same requested input to the same selected app and add no data category, storage, external recipient or retention boundary, so Privacy Policy version 2026-09-privacy-v85 remains current. HVAIA does not silently use your pointer as a fallback or treat a posted event as a completed task.

For supported sliders and steppers in an authorized app, HVAIA can request one observed increase or decrease action and inspect the resulting value. The selected direction passes through the existing model tool request, local native authority and any required confirmation, with the same task history, retention and deletion rules as other Computer Use actions. This uses controls already included in the selected-window observation and adds no capture surface, content category, storage root or recipient. The app’s protected controls and HVAIA’s existing permission checks still apply.

Al-Jazari’s shared cursor artwork points upper-left and includes a dark keyline and restrained static lavender halo inside its existing 56-point footprint. It uses already-validated target geometry and accepts no input or focus. After the first exact selected-window preview binding, HVAIA derives one starting point from the center of that window’s uniquely largest-intersecting display and clamps it so the full footprint remains inside the display and window. It keeps only the latest point in temporary memory for the active run. Display-only travel lasts from 180 to 450 milliseconds according to distance and becomes immediate with Reduce Motion. Logical travel may continue while native pixels are covered, but HVAIA never saves or replays the hidden path. Ordinary mouse movement and unrelated-app input do not remove the marker. Relevant conflicting or unidentifiable input, Stop, invalidation, loss of authority and task end retain their safety effects. The marker is excluded from HVAIA’s app screenshots. Bounded native window geometry is used to clip it around covering windows. To distinguish one inert full-display Dock backing surface from real covering UI, native presentation may perform five bounded system-wide accessibility hits over the prospective visible cursor footprint after freshly validating the live Apple Dock signature and process instance. An unrelated hit exposes only its process identifier for comparison and none of its attributes; selected-app hits use only the exact top-level and window relationships for the already authorized selected window. HVAIA does not read labels, values, titles, screenshots or unrelated relationships for this proof. The four added footprint witnesses, raw WindowServer stack, process births, signature result and lease remain temporary helper memory and never enter model context, helper output, logs, diagnostics, support data, storage, telemetry, a paired device or the relay; the already-disclosed cursor hotspot retains only its existing normalized cursor-notice path described below. Failure hides only the native marker while the independently protected preview remains available and retries do not repeat the action. This masking is not atomically synchronized with macOS window changes and cannot promise zero transient stale pixels. The starting point, run-scoped latest point, motion timing and artwork did not independently change then-current Privacy Policy version 2026-09-privacy-v77 or its consent record. This cursor-only presentation change does not itself change the current policy version or consent record; the later v78 change is the separate Computer Use expansion described above.

The current cursor presentation uses the separately supplied assets/cursor.png artwork with a corrected normalized tip hotspot. Its native and browser footprint is 28 points and its in-app preview footprint is 14 points. When Reduce Motion is off, the visible artwork gently rotates around its geometric center through a 1.2-second cycle bounded to 15 degrees in either direction; Reduce Motion keeps it unrotated. The tip hotspot continues to hold the exact target point while only the artwork pivots. This local display-only effect does not move its logical point, produce input, add cursor history or evidence, or change any collection, storage, sharing, retention, deletion, encryption or exposure boundary. It therefore does not independently change Privacy Policy version 2026-09-privacy-v85 or accept consent on your behalf.

To show that movement in the existing preview, HVAIA passes one latest normalized cursor position and opaque request, observation, stable run owner, stream and generation/sequence identifiers through its private native helper, local authority, backend and authenticated local Desktop snapshot. A private movement phase remains inside the native-to-Rust presentation lane and is not added to the public cursor snapshot. This is temporary process memory only, scoped to the active profile/account/tenant/workspace, chat and run. The latest point can begin with the locally derived safe position before the first mutation and is replaced in place as Al-Jazari moves. It is not a history of your cursor or activity and adds no capture loop, waypoint list, file, cache, storage root or external recipient. Cursor coordinates and these private progress records are excluded from model requests and output, durable chat and event history, logs, diagnostics, support data, telemetry, the public relay and paired devices. A settled command accepts only its exact parked point or invalidation; when no matching preview geometry existed as the seed parked, one first later parked projection may establish that point. Late movement cannot revive or move it. Missing or mismatched preview pixels, Stop, lock, owner change, native connection loss and task end clear the feedback and latest point. Cursor-only updates do not fetch another image. The document viewer and Save evidence continue to use the exact selected PNG, without drawing the cursor into it. The original local temporary cursor-feedback path required renewed acceptance in Privacy Policy v75. This run-scoped latest-only extension added no new data or retention boundary and therefore did not independently advance the then-current v77 policy or accept consent on your behalf.

The bounded accessibility view includes ordinary controls nested within the selected authorized window. It shares the security scan’s nesting limit while keeping the same limits on control count and text size. Deeper valid controls receive the same complete protection checks, and cyclic control relationships are refused. HVAIA may identify whether an enabled, nonsecure, classified control currently supports explicit focus or direct text-value entry; unsupported, disabled, protected, ambiguous and truncated controls receive no such capability. HVAIA may reconcile repeated references to one focused control and its non-activating containers only when native identity, window ancestry and matching control facts prove the same target. Protected content remains masked, and a missing or ambiguous focused control does not authorize keyboard input. This correction uses the existing selected-model recipient and temporary observation lifecycle; it adds no capture surface, content category, storage or retention period.

Within that same bounded view, HVAIA allocates text for the retained controls before optional values. A control’s role, safety-bearing label, available actions and explicit focus/value capabilities are kept together so earlier text does not hide or partially publish a later control’s authority. If that complete bounded description does not fit, HVAIA reports truncation and keeps the control unclassified. This uses information already read from the authorized app, keeps the same overall text limit, and adds no content category, recipient or retention period.

An ordinary app may expose a toolbar button whose optional accessibility subtype cannot be read. That uncertain control remains masked and cannot be targeted. When complete current checks establish that these isolated toolbar buttons are the only protection uncertainty, HVAIA may press a separately verified ordinary button outside their masked bounds. Actual protected content, uncertain text fields, keyboard and coordinate input retain their existing restrictions. The native helper remembers only the protection classification of those already-tracked controls in the existing temporary, task-scoped protection state; a previously stronger protection cannot be downgraded to this exception. Additional checks read only the same authorized app’s control-type and protection metadata, not field contents. This adds no unmasked content, recipient, storage root, durable record or retention period, and does not change the v75 consent boundary.

Computer Use failure diagnostics use fixed, content-free labels to distinguish accessibility projection activation or restoration, accessibility/security-check limits, masking, capture, encoding and temporary-file validation failures, as well as which accessibility-window, capture-window, window identity, geometry or focus check failed. They never include control values, window titles, process identifiers, coordinates, app names, file paths, raw native error text or screenshots. These labels use the existing bounded diagnostic and task-event lifecycle; they add no content log, storage root or recipient.

For a live-preview interruption, the same local diagnostic category may retain fixed capture-stage, availability, failure and recovery labels with ordering, repetition and loss counters. The native owner keeps at most eight coalesced records in temporary memory. An authenticated local preview read may copy a bounded projection to the existing owner-scoped task diagnostic journal, with at most 64 records and one truncation marker per Computer run. The journal keeps its existing configured retention, 90 days by default, and is removed by the existing chat, profile or device-data deletion flow. These records contain no cursor position or progress identity, screenshot, app/window/frame identity, native stream identifier, coordinates, typed value, file path, secret or raw exception. No new recording, storage root, recipient, telemetry or automatic support-report submission is added by these diagnostics. If the preview is closed and HVAIA restarts before another preview read, the temporary native diagnosis can be lost. This uses the existing content-free diagnostic category and retention/deletion boundary and did not independently change then-current Privacy Policy version 2026-09-privacy-v77 or accept consent on your behalf.

For an attempted accessibility button press, a fixed label may distinguish an unsupported action, an incomplete native response, an invalid control reference or an unimplemented native API. It uses the result already returned by that one action, not another read or input attempt. These labels do not establish whether the action took effect or authorize replay. They follow the same diagnostic lifecycle, with no new user-content category, recipient, storage, retention period or renewed-consent boundary.

If a Computer task is interrupted before it can verify an action, its existing result may retain a fixed label for the initiating request, account, connection, timeout, service, response or tool-correlation failure. HVAIA does not copy the exception message, request or response body, website address or credentials into this diagnostic. The label survives in the existing private local run record and delegated result packet so the exact source run’s selected model provider receives the initiating cause after an interruption. A later recovery failure cannot replace it. Cancellation removes the optional cause, and content-free activity, Gateway/public-relay projections, logs, support data and telemetry exclude it. The label follows the same task-result retention and deletion rules, does not certify or repeat the action, and adds no content category, storage root, external recipient or renewed-consent boundary.

To recognize repeated Computer observations, HVAIA compares the already-authorized bounded control information, including explicit focus/value capabilities, in temporary process memory. Between results it keeps only private digests, bounded counts and generations, and fixed recovery facts in bounded task and scope tables, rather than another copy of the controls’ text or images. New frame identifiers alone do not count as progress, and a successful observation does not prove keyboard input is available. Direct value entry can verify that alternative entry route but does not certify keyboard-focus repair. If a task ends with a recovery episode still unresolved, HVAIA records that content-free outcome as unverified rather than treating the assistant’s final text as proof of recovery. These comparison digests and normalized control information are not saved to disk, included in model recovery guidance, logged, or shared with support, telemetry, paired devices or the public relay. Eviction or app-process exit removes them. This uses the existing observation content and recipients and adds no capture, storage root, retention class or recipient.

The local Computer controller distinguishes a timed-out operation from your request to stop. It retains only that fixed cause in its existing temporary run-lifecycle record while disabling input and clearing the matching preview; the status watcher does not turn the timeout into a user cancellation. Existing operation receipts remain intact, and no action is repeated. This adds no user content, storage root, recipient, retention period or renewed-consent boundary.

A recognized Computer diagnostic label may also accompany its pending approval, restored approval checkpoint and existing approval event so the reason remains available while the task waits. Only the fixed label is carried; it grants no permission, changes no action or handoff, and follows the existing approval and task-event retention and deletion rules. This preservation adds no user-content category, recipient, storage root or renewed-consent boundary.

If a task’s permission mode changes and HVAIA refuses an action before starting it, the existing tool result may retain fixed, content-free labels confirming that dispatch did not start. These executor-verified labels contain no action content or coordinates, follow the existing tool-result retention and deletion rules, and grant no permission to retry. This adds no data category, recipient, storage root or renewed-consent boundary.

If an ordinary keyboard action has no safely resolved focused control, HVAIA refuses that input before dispatch and lets the agent try a safe observed control and check the state again. It does not record a human step as completed. Guarded-mode confirmations and genuinely human-only handoffs remain in effect. A temporary native focus-check label is exposed only for its corresponding refusal; it may distinguish unavailable, empty or conflicting child relationships in an ancestor or the selected window using facts already read. Overlap diagnostics disclose whether a cover belongs to the selected app, HVAIA itself, another app’s normal or elevated surface, or cannot be resolved. The HVAIA comparison uses the helper parent’s already-validated process identifier only in private helper memory. If a desktop-backing check fails, a fixed label may also identify its signing, time-budget, native-hit or window-relationship stage, using facts already read for that check and no underlying signer value. These fixed facts add no native query, contain no process or window identifiers, titles, coordinates or content and retain the same diagnostic lifecycle.

When an app omits an optional focus attribute, HVAIA may resolve one uniquely verified control from its existing authorized native observation. The proof stays in memory and checks the selected window, current focus flags, control identity and ancestry. It uses bounded native child-array reads and rejects incomplete or truncated relationships. It does not bring a background app forward merely to observe it, and actual keyboard input still requires a fresh match with the system’s focused control. This uses the existing observation and diagnostic data boundaries, with no new content storage, transmission, recipient or retention category.

If native parent links insert an intermediate container omitted from the child hierarchy, HVAIA can reconcile it only when complete child lists prove the same single control and bounded native checks prove that the intermediate is nonsecure, nonactivating and bound to the selected window. Those additional action and window-relationship checks read no labels, values or screenshots. The proof remains private in memory for the existing observation lifetime and is checked again both when resolving focus and immediately before each key or text chunk. It is not serialized or sent to a model, and adds no public authority field, storage, recipient or retention category. Other branches or missing evidence keep the action blocked.

Some apps report their text area as focused and focusable without providing an enabled flag. HVAIA may use bounded control-metadata checks to verify that exact nonsecure keyboard recipient and its window relationships, then report it as interactive in the existing observation. Explicitly disabled controls and failed or ambiguous checks cannot qualify through this path. The private proof is checked again before each key or text chunk; it does not enable pointer actions or direct accessibility value changes. Focusability-specific queries read only whether the control is enabled, focused and focusable; ordinary identity checks still use the existing authorized control information. This adds no content category, storage, transmission, recipient or retention period beyond the then-current v77 boundaries.

Before a coordinate action, HVAIA checks whether another window covers the selected app. A narrow check for macOS Dock backing uses verified live app signing and an operating-system accessibility hit at the requested point. It compares only process ownership and, for the already-authorized app, native window identity. An unrelated hit supplies only its process identifier for comparison; HVAIA does not read its text, values or control relationships. This proof stays in memory for the action and is not logged, saved, sent to the model or shared. It adds no content category, recipient, storage root or retention period. Missing or conflicting proof blocks the action.

On supported macOS systems, Computer Use continuously captures only the task’s exact authorized app window unless you explicitly choose the whole-primary-desktop scope. macOS supplies a native sharing badge and menu-bar preview. The operating system renders that preview itself, so HVAIA cannot promise that the macOS thumbnail uses HVAIA’s masking of protected fields. Audio, microphone and camera capture are disabled. Ordinary live presentation produces no recording output; the separate protected-video option described above is off by default and cannot be enabled unless action/step recording is also enabled. The selected content cannot be broadened through the native sharing picker. macOS Stop Sharing closes input admission, releases held input, and cancels the owning Computer Use task; explicit Stop does not restart capture.

HVAIA’s floating Current screen preview uses a separate protected live feed, capped at five updates per second with a two-frame native capture queue. Each published frame passes fresh target identity, geometry, and protected-field checks around that sample; unavailable protection clears the HVAIA preview. These frames travel through private native channels and an authenticated, unlocked local Desktop profile/account/tenant/workspace/chat/run boundary. Bounded PNG bytes and opaque stream/frame identifiers, sequence, dimensions, and capture time use no-cache responses. Outside a separately enabled protected-video recording, live frames stay only in temporary local memory; they are not recorded or added to model context, events, chat history, logs, support data, another device, or the relay. They are separate from the agent’s two working screenshots. The in-app and detached preview show only the task you select; switching presentation changes no task’s authority or lifecycle.

HVAIA keeps only the current and previous delivered live frames for each active preview consumer, with at most four consumers and 30-second expiry for abandoned consumers. Clicking Save or the viewer icon selects the exact displayed frame, with at most one temporary selection per consumer that expires after 30 seconds. The document viewer opens that still while the PiP keeps updating; opening the viewer does not save an image. Detached chat windows route an opaque selection reference to the main window and do not put pixels in cross-window events. Save evidence makes only the explicitly selected frame durable through the existing evidence lifecycle; a missing or expired selection fails rather than saving another image. Completing or cancelling selection releases its pin. Closing or replacing a view releases its temporary image URL. Changing owner or selected target, locking, stopping, losing authority or the native connection, or ending the task clears live frames and selected stills. This feed adds no disk cache or storage root.

Computer Use retains only the current and previous working screenshots in the active provider input history as well as in its temporary frame store. User attachments and explicitly saved evidence keep their existing lifecycles. For Computer-enabled ChatGPT work, HVAIA sends the request directly through its own in-memory transport to the same OpenAI subscription service using the existing Vault-held account credentials. Each request contains the ordered context and only the two retained Computer frames; already-issued actions are not repeated. Computer screenshots and accessibility content do not pass through the local Codex app-server’s diagnostic logging or database. The pinned runtime may supply content-free model capabilities; a missing selected model may use one bounded authenticated model-catalog read from OpenAI, without sending chat content or storing the catalog. This bounds HVAIA’s active input context and does not promise retroactive deletion under a hosted model provider’s own retention policies. Secondary specialist recall records keep Computer Use operation names, ordered tool-call identities, and bounded outcome metadata while removing private argument/result bodies. Existing affected fields are cleaned atomically within the same owner/chat ledger without an old-content backup; unsafe or ambiguous storage blocks recall until cleanup succeeds. Content-free locks and sanitized temporary replacement files use that same local ledger root and its existing deletion/reset boundary.

Supported work beside protected fields uses private, bounded control identities, ancestry, masking geometry and native control relationships. HVAIA does not read password values to determine whether they are filled. The narrow submit_existing_login action activates an already-existing verified submit control once, after confirmation for each attempt. In a supported website, the existing Chrome connection binds the selected browser profile/session, exact tab/document/frame, HTTPS origin, form and submit control; it rechecks those bindings in the document before activation. Native applications without sufficient authentication/control evidence and ambiguous custom forms remain unavailable through this method. The application or website handles its existing credentials under its own policies. This feature creates no credential store, password import, password reveal/change, automatic MFA or passkey handling, or automatic replay after uncertainty. It observes the result separately before reporting success.

Supported choose_file flows use only the task’s existing checked-file authority and exact source revision. HVAIA revalidates that authority and the destination app/window before selecting the original durable file or an explicitly created faithful export through a supported panel. The destination application receives the selected file through its ordinary import/upload flow; its own storage and service policies apply. Original files are preserved, selection is separate from acceptance verification, and ambiguous or unbound panels return a limitation. No ambient clipboard service, generic cross-app drag, silent conversion or additional copy store is introduced. A bounded Computer Use clipboard read may return text only after one task-scoped decision in guarded modes or under your HVAIA Mode choice. Clipboard writes may carry text, images or checked file links. An omitted/explicit write intentionally persists. A temporary write holds the serialized clipboard lane and keeps its complete bounded prior snapshot only in the exact signed helper’s memory. Stop, End or cooperative helper shutdown restores only while the native change counter and exact item/type/value fingerprint still prove HVAIA owns the current value; any intervening change cancels restoration, and explicit writes supersede it. A forced helper termination can leave the temporary value because no recovery copy is stored. Temporary ownership grants no paste shortcut. Clipboard payloads and fingerprints are excluded from model-visible receipts, logs, action/step recording, protected-video metadata, metadata history, support data, relay data and disk. Input-monitor diagnostics contain only permission preflight, startup/health/coverage classes and recovery generation in process memory; they do not record keys or clipboard content. Wait operations use only elapsed time and cancellation state. Explicit focus leaves the selected app/control focused; other focus borrowing retains its existing safe restoration rules.

HVAIA Identity And Clean-Break Boundary

HVAIA starts as a new product identity. Its default runtime local state roots are ~/.hvaia and ~/.hvaia-dev, with operating-system application-data roots named HVAIA and HVAIA Dev. Source/development verification can also create the separate disposable ~/.hvaia-testing scratch root described below. Its application identifiers, keychain records, local HashiCorp Vault namespaces, credentials, protocols, enrollment records, and update channels are distinct and new.

HVAIA does not automatically discover, read, import, mutate, migrate, or delete another installed product’s data, credentials, protocols, updater state, enrollment, or service state. Another product may coexist on the same device. Uninstalling it or deleting its data is a separate user or operator action; installing, updating, resetting, or uninstalling HVAIA affects only HVAIA-owned state.

HVAIA-operated services use downloads.hvaia.com, relay.hvaia.com, relay-dev.hvaia.com, and publisher.hvaia.com. Public HVAIA Live sites use hvaia.site or a subdomain of hvaia.site; management traffic uses only publisher.hvaia.com. The HVAIA relay and publisher begin with clean storage. Chats, activation records, Apple Push Notification service device tokens, publisher content, and public pages are not migrated from another product. HVAIA’s APNs token-digest key is newly and independently provisioned in HashiCorp Vault; it is not copied from, derived from, or shared with either catalog-signing key.

HVAIA’s Apple push setup uses only the new HVAIA application topic, new device-token records, and an independently provisioned keyed-digest secret. OAuth registrations and webhook endpoints are provisioned for HVAIA’s new domains and identities. Any separately archived operator rollback resources remain outside HVAIA’s automatic storage and deletion boundary and are not automatically deleted by HVAIA.

Raw Apple push device tokens remain only in HashiCorp Vault and are separated between sandbox and production; the relay database retains only the keyed digest, Vault reference, exact owner/device scope, environment, state, and bounded delivery metadata already described below. Telegram webhook secrets likewise remain only in a Vault namespace for the exact relay environment, and a secret reference from one environment is rejected by another. This strengthens isolation without adding a data category, recipient, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v67.

The Rust-owned local gateway worker receives neither the local Vault credential nor the public-relay bearer token when it starts. While your active local profile is unlocked, the worker can use a random current-session, service-specific capability over loopback to ask the local backend for the already-enrolled relay route, account/workspace scope, host identity, and current runtime credential. The worker keeps that response only in its process memory for the current session and uses the credential only to authenticate its encrypted relay WebSocket; it cannot use this handoff to enroll, read Vault, or replace shared relay state. The loopback response contains no chats, prompts, files, model output, or connector content and adds no external recipient, persistent storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v67.

Local-first, not local-only

Within each Desktop window, HVAIA shares an authenticated local connection for delegated-work, Goal, background-process and integration updates. Subscription identifiers, replay positions and bounded event buffers stay in process memory. Each subscription keeps the existing profile and chat/run access checks; locking or changing the foreground profile fences delivery from the previous session. Reconnection reads existing local event history or refreshes current state. The connection adds no public-relay recipient, persistent event copy, data category or retention period, and requires no renewed consent beyond this policy’s current version.

To distinguish reopening a Desktop window from restarting its backend, HVAIA keeps an opaque backend-session identifier and the identifiers of chats whose queued messages require your confirmation in that window’s profile-scoped session storage. This record contains no messages, prompts, files, credentials or model output and is not sent to an external recipient. It lasts only for the window session and is removed by profile deletion or local data reset. Queued message content remains in its existing profile-owned chat storage. This content-free continuity record does not require renewed consent beyond this policy’s current version.

Replacing a paired phone invalidates its previous access credentials even when the new pairing uses the same device identifier. The Gateway keeps a binding generation and, for refresh recovery, one previous-token digest and a retry expiry alongside the current token digest. For up to 60 seconds, overlapping refreshes or a retry after a lost response recover the same replacement token. Raw refresh tokens are not added to Gateway storage; the existing mobile signing key remains in HashiCorp Vault. The next rotation replaces the retry receipt, and replacement or revocation immediately makes it unusable. These are authentication records, not chat content, and add no content-readable relay storage or external recipient.

Notification delivery rechecks the active profile after preparing its display and before starting each channel; a profile change cancels the stale claim for retry. Deleting a Studio project also prevents late generation results from leaving unregistered media files. Visual Memory repair streams existing local references in bounded batches, preserves valid points adopted by a newer delivery, and keeps its store open until its owned repair worker has actually stopped. These corrections use the existing profile storage and deletion boundaries and do not introduce a new data category or consent requirement.

Permission modes. In Control preserves granular approvals. HITL automatically executes supported work except the defined configuration, whole-resource deletion, persistent access, device-permission, and credential checkpoints. HVAIA Mode supplies consent for all supported product operations, including email, file changes, publishing, completed Plans, and Automation setup. Selecting a mode commits immediately for all workers in that chat and settles eligible pending approvals. It does not provide missing secrets or human challenges, grant unavailable OS capabilities, undo actions already admitted, or override Stop. The mode and revision are stored with the existing encrypted local chat state; compact decision provenance uses the existing local run records. Paired iPhone mode intents and snapshots remain inside end-to-end encrypted payloads, not readable relay metadata. These controls do not add credential storage, credential reveal/export, a new recipient, or a new retention period.

Scheduled chat model choice. HVAIA stores the chat’s canonical inference provider and model identifiers, a revision, and opaque write provenance in that chat’s existing encrypted local capsule so Scheduled tasks can bind to the model you actually used or explicitly confirmed. Full endpoint and request-option snapshots remain in existing encrypted run records. Draft edits, title creation, global model-picker changes, and renderer saves do not replace this binding; backend-created forks receive an independent copy. Deleting the chat, its project or profile, or resetting local data removes the binding under the same existing capsule boundaries. Paired-iPhone selection and initialization use the existing end-to-end encrypted live Desktop broker. No prompt, answer, endpoint, secret, or new relay-readable field is added, and no new recipient, storage root, retention period, or deletion boundary is introduced, so Privacy Policy version 2026-09-privacy-v85 remains current.

When restoring an interrupted chat, Desktop may read the exact run’s status from the authenticated local backend, alongside its saved response records. A confirmed cancelled, failed, or denied run can settle even when it produced no final answer; existing model output is preserved, and unavailable saved content remains recoverable. These checks and the resulting chat status use the existing encrypted local storage and paired-device sync boundaries. They introduce no new recipient, data category, storage root, retention period, or renewed-consent requirement.

HVAIA now applies several narrower reliability and isolation rules within storage and transport already described by this policy. Model-proposed Memory domain names are validated as a complete batch, and each resolved domain path must remain inside the exact local tenant/workspace Memory root even through symlinks; a rejected batch writes no derived domain, cache, or index data. The existing local Gateway database durably keeps content-free local run, ordered-event, approval, and helper-checkpoint topology so those controls recover after restart. Those rows contain only opaque ownership and routing identifiers, finite status/decision/version fields, safe reason metadata, and timestamps; they do not contain prompts, messages, assistant output, attachments, tool arguments or results, or checkpoint details. Related state and event changes commit together, and local SQLite compatibility upgrades serialize and roll back as one transaction. Private interactive Gateway frames go only to the exact authenticated connection that initiated the run and are never retained for replay; broader listeners receive only separately constructed content-free lifecycle status. The public relay rejects plaintext run.start and generic prompt.queue.* calls before backend, quota, or storage work, so iPhone prompts continue only through the existing end-to-end encrypted live Desktop broker. Telegram assigns deterministic opaque local transcript identities and advances its durable update cursor only after command, pairing, queue, or direct-backend admission succeeds; a failed pre-admission attempt remains retryable and does not acknowledge loss. These changes reduce duplicate processing, unintended local-path access, and data exposure. They add no data category, external recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v69.

Source/development verification uses a separate owner-only ~/.hvaia-testing root, or an explicitly configured replacement, for isolated synthetic test homes, pytest scratch, coverage fragments, and inherited subprocess temporary files. It is not a production profile, durable user-file location, secret store, model store, dependency cache, or release-output location. Normal completion removes per-test run-manager state and the isolated pytest session home; if a process is killed, a later run can remove only an exact abandoned session whose advisory owner lock is no longer held. The root and any remaining disposable output stay on the development device, are not automatically sent to a model, public relay, paired device, support report, or telemetry service, and are preserved by ordinary local-data reset because an independent verification process may still own them. A developer may delete the exact root after all verification has stopped, and the next run recreates it. This source-only storage clarification adds no production user-data category, external recipient, retention promise, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v67.

When you explicitly drop a local file into Desktop chat on Linux, the Electron shell reads no more than 32 MiB from the already-authorized path in sequential chunks of at most 2 MiB under one current-window, one-use grant. Rust checks the file’s identity before and after every chunk; Electron assembles one final byte array in current process memory. Completion, cancellation, expiry, file mutation, an invalid offset, or any error revokes the grant. This transport creates no additional disk copy, persistent store, log, telemetry, network request, or recipient. After assembly, the attachment follows the same encrypted chat storage, selected model-provider sharing, retention, and deletion rules already described for chat attachments; the existing Tauri attachment behavior is unchanged. This local transport clarification adds no data category, storage root, recipient, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v66.

When you select Google Gemini as the hosted inference provider, HVAIA sends Google the prompt and visible conversation context needed for that turn, any supported image attachments you intentionally include, and the HVAIA tool declarations and tool results needed for an active tool loop. Google processes that content under its own service terms and privacy policy. The Google API key is stored only in your active profile’s local HashiCorp Vault. HVAIA uses Google’s Interactions API with store: false, starts later user turns as fresh interactions from the visible transcript, and does not enable Google-native tools or background processing. Provider thought signatures needed to continue an active tool loop remain only in HVAIA process memory for that loop, including an exact joined-delegation wait as described below; HVAIA does not put them in chats, settings, logs, client streams, support data, paired-device state, or the public relay. They are discarded when that loop, its wait, or the process ends. This new provider recipient and data flow requires renewed consent at Privacy Policy version 2026-08-privacy-v52.

When Anthropic is the selected hosted provider and the selected model supports Anthropic prompt caching, HVAIA marks the request’s eligible prompt prefix for Anthropic’s ephemeral cache using the provider’s default five-minute lifetime. That prefix can include HVAIA’s system instructions, tool declarations, repo-owned AGENTS.md, CLAUDE.md, or GEMINI.md instructions applicable to the attached project, the current user request and current tool-loop results, and the earlier conversation and tool prefix already being sent for the turn. Anthropic processes and temporarily retains the eligible prefix under Anthropic’s service terms and privacy policy. HVAIA does not create a separate local cache of that provider prefix; cached-input counters, when Anthropic reports them, remain numeric fields in the existing local model-usage ledger. Token-count requests omit the cache marker. If Anthropic rejects the marker before producing output, HVAIA may retry that exact request once without prompt caching. No cached prompt content is added to HVAIA logs, support reports, telemetry, Memory, a paired-device cache, or public-relay-readable storage. This additional provider retention and the repo-instruction provider flow require renewed consent at Privacy Policy version 2026-08-privacy-v63.

For a long ordinary chat, HVAIA may automatically create a smaller continuation context, or create one when you enter /compact with optional guidance. The continuation normally aims to use no more than 5% of the selected model’s context window and is never accepted above 10%; fresh current instructions, tool definitions, or unavoidable live content may use the space between those limits. When checking whether a turn fits, HVAIA reads the dimensions of a supported inline image transiently in process memory and estimates its visual model usage instead of treating the encoded image bytes as conversation text; this check does not resize the image, write another copy, or change the image sent to the selected provider. The full encrypted chat transcript remains the canonical record and is not shortened or replaced. HVAIA stores a private encrypted checkpoint inside that chat’s existing capsule: a model-authored summary, exact bounded fragments of genuine user instructions, recent messages, a bounded recent window of sanitized earlier visible-message and tool-exchange source records, selected provider/model identity, and integrity and revision metadata. Older source records that leave this derived window remain only in the full encrypted transcript. Hidden reasoning, provider-private context, and binary media are removed from summary input and checkpoint recovery records. The same selected provider and model create the summary: a local model keeps this processing on your device, while a hosted model receives the earlier chat context under the same provider disclosure that already applies to ordinary turns. The summary request also identifies the exact conversation references it may cite, and HVAIA checks those references before accepting the checkpoint. This uses the same already-supplied context and does not add a recipient or retain another copy of your chat. For compatible OpenAI API models, HVAIA may also make an additional request to OpenAI’s context-compaction endpoint and keep its bounded returned provider-native output—including retained input items and one opaque provider-encrypted compaction item—inside that same locally encrypted checkpoint; the portable summary remains the fallback and is always retained. Creating or refreshing a checkpoint can require several same-provider model requests for a large chat, including chunk, combination, and up to three bounded attempts per chunk or combination to fit the checkpoint budget or repair invalid summary JSON, fields, or conversation references. A repair sends the original sources, a validation reason, and, when it fits the context window, the rejected summary back to that same provider and model. The repair may also identify failing summary fields and schema rules without adding private field values to system instructions. These diagnostics stay within the same temporary provider request. The rejected summary is untrusted repair context held only in process memory; it is not saved as a checkpoint or added to logs, support reports, or the public relay. Only a summary that passes the unchanged validation checks can be saved. When that provider is hosted, those extra requests and tokens can consume quota and incur provider charges even though they create no additional visible chat messages. During a later turn, that same live model loop may make up to three bounded reads of validated source records from only the same profile, chat, provider, and model. Exact recovery requests and recovered text stay in that live model loop; durable runtime events keep only content-free status and count metadata. The checkpoint and recovery records are not added to Memory, logs, support reports, the public relay, or the iPhone chat snapshot. A paired iPhone receives only the existing end-to-end encrypted /compact intent and content-free markers containing an opaque event id, time, and trigger. Rewinding the chat invalidates the checkpoint, a fork does not copy it, and chat deletion, profile deletion, or device-data reset removes it with the owning capsule. This narrows the normal continuation context without adding a new data category, recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v52.

Before compaction, HVAIA separately forecasts the next provider request from the prepared messages, current system instructions, tool declarations, and supported attachments. For local llama.cpp-compatible runtimes, HVAIA may ask that same on-device runtime to tokenize the prepared request. For OpenAI and Anthropic hosted models, HVAIA normally uses a conservative locally calibrated forecast; only when that forecast reaches at least 80% of the selected model’s context window, or when you explicitly request compaction, HVAIA may send the same prepared input to that same provider’s token-count endpoint. This is an additional hosted request containing the provider-bound prompt and context, uses the same configured credential and provider privacy terms, has a two-second limit, and is not retried. It returns only an input-token count to HVAIA; if it fails, HVAIA keeps the conservative forecast. The forecast and any exact preflight count decide compaction only and are never presented as confirmed context usage or billing usage. This additional same-provider counting request is included in renewed consent at Privacy Policy version 2026-08-privacy-v56.

While you view an idle selected chat, Desktop and a paired iPhone may show confirmed context usage from the newest applicable model request. Before the first request, the meter shows zero. After a request, it uses the provider’s or local runtime’s reported input plus inclusive output total, including non-visible reasoning tokens when the provider reports them in its total. If the newest request omits or returns invalid usage, HVAIA either labels an older valid value Last confirmed or hides the meter; it never substitutes the compaction forecast. The aggregate includes input, inclusive output, total, maximum, automatic- and mandatory-compaction thresholds, provider and effective-model labels, confirmation time, source type, and whether it belongs to the latest applicable request. For iPhone, those fields travel only inside the existing end-to-end encrypted live chat-detail response and remain in process memory; they are not written to the protected iPhone chat cache, UserDefaults, logs, support reports, or the public relay. No prompt text, message, checkpoint, recovery content, or source identifier enters the aggregate. This confirmed presentation and encrypted provider/model metadata are included in renewed consent at Privacy Policy version 2026-08-privacy-v56.

For every dispatched inference request HVAIA accounts for—including visible answers, tool continuations, compaction, title generation, delegated work, Side Chat, and each provider retry—HVAIA stores a local, profile-owned usage row in its existing run-lifecycle database. Each row contains only opaque request, run, operation, and chat identifiers; provider and model identifiers; request purpose, timing, and outcome; provider- or local-runtime-reported input, cached-input, output, and total token counters when available; per-counter reported/derived/missing/invalid status; the selected context-window size; numeric preflight raw and forecast counts plus their method/version; missing-field markers; a one-way digest of a provider response identifier; and a bounded numeric-only copy of native usage counters for audit. When an authoritative total exceeds input plus visible output, HVAIA derives inclusive output as total minus input rather than losing hidden reasoning usage. It never stores prompts, message or response text, tool content, reasoning, headers, credentials, or request bodies in these rows. Counts begin only after this feature is installed, may be incomplete when a provider omits usage, and are not a bill or cost calculation. The ledger remains on the Desktop device: per-request rows and Profile aggregates are excluded from the public relay, support reports, logs, telemetry, and model context. Only the bounded selected-chat confirmation described above may reach iPhone through end-to-end encryption. Deleting a chat removes its attributed or executed request rows; deleting a profile or resetting local data removes its remaining rows. These expanded counters and coverage fields are included in renewed consent at Privacy Policy version 2026-08-privacy-v56.

Desktop Settings may display a local Reported model usage dashboard derived from that same usage ledger, including total, input, cached-input, and inclusive-output lower bounds; per-counter request coverage; request counts; active-day and streak statistics; a yearly activity calendar; and per-provider/model rows. A ≥ mark identifies a confirmed lower bound when not every included request reported that counter, and the dashboard explicitly states that it is not a billing statement. This dashboard does not create a second usage store and does not send its filters, aggregates, activity days, model rows, or profile picture to a model, logs, support reports, or public-relay-readable storage. If you choose a profile picture, HVAIA reads the selected PNG, JPEG, or WebP only to validate and normalize it; the selected original is not retained as profile data, and only a metadata-free, square WebP derivative is stored under the active profile’s private local-data directory. The saved picture is used in the local Desktop interface and, while Settings is open on the paired iPhone, may be sent to that iPhone under the encrypted Settings transfer described below. Removing the picture deletes that derivative; deleting the profile or resetting local data removes it with the profile-owned root. The local profile-picture storage and dashboard presentation require renewed consent at Privacy Policy version 2026-08-privacy-v55; the expanded usage and coverage presentation is included in renewed consent at Privacy Policy version 2026-08-privacy-v56.

When you open Settings on a paired iPhone, the live Desktop may send that exact paired owner’s profile identity and picture, reported model-usage filters and dashboard, Personalize HVAIA text, notification policy, Knowledge document metadata, inference configuration and safe runtime availability, provider credential-presence flags, and archived-item summaries to the iPhone through purpose-bound end-to-end encryption. The public relay can observe only routing scope, opaque request identities, and ciphertext while forwarding a live request; it cannot decrypt, index, log, mirror, queue, or durably store the Settings request or response. The iPhone keeps Settings snapshots, filters, search text, drafts, disclosure state, picture previews, credential input, and upload progress only in current process memory. It does not put them in UserDefaults, Core Data, the protected chat cache, files, or Keychain, and clears them when the pairing, profile, workspace, or pairing key changes, when trust is revoked, on reset, or when the app process ends. A transient network interruption may retain the same owner-scoped in-memory screen read-only until reconnection. Provider keys and tokens are never returned to iPhone; only presence and safe status are returned. A new key travels inside the encrypted request, is committed only to the exact owner’s local HashiCorp Vault, is cleared from the iPhone draft after confirmation, and is redacted from diagnostics. Desktop resolves every Settings request against the pairing’s exact account, profile, tenant, and workspace even if Desktop is locked or another profile is foregrounded; it never changes or borrows the foreground profile’s paths, credentials, Vault identity, or interface state. An explicit quiet or attention notification test may exercise only its selected iPhone or Desktop channel for that paired owner while another profile is foregrounded; HVAIA cannot use this exception to deliver any other inactive profile notification. Local-model paths, raw runtime failures, and local runtime lifecycle controls are not sent to iPhone. Desktop rechecks that a selected local model is currently running and compatible before saving; installing, downloading, deleting, starting, stopping, or configuring automatic startup remains Desktop-only.

When you choose a profile picture, Knowledge document, canonical 14-file or legacy 13-file Memory export folder, local speech reference, or hosted custom-voice sample on iPhone, HVAIA validates names, types, declared sizes, and SHA-256 digests and transfers bounded one-mebibyte chunks through that same end-to-end encrypted live Desktop channel. Profile pictures and voice samples are limited to 10 MiB; Knowledge documents and aggregate Memory packages are limited to 100 MiB. Desktop stages only the minimum manifest and partial bytes needed for same-request retry in an owner-only HVAIA temporary directory, rejects nested Memory files, symbolic links, and path traversal, and invokes the existing atomic import or settings service only after every byte, count, type, and digest is verified. Successful and cancelled staging is removed immediately; incomplete or failed staging expires after one hour and is cleaned at startup and by a Desktop-owned expiry task even while idle. Expired staging cannot accept more chunks or begin a commit. Expiry never removes staging from an active application, including after request cancellation. Once that operation finishes, expired staging is removed; a failed operation within its original hour remains retryable. Successful retry receipts, manifest metadata, and chunk fingerprints remain only in Desktop process memory for one hour after application and are then removed; commit locks remain only while a caller holds or awaits them. Pairing revocation makes earlier staging uncommittable even before its files are removed. A hosted custom voice is sent to the selected speech provider only after you confirm that you own or have permission to use the sample, under that provider’s terms. Disconnect first asks Desktop to revoke trust; after confirmed revocation, iPhone clears pairing credentials, protected paired-workspace data, and Settings process memory. If revocation cannot be confirmed, trust and local data are preserved with a retry action. These iPhone Settings transfers, temporary upload staging, paired-device presentation, and deletion rules require renewed consent at Privacy Policy version 2026-09-privacy-v71. Policy review and acceptance remain available only in HVAIA Desktop; until this version is accepted, iPhone Remote Control connection and disconnect remain available but data-bearing Settings sections fail closed with guidance to review the updated policy on Desktop.

Browser, Computer Use, Apps and Skills in paired iPhone Settings use these same encrypted, exact-owner transfers. Desktop may send safe app and library metadata, installation progress, connection and credential-presence status, connected account/store labels, Watchdog settings, Computer Use preferences and allowed-app display names, browser preferences, and installed-skill names, icons, versions and pin state. Local paths, commands, process details, raw errors, skill source/archive URLs, specialist assignments, and full skill instructions are not catalog responses. Your explicit connector, store, Watchdog, preference, install, delete, pin or import action runs through the same Desktop services and existing storage/deletion rules; it does not install a connector runtime on the phone. A hosted Google Workspace or YouTube sign-in may open its validated authorization URL on iPhone. The sign-in provider receives ordinary browser requests and the information you choose to submit under its existing OAuth terms; resulting connector secrets remain in the paired owner’s local Vault. Physical Desktop permission prompts and Chrome extension installation still require your action on that computer. Ordinary Apps/Skills alerts keep their Desktop notification destinations.

WooCommerce stores, credentials, and default-store choices are separate for each HVAIA profile. Desktop and its paired iPhone use that profile’s same stores. Credentials and store configuration remain in that profile’s namespace in the existing local HashiCorp Vault; plans, jobs, safety records, and audit data remain under its local profile directory and follow profile deletion and reset rules. HVAIA verifies the final connector storage belongs to that exact profile before execution and rejects shared or foreign storage. Existing shared stores remain untouched and must be added again under the intended profile; HVAIA does not migrate them or assign an owner automatically. This adds no external recipient or persistent iPhone copy.

Profile cleanup waits for already-running WooCommerce calls and their connector shutdown before removing that profile’s Vault namespace and local files. It blocks new calls for that deleting profile and uses the existing content-free cleanup marker to retry. A process-memory record containing only the local profile storage identity, active-call count, and deletion flag prevents stale queued work from recreating deleted data. It contains no store content, request arguments, or credentials and is cleared when the process ends.

When you import a selected skill folder on iPhone, HVAIA reads its basename, relative filenames and regular-file bytes and transfers them through the existing encrypted Settings upload. Root SKILL.md must be nonempty; nested supporting files, including empty ones, are included. The folder is limited to 100 MiB total and per file, 10,000 files, one-mebibyte chunks, 1,024 UTF-8 bytes per relative path, 255 per path segment, and a four-mebibyte upload manifest. HVAIA rejects links, unsafe or conflicting paths, and unsupported ZIP import. The phone keeps upload state in current process memory and does not create a persistent copy. Desktop reconstructs verified bytes only inside its existing private owner-bound upload staging, passes that folder to the ordinary atomic Skills importer, and removes the reconstruction on success or failure. The installed skill then follows existing profile-owned Skills storage and deletion/reset rules. Slow Apps/Skills reads may send partial safe data; exact-owner operation receipts and terminal results remain only in Desktop process memory, with completed receipts removed after one hour. Disconnecting the network does not automatically replay an uncertain mutation or abandon an accepted import; reconnect checks its result, and an unavailable result requires refresh before an explicit retry. These additions use the Settings recipient, encrypted transfer, upload staging, memory retention, consent and deletion boundaries disclosed in Privacy Policy version 2026-09-privacy-v71; that version and its Desktop-only acceptance requirement remain unchanged.

Scoped deletion also finds older profile-only raw-event journals and their temporary or recovery copies at their existing local locations. Only records attributable to the exact owner are removed; ambiguous or conflicting records stop deletion before cleanup. This repairs existing deletion and retry guarantees without adding a storage location or external recipient.

For each temporary PDF source copy described below, HVAIA first verifies enough local storage for the remaining PDF bytes plus a fixed 1 GiB reserve. If that space is unavailable or cannot be verified, the read stops with local-storage guidance and leaves no new PDF work directory. This clarification uses the existing Shared Files temporary-storage and deletion boundaries at Privacy Policy version 2026-08-privacy-v51 and adds no new recipient, storage root, or retention period.

The bounded normalized Office scene used to display a presentation may include document-derived background, font-name, text-frame, transform, fill, and line metadata. HVAIA uses font names only to look for an already installed local font; it does not download fonts or place raw OOXML, source paths, or external font URLs in the scene. This metadata follows the same purpose-bound local and end-to-end encrypted Shared Files recipients, storage, retention, deletion, relay-blindness, and model-sharing rules as the document content already described below. This viewer-layout clarification adds no new recipient, storage root, retention period, public-relay-readable content, or renewed-consent requirement.

While a Shared Files open, source update, or close is awaiting its encrypted workspace write, the active profile’s HashiCorp Vault may temporarily retain a bounded prepare record containing the proposed platform capability plus an opaque tab id, operation, and one-way descriptor digest. The existing committed capability remains unchanged until the encrypted workspace decides whether recovery commits, rolls back, or deletes it; malformed or unavailable recovery state fails closed, and the prepare record is removed after resolution or with the same chat/profile capability cleanup. This Vault-only record contains no source path or file content and is never sent to a model, log, support report, paired device, or public relay. This recovery clarification is part of the Shared Files disclosures at Privacy Policy version 2026-08-privacy-v51 and adds no new recipient, storage root, or retention period.

A Shared Files annotation may keep a non-secret origin label such as Desktop, its page, slide, sheet/cell, line/column, timestamp, or normalized image position, and bounded quoted text plus one-way context hashes needed to restore its position after a file revision. This annotation metadata stays in the encrypted per-chat viewer state described below, follows the same deletion and paired-device rules, and is included in model context only when that annotation belongs to the actively shared visible view. If HVAIA cannot match an anchor unambiguously, it marks the annotation Needs review instead of moving it silently. This clarification is part of the Shared Files disclosures at Privacy Policy version 2026-08-privacy-v51 and adds no new recipient, storage root, or retention period.

For a Main Chat turn that uses Shared Files context or its bounded read tool, viewer-tool arguments, results, and visual reinjections are available only to the current live model exchange. The ordinary run lifecycle keeps content-free tool placeholders, call/status correlation, one-way dispatch hashes, and, when authority fails, a bounded public viewer failure code plus its precise bounded native subreason. Those records never include tool arguments, paths, file content, native session or grant identifiers, credentials, headers, or response bodies; they are removed with the existing chat, profile, run, or device-reset boundary. Recovery must read the currently shared file again if that information is still needed. Ordinary logs, raw diagnostic events, local issue-ticket diagnostics, and support-report payloads receive no viewer-tool arguments or results. Support diagnostics for that run also omit the entire conversation snapshot, including the assistant answer, plus raw error events, stack traces, client metadata, raw-event excerpts, log tails, and content-bearing run state, so quoted file content cannot be copied into a report. If a mixed action requiring approval loses its live Shared Files details before approval, HVAIA keeps only an omission marker and requires the user to cancel and retry that action separately instead of approving incomplete recovered work. This privacy hardening narrows diagnostic collection within Privacy Policy version 2026-08-privacy-v51 and adds no new recipient, storage root, retention period, or renewed-consent requirement.

When you ask Main Chat to edit a checked Word, Excel, or PowerPoint file, the selected main model chooses the relevant Office specialist from the meaning and context of your request; HVAIA does not choose or replace that specialist through a filename, extension, or regex rule. The specialist uses the same selected model provider under the provider disclosure that already applies to the turn. At delegation, it receives only the model-authored task and a temporary alias for the authorized checked tab, not a duplicated copy of your full original prompt, the injected Shared Files block, source path, sharing grant, or source revision. Through the live alias, it may inspect bounded editable text, cell values/formulas, shape geometry, and the current revision needed to propose the edit. Native viewer sessions, read/sharing grants, source paths, and file bytes are not sent as specialist identifiers. Inspection does not require approval; every actual Office edit asks for your explicit approval. An isolated local worker creates the candidate, and the native Rust file owner rechecks the exact live chat, sharing grant, and source revision before validating and atomically replacing the user-owned source and rotating the grant. A temporary backend connection loss does not by itself close that same-chat, same-scope native session; after recovery, Desktop re-enables sharing and registers a fresh backend grant before another edit, while changing chat or file scope, unchecking, closing, or exiting still revokes authority. An Office delegation is successful only when the existing compact receipt confirms that the resource changed, identifies the Office file kind, and reports a positive edit count; otherwise it returns a safe structured failure. The exact model-authored title of each Office tool step is shown in the authenticated local Desktop timeline and retained in the same local run-lifecycle event so that timeline can replay it; it may reach a paired iPhone only inside the existing end-to-end encrypted chat payload. Raw-diagnostic, support, and public-relay projections omit it. The plannerless Office answer is finalized and shown locally, then published once only after the compact receipt or safe failure evidence passes the same deterministic finalization checks as other chat runs. The specialist uses HVAIA’s existing profile-local, chat-and-specialist-scoped continuity ledger, but Office request and response continuity is content-free: Office tool entries retain only operation/status/file-kind/count metadata, and the ledger and durable delegation events omit the delegated task, original prompt, final child response, raw inspection/edit payloads, revisions, tab/resource ids, grants, paths, and bytes. Chat purge, profile deletion, or device-data reset removes that continuity under the existing local-data rules. A paired iPhone can request and approve the live desktop action only through the existing end-to-end encrypted Main Chat channel; the public relay cannot read, queue, or execute the edit. The tool-title clarification restores existing local and encrypted presentation, and it adds no new data category, recipient, storage root, relay-readable content, retention period, or deletion boundary beyond Privacy Policy version 2026-08-privacy-v57.

The Word, Excel, and PowerPoint specialists may also create polished native DOCX, XLSX, and PPTX files from scratch or from an authorized same-format template, and may perform supported everyday structural revisions. The selected specialist model may process the richer Office instructions, research brief, citations, data, and document structure needed for that work under the same selected-provider disclosure above. The Office specialists themselves receive no terminal, browser, Ibn Battuta, computer-control, Google, MCP, or direct internet authority; when research is needed, the main agent uses the internet-search specialist and passes a concise brief. Visual artifacts you explicitly select may be revalidated under your current profile and embedded locally through short aliases; model-visible Office arguments never receive their local paths. Each selected image is capped at 4 MiB and the selection at 16 MiB. Before approval, HVAIA builds and validates one candidate only in current process memory, scoped to the exact profile, workspace, chat, run, delegation, and specialist; candidates are capped at 25 MiB each, four active candidates and 100 MiB total, expire after 30 minutes, disappear on app restart, and are removed after replacement, success, denial, picker cancellation, failure, cancellation, run termination, or expiry. They are never written to HVAIA profile storage, chats, specialist history, lifecycle records, logs, diagnostics, support reports, a paired-device cache, or the public relay. Every final create, copy, or overwrite requires one exact approval. Standard-folder approvals name the folder and filename; other user-owned locations use the native Desktop save picker, whose selected absolute path stays in native process memory and is not sent to the backend, a model, logs, durable lifecycle storage, iPhone, or the relay. When a chat has an attached project, an approval may instead name Staged project and the portable filename. That file belongs to the existing HVAIA-owned staged copy, follows its chat/profile/reset deletion boundary, appears in Changes, and does not change the user-selected original project until Apply changes. Its exact staged root remains only in authenticated process memory and native transport. A paired iPhone may approve a standard-folder publication only while the owning Desktop is live; a picker publication is shown as Open on Desktop and can only be denied from iPhone. Rust alone validates and publishes the prepared bytes with no-overwrite creation or exact-revision atomic replacement. A successfully created file is user-owned when it uses a standard folder or picker, may be opened and shared in the current chat after all native/backend/encrypted-workspace grants succeed, and is not removed by chat deletion, profile deletion, or HVAIA data reset. After those grants and encrypted workspace state are established, one opaque created-resource handoff may remain for at most 60 seconds in current-process authenticated local transport so the exact source run can receive only the opened tab reference and continue editing. Its handoff id and hidden read grant are never sent to either model, persisted, logged, included in support data or paired-device storage, or exposed to the public relay, and are cleared on use, expiry, cancellation, scope revocation, reset, or process exit. If final native publication is ambiguous, a revealable recovery sibling may remain beside the selected destination for a user-owned standard-folder or picker file under the same recovery rules as Shared Files saves; an auto-open failure does not remove or recreate a file that was successfully created. This staged-project and current-process continuation clarification reuses the Office content, staged-project, provider, retention, deletion, and local authenticated transport boundaries already disclosed at Privacy Policy version 2026-08-privacy-v57. It introduces no new external recipient, readable public-relay exposure, persistent HVAIA storage root, retention class, or data category beyond the Office content and explicitly selected visual artifacts already described.

Office creation uses that same current-process specialist boundary even when no existing file or image is supplied. Its delegated brief is not admitted to the ordinary durable delegation queue. Selected downloaded pictures and generated images share the existing profile-bound visual-artifact validation and local embedding path. Restart requires fresh draft preparation; restoring an approval card does not restore expired file authority. These corrections prevent future unintended Office copies without changing existing historical records or adding a recipient, storage root, retention category, or consent requirement.

Profile preparation diagnostics retain only a bounded reason code, failing component, attempt number, and safe exception category. They exclude credentials, prompts, document content, raw exceptions, and provider response bodies. A later successful runtime can clear the matching runtime warning while leaving an independent document-preparation failure visible. This diagnostic correction uses existing local logs and status storage with their existing deletion and retention boundaries; it adds no new data category or recipient.

After a trusted first-party connector, native Office publisher, generated/downloaded artifact publisher, or delegated project changeset confirms a successful creation or edit, HVAIA may store a versioned changed-resource record inside the originating tool invocation in the existing encrypted chat. The record can include a durable resource identity, operation, display filename or cloud-document name, file kind, provider, time, specialist/delegation attribution, integration state, and capability-gated opaque targets or validated provider URLs for opening the resource in HVAIA, externally, or in its folder. It adds no new raw local-path field, never infers a mutation from arbitrary tool prose, and does not create a record for failed or ambiguous outcomes. Desktop uses these records beneath the final response and in Changes; a paired iPhone may receive them only as part of the existing end-to-end encrypted chat snapshot. The public relay, content-free delegation stream, ordinary logs, raw-event projection, and support reports receive no filenames, provider URLs, helper task titles, tool contents, or action targets. Chat deletion removes the records with the encrypted chat; profile deletion and device-data reset remove them through the same existing boundaries. User-owned files and cloud documents remain subject to their ordinary provider or filesystem deletion rules. This adds no new recipient, storage root, retention class, relay-readable field, secret path, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

For a failed approved Plan, HVAIA stores only the bounded recovery identity needed to show an explicit retry. An ordinary later message never retries that older work, and an explicit retry creates a new Standard run while leaving the failed source unchanged. These fields use existing encrypted local and paired-device paths, follow existing deletion and reset rules, and add no recipient, readable relay exposure, or retention period.

The local backend binds publication claim, final write-check, failure, and acknowledgement requests to an authenticated, role-scoped current-session service capability. This prevents one connector from claiming another destination’s accepted publication work merely by naming it in a request.

HVAIA is designed around a local desktop profile. Your chats, drafts, queued prompts, settings, memory, knowledge documents, automations, Scheduled tasks, Studio projects, generated audio, and onboarding state are stored on your device under HVAIA-owned app data folders. Source/development sessions and packaged app sessions use separate local data roots.

Studio projects, their assets and generation results, and image settings use the authenticated profile’s existing local storage and Vault credentials. Work admitted by a profile retains that profile while it finishes; switching profiles does not transfer it. Older shared Studio content is left untouched and is not automatically assigned, migrated, or deleted. This isolation repair adds no data category, recipient, retention period, storage root, or renewed-consent requirement.

Computer Use stores its enabled choice, safety limits, preview mode, separate action/step-recording choice, nested protected-video choice, optional metadata-history choice, and any apps you choose to Always allow only in the active profile’s local data root. An allowed-app record contains the platform, canonical app and trusted signer or package identity, display name, and approval time; it does not contain screenshots, window titles, app content, coordinates, typed text, or accessibility values. The preference fields record choices only and contain no captured content. When HVAIA recognizes an exact retired Computer Use settings format, it rewrites that file locally once, preserving supported choices and forcing every newly introduced capture or history choice off; an unknown or malformed older file is left untouched for explicit recovery. Allow once exists only for the current run and disappears when that run ends, is cancelled, the native broker restarts, or the app identity changes. Removing an always-allowed app pauses active use of it. To prevent source/development and packaged HVAIA from controlling the same desktop at once, Rust uses one empty, content-free advisory lock file in a fixed owner-only per-user operating-system temporary/runtime directory. The file contains no profile, app, action, content, coordinate, or diagnostic; the operating system may remove it during temporary cleanup, and HVAIA’s profile reset does not target it. Computer Use has no user-configurable endpoint and does not expose a first-party local network server. The changed authorization and storage contract required renewed consent at Privacy Policy version 2026-08-privacy-v58; the v78 preference and data-handling choices are disclosed above.

Chrome extension deployment state also stays on this device under the matching source/development or packaged HVAIA data root. That non-secret state can include the extension runtime mode and local backend candidates, bundle checksums, install time, whether Chrome still needs activation or reload, and the latest local activity or wrong-runtime diagnosis. Chrome control session state remains in that same identity boundary and does not make the other HVAIA identity appear connected. WooCommerce safety state—including local plans, jobs, idempotency records, audit events, backup-drill records, and locks—likewise stays under the matching HVAIA data root; Woo credentials remain only in the matching local Vault. These records are not sent to a model provider, connected service, paired iPhone, support relay, or public relay merely because they exist. They follow the active identity’s existing deletion and reset rules.

Computer Use working frames stay under the matching HVAIA temporary root, and the native broker fails instead of choosing another identity’s directory when the correct root is absent. Only a frame deliberately used for the current task is sent to the selected model, under the app-scoped and short-retention rules above. This replaces the older per-operation cleanup description with the bounded current/previous-frame and terminal/crash cleanup contract at Privacy Policy version 2026-08-privacy-v58.

Computer Use failures may include a finite diagnostic code identifying a changed app or window, obstructed coordinate, changed input or focus, unavailable semantic action, or secure context. These codes reach the selected model and existing content-free local run/event diagnostics so a failed action can be explained. They contain no app or window name, prompt, coordinate, typed value, screenshot, or arbitrary exception text. They follow the existing run and diagnostic retention/deletion rules and add no storage location, recipient, public-relay content exposure, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v58.

Apple Silicon macOS release qualification can write an ordered set of owner-only, content-free Computer Use checkpoints and one final receipt to a private location chosen by the release operator outside HVAIA profiles. Those files contain only source, package, hardware, display, runtime, fixture-contract, and live-process digests; bounded source-revision, model, and fixture-version identifiers; version and permission-state classes; invariant outcome counts; and timestamps. They exclude screenshots, app and window names, prompts, app content, coordinates, typed or accessibility values, and chat, run, tool-call, action, or authorization identifiers. HVAIA does not upload, synchronize, relay, add to support data, or send this release evidence to a model. The release operator controls its retention and deletion; chat deletion, profile removal, and local-data reset do not manage it. This developer release-evidence boundary adds no user-content collection, external recipient, product storage root, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v58.

The same private release-evidence boundary may retain a reviewer-signed physical-observation matrix for Computer Use behavior that cannot be established without seeing the disposable qualification fixture, plus its separate code-collected product-observation bundle. That bundle can represent only fixed schema/source/scenario names, one-way chat/run identities, completed state and sequence, first/last event times, and exact SHA-256 package/source/device/backend-window/call/result bindings. The signed matrix adds only fixed scenario/fact names, bounded event counts, bundle-derived scenario digests, timestamps, and an Ed25519 signature/key digest. The schema cannot represent a reviewer note, verdict boolean, raw chat/run identifier, app or window name, typed or clipboard value, file path, URL, screenshot, recording pixels, secret, credential, or arbitrary user content. Before authority is issued, the owning collector re-fetches the exact raw runs from the unchanged authenticated packaged-backend generation and recomputes the bundle; the stored bundle is not independently product-signed or MAC-authenticated. The checked-in reviewer registry contains public keys only; it starts empty and therefore blocks release until a real physical review is approved. These owner-only files are not uploaded, synchronized, relayed, sent to a model, added to support data, or managed by profile/chat deletion. This remains within the existing content-free developer qualification boundary and adds no user-content collection, external recipient, product storage root, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v83.

When you try to open a second copy of the same HVAIA desktop identity, the operating system may pass that launch’s arguments, working directory, and deep-link URL transiently to the already-running local HVAIA process. HVAIA uses this on-device coordination only to focus the existing window and route a bounded chat link; its callback ignores the arguments and working directory, and this mechanism does not log, persist, send to a provider or public relay, or copy the data to another device. Packaged HVAIA and source/development HVAIA Dev use separate app identities and separate hvaia and hvaia-dev link registrations, so one of each can run together without sharing this coordination boundary. This clarification adds no new storage root, external recipient, retention period, deletion behavior, or additional renewed-consent requirement beyond Privacy Policy version 2026-07-privacy-v49.

Scheduled tasks store their title, instructions, cadence, destination, owner, status, and run history in your active profile’s existing local Scheduled data. A task that continues a chat also stores the target chat and optional Goal identifiers, a message-anchor digest and chat version, the selected model and permissions, optional project and staged-workspace binding versions, your explicit current-or-isolated workspace choice, stop condition, coalesced occurrence count, attention and unread state, and result-chat link. At execution, HVAIA rechecks those bindings and may use newer messages from that same chat; it waits while another turn is active and does not bypass an approval, Plan review, user question, paused or blocked Goal, or changed chat/project boundary. A completed or replaced Goal stops the task. A standalone occurrence starts a fresh local session. If you explicitly choose isolated project work, HVAIA creates one visible joined child chat and a HVAIA-owned Git worktree; choosing the current workspace uses the exact existing staged copy. Deleting the Scheduled task removes its definition, instruction file, run records, and standalone occurrence-session messages, but does not delete its bound chat, Goal, original project folder, or visible child chat. The Scheduled instruction and bounded local session context pass transiently on this device from the gateway scheduler to the authenticated local backend; that loopback transport does not retain or log their content, and the backend remains the sole model, secure-storage, run, and publication authority. The selected model processes the Scheduled context under the same local-or-hosted provider rules as an ordinary chat, and tools or connected services process only data needed for the task under their existing policies. A paired iPhone may receive a compact Scheduled projection—including destination, target/Goal references, workspace mode, attention/unread state, and result link—only inside the existing end-to-end encrypted device envelope. The public relay sees only routing metadata and ciphertext, cannot read or durably store these fields, and never becomes the Scheduled executor. This clarification adds no new storage root, external recipient, retention class, or renewed-consent requirement beyond Privacy Policy version 2026-07-privacy-v49.

Scheduled definitions now also store whether their schedule is an interval or one-time, the interval value/unit or fixed instant/local wall time, device-local or named-timezone behavior, the named timezone when used, and a required tool-policy value. Each occurrence stores a snapshot of that effective tool policy so a later edit cannot change work already in flight. Existing Scheduled rows are migrated to the standard policy. A request for no tools or partially restricted tools is rejected before HVAIA saves a definition, instruction file, review, or run because that restriction cannot currently be guaranteed. A standalone occurrence receives a unique fresh session with an empty prior transcript and no automatically injected transcript or memory from another chat. A current-chat occurrence receives only its explicitly bound chat context. These context rules prevent automatic transcript inheritance, but they are not a filesystem sandbox: the standard agent tools remain available, including whole-computer filesystem access allowed to the current operating-system user, and the task may deliberately use authenticated chat or memory tools or read accessible local chat files. Guarded versus full autonomy changes whether protected state-changing actions need approval; it does not remove tools. A paired iPhone may receive the schedule, timezone, tool policy, permission state, available controls, and safe blocked reasons only inside the existing end-to-end encrypted device envelope. The public relay still sees only routing metadata and ciphertext. This disclosure is included in Privacy Policy version 2026-08-privacy-v50 and adds no new storage root, external recipient, retention class, public-relay-readable content, or additional renewed-consent step beyond that version.

Scheduled calendar recurrences additionally store their local time, anchor date, repeat choice, and applicable weekday, interval, day, or month selection in the existing local definition record. The record also stores your choice to notify only when attention is needed, after every completed run, or not at all, plus a content-free configuration revision used to keep late results from overwriting later edits. These choices affect future scheduling and eligible alerts; suppressing alerts does not suppress the task’s output, run history, or visible pending actions. When you create a Scheduled task from a chat, the local definition may retain that source chat’s exact identifier across reviewed destination changes so the source can continue showing the task; the identifier is an informational association, cannot authorize execution, and is removed with the definition or local profile data. A visible chat created for a task or occurrence keeps only the task ID and optional occurrence ID as a scheduledOrigin association in its existing encrypted, owner-scoped chat record and index; deleting the Scheduled definition does not silently delete an independently retained chat, while deleting the chat or profile removes that association with the chat. When an earlier attention alert is no longer current, the authenticated local scheduler may send only the task identifier, exact owner, and committed completion cutoff to the local notification service to resolve that alert; no title, instruction, result, or chat text enters this resolution request. A paired iPhone sees Scheduled task fields only through the existing encrypted live Desktop projection; a visible chat’s content-free task/run backlink follows ordinary encrypted chat synchronization. These changes create no new public-relay-readable content, storage root, external recipient, or retention class, and do not require additional acceptance beyond Privacy Policy version 2026-09-privacy-v85.

Changing a Scheduled task between its three chat destinations uses a reviewed, owner-bound configuration change. A switch to a dedicated chat may temporarily keep an activation receipt in the existing local task record until the exact visible chat is confirmed; if that chat changes before confirmation, the task waits for attention instead of running against guessed authority. When you complete, archive, or delete a live continuation timer, HVAIA may keep a content-free cancellation-pending reason and the existing source binding until the authenticated local backend confirms that only the matching source work was stopped. It then follows the ordinary Scheduled cleanup rules; an old completed timer cannot stop newer work. These recovery facts stay in existing local profile-owned records, never in public-relay-readable storage, and add no new recipient, storage root, or separate retention period. Privacy Policy version 2026-09-privacy-v85 remains current.

Each queued Scheduled occurrence now keeps the exact local, content-addressed instruction snapshot and SHA-256 digest that existed when it was queued, so an edit cannot change work already waiting or running. An older snapshot remains only while Scheduled state still references it or during a bounded 24-hour orphan-cleanup grace period inside the existing local Scheduled root. Deleting a Scheduled task immediately hides it and records content-free retry metadata and a tombstone in the existing local Gateway database, then idempotently removes its instruction snapshots, runs, traces, and standalone Scheduled messages; if cleanup is interrupted, HVAIA retries it, and delayed work cannot recreate the deleted material. A thread destination’s independently owned chat, Goal, project, and visible delegated child are not deleted. Worker lease identifiers, tokens, expiries, heartbeat times, and deletion retry fields contain no instruction or result content. These changes add no storage root, external recipient, relay-readable content, provider disclosure, or retention class and require no renewed consent beyond Privacy Policy version 2026-08-privacy-v63.

When you approve HVAIA controlling HVAIA, it can read or change profile-owned chats, projects, Automations and Automation Hooks, Gmail watchdogs, Scheduled tasks, Studio projects, Goals, Runtime Hooks, and the Personalize HVAIA text using the same local authorities as the app. Reads are bounded; every change asks for approval and uses replay protection, and authorities with state-version contracts also reject stale state. An approved Gmail watchdog change can store the Gmail account, optional sender scope, local mailbox-watch binding, status, health diagnostics, and timestamps in the existing local gateway data, and can ask the already-connected Google service to establish or check the same push-or-polling watch available from Settings. OAuth credentials remain in the existing local Vault; unavailable watch prerequisites are stored and shown as needs_attention rather than silently treated as active. Cross-chat work stores its prompt and result in the existing Scheduled and encrypted chat stores. HVAIA additionally stores profile-scoped pin preferences and bounded self-control replay receipts, plus protected Runtime Hook manifests and any private hook source, under the existing active HVAIA data root. Personalize HVAIA replacements affect future runs. Deleting or resetting the profile removes this profile-owned state through the existing cleanup boundary. Hook creation adds a compact chat receipt describing its name, trigger, behavior, status, and risk. Self-control tool inputs/results and Hook receipts can reach a paired iPhone only inside the existing end-to-end encrypted device envelope; the public relay sees only routing metadata and ciphertext and cannot read, index, log, or durably store them. Explicit Python or shell Runtime Hook source runs locally only after a separate high-risk approval, with the full file, network, and process authority of the current operating-system user; it is not sandboxed. HVAIA bounds the worker’s lifetime and captured output and cleans up its owned process tree, but those controls do not restrict what the source can access while it runs. Runtime Hooks remain manually invoked only: creating a manifest does not automatically subscribe or execute its source on lifecycle events, and selecting events only limits which event names a later manual invocation may use. Agent-initiated Gmail watchdog control adds no new data category, recipient, retention period, relay exposure, encryption change, or additional renewed-consent step beyond Privacy Policy version 2026-08-privacy-v50. This self-control capability originally required renewed consent at Privacy Policy version 2026-07-privacy-v49.

When HVAIA reads one chat for self-control, the bounded result may include up to 20 existing finalized-response checkpoint references in history order. Each reference contains the opaque assistant-message identifier already stored with the encrypted chat and a whitespace-compacted excerpt of at most 240 characters, allowing a later approved fork to select the intended answer instead of confusing a publication identifier with a message identifier. These references are returned only as the existing selected-model self-control tool result; they create no new checkpoint, copy, storage root, external recipient, log, support-report field, retention period, deletion boundary, public-relay-readable field, or renewed-consent step beyond Privacy Policy version 2026-07-privacy-v49.

Canonical Runtime Hook source versions are stored as owner-only, digest-addressed files inside the same profile-owned Runtime Hook directory. HVAIA writes a candidate source before atomically committing its manifest; it removes obsolete or uncommitted source copies only after that decision, or through a bounded recovery pass after interruption. A cleanup failure can leave a private, unreferenced copy for a later recovery pass, but it does not replace or invalidate the source referenced by the committed manifest. During each approved manual Python or shell Runtime Hook run, HVAIA writes one owner-only temporary copy of the already verified source inside that directory and executes the copy so a concurrent edit cannot replace the reviewed program while it starts or runs. HVAIA keeps the execution copy until the owned worker ends, then makes a bounded removal attempt after success, failure, timeout, or setup failure and reports a cleanup failure instead of silently treating it as complete. A copy retained after an unclean app exit or filesystem cleanup failure stays inside the existing profile and reset deletion boundary. It is not sent to a model provider, paired iPhone, public relay, log, support report, another profile, or any new storage root. This canonical-source and local execution-copy clarification adds no new data category, storage root, external recipient, retention class, deletion boundary, or renewed-consent step beyond Privacy Policy version 2026-08-privacy-v62.

When you approve HVAIA opening a supported local file through that self-control tool, the tool input and result may include its display path. The local backend resolves the file and asks the native file owner for a short-lived, one-use ticket; the Desktop then opens or reuses that file’s current-chat tab and requests Share with HVAIA on. The path itself never authorizes a file read. Sharing becomes active only after the ordinary encrypted workspace save, native sharing capability, and backend read grant succeed, and any later model use follows the existing Shared Files and selected-provider disclosures below. Activating a file selects an already-open matching tab and creates no file authority. Tickets and duplicate-effect tracking remain current-session only, and this extension adds no new storage root, recipient, retention period, public-relay-readable content, or renewed-consent step beyond Privacy Policy version 2026-08-privacy-v56.

Side Chat lets you ask a temporary follow-up without adding it to the main conversation. When you open Side Chat, HVAIA holds a frozen copy of the current chat’s user messages and completed assistant answers, your Side Chat questions or selected quote, and Side Chat answers only in the current desktop or iPhone app process. Side Chat cannot take actions, read ordinary chat attachments or unchecked files, write memory, create Plans or Goals, use terminal or MCP tools, or add its transcript to chat history, logs, offline caches, or the public relay. Its only tool is the read-only Shared Files viewer tool. When Share with HVAIA is enabled for a file, Side Chat may receive the checked files’ names and display paths, one retained exact visible view as described below, and revision-checked read grants for bounded file reads and bounded annotation-list requests. Repeated model-chosen reads can traverse a checked file without a HVAIA tool-turn limit. Every call and result is shown in the temporary Side Chat transcript; a malformed call is shown with secret-redacted raw arguments and its exact validation error and is never executed. The tool cannot save or change the source, use another HVAIA capability, or read an unchecked, closed, stale, or revoked file. The selected model receives that temporary context and question: a local model processes them on this device, while a hosted model provider processes them under that provider’s policy. Closing and clearing Side Chat, tapping Done on iPhone, deleting the parent chat, resetting or deleting the profile, unpairing or replacing the paired device, or ending the app session clears or revokes its readable process-memory state; an inactive iPhone Side Chat and an unclaimed desktop opening also expire after short live-session leases. A paired iPhone sends Side Chat questions and receives live answers and tool activity only through the existing end-to-end encrypted desktop channel. The public relay can route the encrypted live frames but cannot read or durably store their plaintext or ciphertext. For each ordinary standalone or project chat, the desktop may retain only three content-free local interface preferences: whether the shared pane was closed or the opaque pane type that was selected (Browser, Files, Side Chat, Sub-agents, Changes, or Goals), one integer pane width bounded to 300–960 pixels, and one boolean recording whether the normal pane should reopen full width. These profile- and chat-scoped preferences contain no transcript, URL, path, title, file metadata, Goal, diff, or agent content; they remain on this installation, are not synchronized to iPhone, survive ordinary restart or crash, remain through archive, and are removed with chat/project deletion, profile cleanup, or local-data reset. Returning to Side Chat in the same app run may reopen its in-memory transcript; after restart or crash the remembered Side Chat pane opens empty and creates no backend session until you send a message. Plan Review is not retained and does not change the ordinary pane’s remembered full-width state. This expands the existing content-free interface-preference category and does not require a new consent version. These Side Chat viewer-only access changes require renewed consent at Privacy Policy version 2026-08-privacy-v52; visible tool activity and unlimited model-chosen reads are included in the renewed consent at Privacy Policy version 2026-08-privacy-v56.

Clicking a downloaded-video thumbnail explicitly selects that video for local inline playback. The thumbnail becomes the player in the same card, and playback starts after your click. Verified downloads use the existing one-use file ticket. Older or reused downloads open the exact video you clicked through a native video-only action, without a file chooser. HVAIA validates that it is a regular video file and checks its identity; merely displaying a path does not open or read it. That click-selected preview cannot enable model sharing or create a durable Files permission. Inline playback holds one temporary unshared session in the owning chat and profile, with no Files tab, model grant, saved workspace, restart capability or extra video copy. Closing, replacing or removing the player, changing chats/profiles, leaving Chat or ending the app releases its temporary authority. A detached chat sends receipt correlation or the explicitly selected video path only through HVAIA’s private local window bridge; the main window plays it in the owning chat and sends no stream token or video bytes back. The protected local stream accepts the app’s origin and remains revocable. Clicking the displayed downloaded-video path in Chat, or Play in default app, explicitly opens the file in the operating system’s default application, whose privacy practices apply. The path does not start an inline preview. Files and Changes keep their existing sharing rules. No video reads or playback occur before your click. This local preview action adds no storage root, external recipient, model access, retention period or additional consent purpose; the current Privacy Policy version remains in effect.

Shared Files lets you open supported files in a per-chat, multi-tab workspace. HVAIA stores the workspace’s display state, checked-sharing choices, annotations and deletion tombstones, and bounded unsaved desktop edit journal as encrypted data in the active local profile. A platform-specific capability used to reopen a selected source after restart is a secret stored only in that local profile’s HashiCorp Vault; the encrypted workspace may keep only an opaque reference, and HVAIA asks you to reopen the file if the capability is missing or no longer valid. User-selected source files remain in their original user-owned locations; they are not copied into chat storage, and HVAIA changes a source or chosen Save As destination only after your explicit Save action through a revision-checked, validated atomic write. If another app changes a destination during the final save window or the operating system cannot confirm the outcome, HVAIA keeps one or more hidden recovery siblings beside that destination and offers to reveal them; because they are user-location recovery data outside HVAIA’s profile, chat deletion, profile cleanup, and HVAIA data reset do not remove them, and they remain until you review or delete them. A pathless chat attachment may require one owner-only plaintext copy in a random operating-system temporary directory while its tab is open; HVAIA removes that copy on tab or chat close, profile change or deletion, orderly app exit, and stale-owner startup cleanup. A path printed by a terminal command is display content, not permission to open a file. After a successful download with an explicit local output target, HVAIA’s trusted local terminal owner may compare that target directory before and after the command and store a typed, path-independent file-identity receipt in the private local run record. The visible path stays only in the existing encrypted chat terminal state; public relay, support, log, and external event projections receive neither the path nor native file identity. A failed, cancelled, shell-composed, changed, symlinked, or forged output receives no authority, and the bounded directory snapshot is discarded from process memory when the command ends. The receipt is removed with the owning chat, profile, run, or device reset and adds no external recipient or storage root.

Each new tab starts with Share with HVAIA on after HVAIA safely saves that choice and establishes its current private native capability and backend read grant. If the choice cannot be saved or either grant cannot be established, sharing visibly falls back to off before the file receives model-read authority. You can uncheck the toggle before asking a question; unchecked files contribute no model context or read authority. While you keep sharing enabled, a Main Chat or Side Chat prompt may include every checked file’s name and display path, but only one exact view: the most recently visible checked tab. That bounded exact view may include the on-screen frame or visible semantic text, the visible portion of unsaved edits, visible annotations, a bounded annotation index, and the current viewport; HVAIA never automatically injects every open document or an entire file. Before Files hides, collapses, or gives way to Changes or Side Chat, HVAIA freezes that exact current view in process memory. It does not persist the retained view or replace a failed fresh capture with an older frame. The retained exact view and checked metadata may remain available to both chats while Files is hidden, until a newer exact view replaces it or its authority is revoked. Other open tabs contribute metadata only. Main Chat and Side Chat may use the checked-file-only viewer tool for bounded reads and bounded annotation-list requests; repeated model-chosen reads can traverse a checked file. Side Chat receives no other tool or action authority. Read grants and retained views are revoked on uncheck, tab close, chat or profile deletion, reset, unpairing or pairing replacement, revision mismatch, failed attestation, or app exit. A capture failure removes the exact view instead of substituting stale content. This default-on sharing choice requires renewed consent at Privacy Policy version 2026-08-privacy-v54.

For image reads, HVAIA fetches revocation-checked file ranges into a bounded process-memory cache instead of writing a temporary full-file source copy; decoding retains the 100-megapixel limit. For a PDF text or visual read, HVAIA writes the exact revocation-checked source to one owner-only plaintext file under the active profile’s HVAIA temporary root only long enough for a fresh resource-bounded parser worker to process one request. The worker makes the temporary pathname inaccessible after opening where the operating system supports that behavior, and HVAIA removes the random work directory on normal success or failure; profile reset removes the temporary root if an abrupt process exit leaves a staging file behind. The temporary PDF source and path are not put in model context, chat storage, logs, support data, paired-device state, or the public relay. Audio and video playback uses the device’s native viewer on every supported desktop platform. In the Tauri desktop shell, images, audio, and video are delivered byte-for-byte through the same current-process, loopback-only native streaming listener, using separate image and media routes. The listener accepts only an existing native file session and its temporary stream token from an allowed HVAIA renderer origin, rechecks file identity on bounded reads, and supports full-file and seek requests without a temporary source copy. Linux Electron keeps its Rust-authorized Chromium range protocol. Closing the session or exiting the app revokes streaming access; the listener does not grant model access, store or log file contents or stream tokens, or send them to another device or recipient. HVAIA packages no FFmpeg, FFprobe, or media-analysis sandbox dependency, so whole-audio transcription or sampled-video analysis that requires those codecs fails closed in packaged HVAIA with playback or external-open guidance. A macOS source or development session may use one separately installed, colocated local FFmpeg/FFprobe pair only when HVAIA can run it under the built-in deny-by-default platform sandbox, limit input to the exact per-operation loopback media bridge without the file input protocol, and allow writes only to the exact protected derived output. Windows and Linux source or development analysis that requires FFmpeg currently fails closed before a codec child starts; native playback remains available. A configured hosted speech or model provider may receive bounded audio chunks, sampled frames, or extracted text only after an explicit supported analysis request under that provider’s policy. No whole-file read or media analysis happens merely because you checked the toggle. A local model processes shared context on this device; a hosted model provider processes it under that provider’s policy.

For an authenticated Main Chat message, HVAIA stores the accepted bounded snapshot—including the visible frame—only in an AES-GCM encrypted sidecar inside that chat’s active-profile capsule, bound to the original chat, run, and assistant-message identity. The ordinary run-lifecycle database keeps only an opaque reference, one-way digest, and compact marker, not the file path, visible text, annotations, or frame bytes. Only retry or recovery of that same run may decrypt the sidecar; unrelated later messages do not reload it. Chat deletion, profile cleanup, and HVAIA data reset remove the sidecar with the chat capsule. A Shared Files question sent to Side Chat keeps its frozen snapshot and viewer-tool results only in the temporary Side Chat process-memory session described above. HVAIA marks unsharing or closing complete only after the current desktop owner confirms revocation; if that confirmation fails or is ambiguous, the tab remains visibly checked or open with retry guidance instead of falsely claiming that access ended. On iPhone, those controls require a live writable desktop connection, while offline files remain available only for local viewing and annotation. After a confirmed uncheck or close, future reads are revoked immediately; a snapshot or bounded content already sent remains part of that earlier model request. These Shared Files context and Side Chat changes require renewed consent at Privacy Policy version 2026-08-privacy-v52.

A paired iPhone receives Shared Files workspace state, file bytes, names, paths, annotations, viewports, and sharing choices only through the live purpose-bound end-to-end encrypted desktop channel. The public relay sees only authenticated routing metadata and ciphertext; it cannot read, index, log, cache, or durably store those fields, file bytes, or annotation operations. For DOCX, PPTX, and XLSX, the authenticated desktop sends a normalized viewing scene capped at 16 MiB instead of raw Office source bytes; that derived scene follows the same encrypted channel, cache, and deletion boundaries. The iPhone stores completed workspace state, annotations, manifests, and approximately 2 MiB source or normalized-scene chunks in its pair/workspace/chat-scoped AES-GCM encrypted cache with complete iOS file protection and backup exclusion. Before showing a broker-backed annotation add or delete as successful, it stores an immutable pending operation in a separate AES-GCM record in that same scope. Each operation contains a UUID, opaque tab id, exact file revision, bounded annotation and base revision, action, and timestamp; the record is capped at 256 operations and 2 MiB, survives restart, overlays refreshed workspace state, and is removed only when an authenticated Desktop response acknowledges that exact UUID. Desktop rejects an altered retry and preserves concurrent Desktop and iPhone versions as visible Needs review conflicts, including delete-versus-edit. The relay never receives a readable operation or owns a durable retry queue. Only the active broker-backed tab retains decoded or playback-ready content in memory; changing tabs releases the prior decoded or protected temporary representation while its encrypted offline chunks may remain. That cache is capped at 2 GiB, preserves a fixed 1 GiB device free-space reserve, and never silently evicts another file. The iPhone’s Offline files screen shows only encrypted storage totals, the configured limit, bounded filenames, and per-file/current-chat byte totals; it does not reveal paths, read grants, native file authority, decrypted manifests, or file content. When you explicitly remove one download or all downloads for the current chat, HVAIA removes those encrypted file chunks and manifests—including any derived Office-view copy—and clears their current preview content, while keeping open tabs, sharing choices, annotations, and pending annotation operations. Protected plaintext files materialized only for Quick Look or media playback are removed when the app backgrounds, the tab or owning chat closes, the device is unpaired or reset, and during startup cleanup. Closing a tab removes its iPhone cached source and derived bytes and stops future sharing; its encrypted annotations may remain with that chat so reopening the same file can restore them. Deleting the chat, profile, pairing, or device data removes the corresponding HVAIA-owned viewer state, pending annotation operations, and cache but never deletes the original user-owned source file. These Shared Files disclosures require renewed consent at Privacy Policy version 2026-08-privacy-v51; this storage-management clarification uses the same data, recipient, storage root, and retention boundary and does not introduce another policy version.

While the Desktop app remains running, it keeps a separate current-process iPhone owner session for each exact profile, account, workspace, chat, paired device, and pairing key. If User A locks their Desktop profile and User B becomes active, A’s paired iPhone may continue A’s Main Chat, temporary Side Chat, current-Goal and completed-Goal-history reads, Goal readiness, checked Shared Files reads, annotation review and synchronization, and audio or video playback. The Goal exception is read-only and does not authorize background Goal actions or the Goal event stream. Every request is resolved from A’s encrypted chat state, lifecycle state, model choice, permissions, Vault-backed credentials, file tabs, and checked grants; B’s renderer, notifications, logs, Goal content, prompts, answers, filenames, paths, annotations, and tool traces do not receive A’s data. Changes reconcile into A’s workspace when A returns. iPhone file editing remains limited to viewing, annotations, playback, and changing Share with HVAIA; Office and text saving remains Desktop-only. The live owner session and retained exact viewer frame are never persisted. Profile or chat deletion, reset, unpairing, pairing replacement, failed attestation, or app exit revokes fresh Desktop access. After Desktop exits, already encrypted cached files may remain available offline under the cache rules above, but a fresh Desktop read requires the owner to unlock and revalidate. The public relay remains ciphertext-only and cannot read or durably queue Goal history, file metadata, content, annotations, prompts, answers, or tool traces. This cross-profile continuity requires renewed consent at Privacy Policy version 2026-08-privacy-v52; the read-only Goal-history and readiness extension is included in renewed consent at Privacy Policy version 2026-08-privacy-v62.

When you create an Automation Hook, HVAIA stores its friendly event choice, instructions, permission mode, enabled state, and normal run history with your profile’s local Automation data. The lifecycle signal that starts it contains only bounded identifiers, status or reason codes, and explicitly allow-listed built-in event metadata; it does not create another stored copy of your prompt, assistant response, tool input or output, notification text, secret, token, or arbitrary event body. A Hook runs after the selected event. If Hook dispatch crashes, times out, or is unavailable, the action that triggered it continues; Hooks are not permission, approval, validation, or security controls. A Hook’s own actions still use normal Automation permissions, local Vault access, owner scoping, deterministic integrity checks, and publication rules. Event choices come only from HVAIA’s immutable built-in catalog; connected apps cannot register or supply events.

Images generated or edited for a chat are downloaded promptly from the selected image provider into the active profile’s HVAIA-owned visual-artifact folder. Browser screenshots, local images imported for model vision, embedded images returned by tools, and Computer Use frames you explicitly ask HVAIA to Save evidence may be stored in that profile-owned visual-artifact class. Ordinary Computer Use frames are not durable visual artifacts: only the current and previous authorized-app crops are kept in an owner-only temporary run location, each is capped at 16 MiB, the run is capped at 64 MiB, they are deleted when the run ends, and crash remnants older than 15 minutes are removed on startup. HVAIA sends an authorized app crop to the selected local or hosted chat model as a separate image input when Computer Use needs visual understanding; it never places the raw bytes or a local path in tool JSON, streams, run journals, logs, diagnostics, support data, policy receipts, a paired-device cache, or the public relay. Explicitly saved Computer Use evidence is deleted with its owning chat, profile deletion, or device-data reset. If reserved evidence metadata cannot prove the owning chat, chat deletion remains visibly incomplete and the exact profile files are retained for retry or profile/device cleanup rather than risking deletion of another chat’s evidence. Other visual-artifact files have no time-based expiry and currently remain until profile deletion or reset even when an individual chat is deleted. HVAIA-owned visual-artifact files are not copied to HVAIA’s public relay. Surviving legacy files remain available under their prior deletion rules. Missing previews are shown as unavailable without repeated download attempts. The retry guard keeps only bounded opaque missing-artifact identifiers in the Desktop WebView’s session storage and clears them when that session ends; it does not store image content, URLs, paths, or provider data there. This app-scoped capture, model transmission, retention, and deletion change requires renewed consent at Privacy Policy version 2026-08-privacy-v58.

When you generate a video in chat or Studio, HVAIA sends the prompt, selected model and generation options—and any source image, video, or audio you intentionally select—to the hosted video provider chosen in Settings (Alibaba Model Studio or xAI). Those providers process the request under their own terms and may make the completed video available at a short-lived provider URL. HVAIA downloads the result promptly, validates it as an MP4, and stores it in the active profile’s HVAIA-owned visual-artifact folder for chat or studio/videos for Studio; the provider URL is not retained as the playback source. Video prompts, job state, model/provider metadata, source-asset references, and local output metadata remain in the existing profile-owned chat or Studio state. Video API keys are stored only in local Vault and are never written to settings files, chat history, logs, WebView storage, a paired iPhone, or the public relay. Local video generation is marked Coming soon and does not start a local runtime. Generated video files have no automatic expiry: profile deletion or device-data reset removes them, while deleting one chat does not currently remove shared visual-artifact video files. A paired iPhone receives Studio video metadata and on-demand video bytes only through the existing end-to-end encrypted live desktop channel; its temporary playback file is removed when the player closes. The public relay sees routing metadata and ciphertext only and cannot read or durably store the prompt, source media, generated video, provider response, or local file path.

For conversation history controls, HVAIA stores an encrypted, per-chat capsule in the active local profile. An untouched startup New chat remains only in Desktop process memory until its first durable draft or prompt boundary. The encrypted capsule records can contain the chat transcript, unsent draft, queued prompt state, copied attachments, finalized-response checkpoints, and an opaque link to an attached project. If you stop a run before it produces assistant text and then send a follow-up in the same chat, HVAIA keeps the original user request in that chat’s immediate model context so the selected model can understand a correction; the empty stopped assistant placeholder is not sent as assistant text. Each newly created assistant run also retains bounded model-identity metadata—the provider, catalog model id, effective model name, and display name actually used for that response—in the existing chat/run history so the timeline can show a model-change marker. A paired iPhone receives that same optional metadata only inside the existing end-to-end encrypted chat snapshot; HVAIA’s public relay cannot read or store it as content. Ordinary project chats work directly in the selected project folder. HVAIA keeps one encrypted, project-owned binding containing the canonical local path, a path digest and filesystem identity used to detect replacement, and an opaque resource scope; each member chat keeps only project identifiers and an opaque link, not another source-path copy. Multiple chats in the same project, chats in different projects, and regular chats may run at the same time. Creating another project chat links it to the existing live folder and does not wait for another member chat to finish. Direct edits are visible in the real project immediately and have no separate Apply changes step. A short, timed per-project mutation lease serializes only individual commit, capture, Undo, Redo, and recovery boundaries for that folder; it is not a project-wide run lock and does not serialize unrelated projects or regular chats. Forking makes a new local chat capsule, and the Fork control becomes available only after the selected assistant answer is present in durable finalized history. A narrowly bounded retry handles only the brief interval in which that exact checkpoint is still being committed; it creates no additional checkpoint, log, recipient, relay-readable field, retention period, or deletion boundary. A current-project fork links the new chat to that same live folder. A direct-workspace rewind changes only that chat’s transcript; it does not rewrite the shared project, and file history remains available through Changes. Only an explicitly isolated or delegated workflow receives its own HVAIA-managed staged copy or Git worktree, where checkpoint materialization and Apply may still be used. Deleting one chat removes its capsule, link, drafts, queues, and chat-owned history but never the selected project folder or the shared binding while its project remains. Removing the project removes HVAIA’s project binding and member chat data but never the user-owned folder. Profile deletion or local-data reset removes HVAIA-owned bindings, capsules, history, and isolated copies, not the selected project itself. Local storage media and external backups may retain forensic copies after deletion. This direct shared-workspace model and its changed deletion, concurrency, and history boundaries require renewed consent at Privacy Policy version 2026-09-privacy-v68.

For a trusted attached project, the main agent can use bounded repository mapping, search, and paged file reads; exact root and subtree instruction files named AGENTS.md, CLAUDE.md, or GEMINI.md; digest-bound edits; and structured verification commands. File content, applicable repo instructions, edit arguments and receipts, and bounded verification or terminal output can enter the selected model’s live tool loop and existing encrypted chat tool history. A local model keeps that model processing on the device; a hosted model receives the needed content under that provider’s disclosure above. Repository cursors and structured edit receipts use project-relative paths, but the selected model can receive the absolute project path if a tool, command, traceback, or project content emits it. HVAIA necessarily resolves the selected path in the authenticated local backend, and the authenticated local Desktop can receive it for an explicit reveal/open action; HVAIA does not deliberately render it in the sidebar or add it to logs, support reports, telemetry, Memory, paired-device state, or public-relay-readable storage. Structured multi-file publication uses an encrypted, crash-recoverable project transaction containing project-relative names and bounded before/after bytes. It uses same-folder owner-marked temporary or quarantine artifacts and removes only artifacts whose owner and expected state can be proven. A timed, cancellable per-project lease covers each structured mutation and its Changes before/after capture. A finite terminal command classified as mutating or uncertain holds that same lease until its real exit, error, cancellation, or lost connection; read-only commands do not take it, and a model-explicit persistent server or watcher remains concurrent and untracked, so its writes can conflict with other work and are not promised Undo. Terminal commands run with the current operating-system user’s authority and are not a filesystem sandbox. HVAIA records supported structured changes in encrypted Changes history, including bounded regular binary contents. Undo and Redo preserve later disjoint UTF-8 line edits with a three-way merge, restore binary files only when their exact expected state still matches, and fail closed without writing when edits overlap or authority cannot be proven. A durable transition intent lets restart recovery recognize and complete or roll back an interrupted merged transition without guessing. Explicit isolated or delegated copies retain their separate staged-workspace and Git metadata behavior. These coding-tool, local-path, concurrency, transaction, and provider-sharing changes require renewed consent at Privacy Policy version 2026-09-privacy-v68.

From Privacy Policy version 2026-09-privacy-v68 onward, any earlier reference in this document to a Staged project, a private staged project copy, or an ordinary project’s Apply changes flow applies only to an explicitly isolated, delegated, or legacy staged workspace. An ordinary attached project chat uses the live-folder behavior described above.

When one chat asks HVAIA to continue work in another chat, HVAIA checkpoints that prompt in the destination chat’s existing encrypted capsule with the existing non-secret HVAIA author-origin value. Desktop and a paired iPhone use it to label the prompt Sent by HVAIA from another chat rather than presenting it as text you typed in the destination. It follows the same local deletion, profile reset, end-to-end encrypted paired-device, and public-relay-blindness rules as the destination transcript. This corrects authorship presentation without adding a data category, storage root, recipient, retention period, deletion boundary, public-relay-readable field, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v56.

When an active HVAIA task explicitly inspects other active tasks for cooperative same-checkout coordination, HVAIA may return to that task’s selected model a bounded task-goal excerpt of at most 240 normalized characters, the current phase and activity state, interaction mode, opaque profile-scoped repository and checkout equality fingerprints, whether a task uses the same checkout or another worktree, and counts of HVAIA-owned active, persistent, or ownership-unverifiable terminal commands. A hosted selected provider receives that bounded context under its own terms and privacy policy; a local selected model processes it on your device. HVAIA does not infer file ownership or a write set and does not include raw repository paths, Git directories, resource scopes, terminal commands, output, process identifiers, watcher names, or peer transcript history in this discovery result. Full peer goals are not inserted automatically into every model request. Only tasks with the same exact profile, account, tenant, workspace, and local host are eligible, and the model—not the backend—judges whether their work overlaps.

After the existing approval required for a cross-chat dispatch, an exact same-checkout coordination request stores its readable peer message once in the destination chat’s encrypted capsule and stores matching content-free coordination records in both bound chat capsules. The local run lifecycle stores only opaque coordination and message identifiers, one-way request and scope digests, exact run fences, states, versions, timestamps, and content-free application and response receipts. Before a lifecycle message checkpoint or its compaction callback, HVAIA reduces provider-ready peer text to one matching content-free reference. If the exact receipt and prompt digest cannot be read or matched, HVAIA omits that new message snapshot and keeps the earlier safe checkpoint instead of storing readable peer text as a fallback. The destination message stays hidden until HVAIA proves it was applied to the exact active run at a safe model/tool boundary, then appears with the label Sent by HVAIA from another chat. The destination model may acknowledge, decline, or voluntarily pause without another approval because that narrow response can address only the already approved exact request; it cannot carry a new prompt, path, command, approval, tool argument, or alternate target. Any dirty paths, commit state, test evidence, or explanation it reports are model-authored, bounded, and non-authoritative. Those details may be retained in both encrypted coordination records and returned to either bound task’s selected model, but HVAIA never treats them as proof of file ownership.

A coordination pause receipt proves only the exact local coordination transition and HVAIA’s observation that no HVAIA-owned active, persistent, stopping, lost, or unverifiable task command remained at the verification boundary. It always says that filesystem exclusivity is not proven. HVAIA cannot prove the absence of external editors, independently launched or escaped processes, future activity, or changes made outside its owned terminal sessions. A later run or owned command in that checkout marks the last-known pause as no longer current. A later direct human Steer supersedes an unpublished pause only when HVAIA can prove the prior assistant-generation fence and a newer content-free Steer receipt; it then removes the old pause marker without creating an assistant explanation. A failed, cancelled, denied, missing, or explanation-less completed target settles the coordination request rather than leaving the source waiting indefinitely, while a recoverable execution_incomplete target remains pending. These repairs add only content-free generation/version fences, reason codes, and cleanup events to the existing local lifecycle data and add no new recipient, storage root, retention period, public-relay-readable field, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v69. The receiving task must inspect Git, Changes, and relevant files again before editing or integrating. Coordination never locks a file, denies a filesystem mutation, commits, stashes, resets, merges, deletes, or rewrites user work.

Desktop can show content-free coordination status cards in the two bound tasks. A paired iPhone receives only the delivered labeled transcript message and a bounded read-only last-known coordination card inside the existing end-to-end encrypted chat snapshot; that card contains no repository or checkout fingerprint, task goal, phase, terminal count, path, command, output, process detail, or control action. Explicit chat switching clears the prior visible projection, while explicit disconnect, unpair, pairing replacement, scope reset, protected-cache teardown, chat deletion, profile deletion, or local reset removes the applicable protected coordination cache. The public relay receives only its existing opaque routing metadata, end-to-end ciphertext, and generic chat invalidation; it receives no readable peer message, task context, repository/checkout relationship, coordination queue or table, receipt body, or durable ciphertext queue. Coordination prompts, goal excerpts, phases, relationships, receipt bodies, paths, commands, terminal details, and model-authored handoff reports are excluded from ordinary logs, telemetry, notifications, support reports, and Memory.

Deleting a destination task cancels an undelivered coordination pointer, removes its hidden prompt, and leaves a surviving source record unavailable or stale. Deleting a source task cancels undelivered coordination work; a message already delivered to the destination remains in that destination transcript but is marked as having an unavailable source. Project deletion removes the affected HVAIA-owned coordination state and metadata without deleting the user’s project folder. Profile deletion and local reset remove the profile’s coordination records, pending pointers, receipts, and protected paired-iPhone cache. A failed cleanup remains retryable and is not reported as complete. Unresolved coordination records are retained until an exact lifecycle transition or deletion settles them; each chat then retains only its newest 64 settled records. These new cross-task discovery, selected-model sharing, encrypted storage, paired-device presentation, receipt limitations, retention, and deletion behaviors require renewed consent at Privacy Policy version 2026-09-privacy-v69.

When chat deletion pauses because linked local results could not be cleared, HVAIA keeps the chat and the existing content-free cleanup identities so you can safely retry. The local backend may write a bounded operational warning containing only a cleanup reason code, retry attempt, ambiguous-outcome flag, and exception class; it does not log the chat identifier, chat text, attachment path, token, endpoint, or raw exception message. The desktop receives only the corresponding user-safe reason code, diagnosis, and retry/ambiguous-outcome flags over HVAIA’s authenticated loopback API so it can explain the recovery action. These diagnostics follow the existing local log and chat-deletion/reset lifecycles and are not sent to a model provider, connected service, paired device, or public relay. This clarification adds no new data category, storage root, external recipient, retention class, or renewed-consent requirement beyond Privacy Policy version 2026-07-privacy-v49.

When you choose to use code support for an attached project, HVAIA may offer to download a verified local language-server component after you explicitly select Install. The component cache contains executable payloads, version/source/license metadata, checksums, receipts, and content-free installation progress under HVAIA’s local cache; it does not contain your source files, diagnostics, hover text, diffs, or project path. Component download, unpack, and promotion preserve the same fixed 1 GiB local-storage reserve in addition to the pending write. HVAIA verifies the download and unpacked component before use, removes unpublished install candidates after failure or restart recovery, and does not start a server from an arbitrary tool already installed on your computer. This download is local to your device and does not send your project content to the component source.

The Agent Terminal uses the current signed-in operating-system user’s filesystem in every chat. It can read any path that user can read. An attached project still starts the terminal in HVAIA’s private staged project copy so project edits can be tracked, but that copy is not a filesystem sandbox: an approved terminal command can also write explicit user paths such as Documents or Downloads. Read-only commands do not need a confirmation card. Every mutation—including creating, changing, deleting, downloading, installing, or moving local files—uses HVAIA’s normal approval card, which describes the action and target path before it runs. The terminal receives the real user home directory but a HVAIA-owned ephemeral temporary directory; HVAIA does not forward the desktop/backend parent environment or its secrets into the terminal. Package managers, downloaded dependencies, project scripts, and any command may contact package registries or other internet services and can send normal request metadata—and any data that command explicitly transmits—to those third parties under their own policies. Terminal network traffic does not pass through or become readable content in HVAIA’s public relay.

The desktop Agent Terminal uses a persistent pseudo-terminal process owned by the local Rust desktop shell. The admitted command text, agent-provided interactive input, and combined terminal output cross an authenticated, terminal-only loopback bridge between HVAIA’s local Python backend and that Rust owner so the shell can preserve its working directory, environment, and other session state. This transfer stays on the device and is transient. The bridge does not log commands, input, output, paths, or private completion tokens. Ordinary command text and bounded terminal output continue to be retained only in the existing encrypted per-chat history used for tool evidence; HVAIA does not create a separate terminal log file or WebView storage copy. This adds no new storage root, external recipient, relay-readable content, or retention class. If you choose a hosted model, tool output needed to complete the requested task may be processed by that selected provider under its policy; it is never made readable to HVAIA’s public relay. At most the recent bounded transcript is replayed after restart, and a new app session starts a fresh shell without claiming that prior shell state was restored. Existing chat deletion, profile reset, capsule cleanup, and device-data deletion rules continue to remove the retained transcript.

After one successfully downloaded YouTube video, desktop chat may load that video’s public thumbnail from YouTube’s i.ytimg.com image service. The request contains the validated public video identifier already present in the approved terminal command and normal network metadata such as your IP address and user agent; HVAIA requests the image without WebView credentials or a referrer and does not send the downloaded video’s bytes, local path, chat text, or Vault secrets. The thumbnail is lazy-loaded, is not copied into HVAIA chat storage or the public relay, and disappears if unavailable while the existing local file link remains. Activating the thumbnail starts local inline playback; activating the local video path opens the operating system’s default application. This clarification adds no new external recipient beyond the YouTube service used for the requested download, no new stored data or retention class, and no additional renewed-consent requirement beyond Privacy Policy version 2026-07-privacy-v49.

For a one-time administrator action, the desktop approval card may ask for your sudo password only for a command that explicitly starts with sudo. The password remains in the password field only until you submit it, is cleared from the card, and is sent directly to the current native desktop runtime. That runtime keeps it only in current-process memory for one matching approved command (or up to 60 seconds if unused), gives the local backend only an opaque handle, and clears/zeroes it when consumed, expired, cancelled, or the app session ends. HVAIA invokes the system sudo without using shell aliases, functions, or a changed command search path, and does not accept further terminal input while that elevated command is active. The password is not saved in Vault, Keychain, a file, chat history, terminal output, logs, WebView storage, a paired iPhone, or the public relay. An iPhone or other remote client cannot supply this password; that approval must be completed in the local desktop app.

Projects are profile-scoped encrypted metadata derived from a stable folder identity and a display basename. The raw source path is kept in the encrypted project-owned binding and may be returned only to the authenticated local Desktop for an explicit reveal/open action; outside the explicit new-folder confirmation described below, it is not rendered in the sidebar, placed in a relay event, logged, included in a support report, or sent to iPhone. When you create a new empty project folder, HVAIA first shows the exact final path in a confirmation step and creates nothing until you confirm. Choosing a parent folder whose final name already matches the new project name is rejected before creation, preventing an unintended name/name folder. Desktop folder-picker previews remain only in current desktop memory. When you create a project from iPhone, HVAIA previews a new folder under HVAIA Projects in your paired computer’s Documents folder and waits for your confirmation. The project name, exact preview path, creation request, and result travel only in the existing encrypted live connection between your paired devices. The phone keeps this form only in memory and clears it when you dismiss it, finish creation, change the name, or change pairing, profile, or workspace. These values are not added to logs, phone caches, or relay-readable storage. After creation, the existing protected project binding rules apply. The new folder is user-owned and is not deleted by removing the project or resetting HVAIA. The encrypted project binding retains a full canonical-folder digest, filesystem identity, opaque resource scope, and matching logical-project owner so another logical sidebar project cannot adopt it. A selected Git folder may also provide its source branch as optional, display-safe local metadata. The composer can show only the display basename, Local, and that optional branch. If the logical project, canonical-folder digest, filesystem identity, code-project capability, and trusted owner do not agree, HVAIA withholds the branch, capability, and source, disables project tools, and shows only generic re-attach guidance; it does not search for, import, reuse, or silently repair another folder. The sidebar additionally retains content-free project display state: project and chat order, an empty-project placeholder, and any manually requested unread marker. A confirmed project rename, pin, or archive change remains authoritative for every member chat when an older desktop write is reconciled. A paired iPhone receives only the project identifier, display name, ordering, placeholder, and unread state inside its existing end-to-end encrypted chat snapshot; it never receives the original folder path or project files. Before the first accepted prompt, a project choice may be changed or removed. Creating another chat in an attached project stores only a new opaque chat link to the existing project binding; it neither clones the folder nor checks whether another project chat has an active run. Afterwards the project choice is locked. If its protected attachment is missing or mismatched, the user may explicitly choose the folder again, but HVAIA accepts it only when inspection proves the same logical-project identity; cancellation or failure leaves the draft and current state unchanged. HVAIA never searches for or silently substitutes another folder. A folder created through the new-project flow remains user-owned and is never deleted when the pending choice is removed or never sent. Removing a project deletes its HVAIA-owned binding, member chat capsules, drafts, queues, Changes history, and any explicit isolated copies while leaving the original selected folder untouched. A new standalone chat may hold a protected pending folder attachment only until its first accepted prompt; sending without one permanently closes that attachment opportunity. These project-binding and concurrent-chat changes require renewed consent at Privacy Policy version 2026-09-privacy-v68.

Sidebar activity markers (working, Question, successful completion, or failure) and their acknowledgement cursor are content-free local metadata. The desktop app shell continues observing the same authenticated content-free activity signal for eligible nonterminal local chats while another chat or Settings is visible, then reconciles a terminal signal against the exact encrypted chat/run/message identity. This adds no polling, readable event content, storage root, relay projection, recipient, retention period, or deletion boundary. Opening a chat acknowledges the current marker across the paired desktop/iPhone channel; the prompt, response, question text, and checkpoint previews remain in the encrypted chat capsule or encrypted paired snapshot. Checkpoint rails and edge scrubbers are derived locally from already-held user prompts and assistant previews and create no additional transcript persistence.

When you export a conversation, HVAIA asks you to choose a local destination and writes a ZIP containing a Markdown transcript, redacted machine-readable transcript data, and an export manifest. HVAIA builds the ZIP in a private temporary file, streams it in bounded chunks, then atomically replaces the selected destination so a failed export does not delete an existing file. The temporary archive is removed after completion, cancellation, or the next safe startup cleanup. Machine-generated metadata is path-redacted, but the exported conversation text is verbatim and can include a path that you or the assistant wrote. HVAIA does not upload that export automatically. If a chat uses a hosted model, only files or tool results the assistant needs during the staged task may be sent to the model provider under the provider and model settings you selected. A paired iPhone can request a fork or rewind only while its paired desktop is live; the request and resulting chat state stay inside the existing end-to-end encrypted desktop-to-iPhone channel. The iPhone and public relay do not receive the staged project files, source paths, workspace snapshots, or desktop export files.

When you explicitly choose Copy session ID from a regular or project chat’s desktop menu, HVAIA places only that chat’s identifier on your operating system clipboard. Other applications or clipboard synchronization services may access it under your device settings. This action does not copy conversation text or automatically send the identifier to a model provider or HVAIA’s public relay.

On a paired iPhone, you can explicitly choose Share/Export transcript from a chat or Share/Save from a generated-image preview. HVAIA hands the selected transcript or bounded image preview to the iOS share sheet only after that action; it does not automatically upload, relay, or write the item to Photos. The recipient, app, or Photos destination you choose processes or stores the shared content under its own privacy practices. The iPhone Archive view retrieves a compact archived-chat list only while your paired desktop is live, inside the existing end-to-end encrypted device channel. It keeps that list in memory for the open Archive view, does not add archived chats to the active offline chat cache, and does not store the list or its titles on the public relay. These behaviors remain covered by the current Privacy Policy, for which HVAIA’s existing renewed-consent flow asks you to accept an updated version after sign-in.

When you select Plan mode for a chat task, HVAIA stores the latest reviewable plan, its digest, bounded review feedback, and the review decision with that task in the active profile’s local run state. Profile chat state is encrypted at rest; the shared lifecycle database also retains the bounded owner-scoped fields needed for recovery and publication. The plan is not a separate plan.md file and is not retained as a second conversation. After approval, the same durable run performs the implementation; abandoning it leaves the run read-only, and requesting changes keeps execution blocked while a revised plan is generated. If a Plan asks how to access project files, choosing the explicit attached-project option grants that run read-only access only after the local backend revalidates the current chat’s logical project, opaque code-project capability, canonical-folder digest, trusted staged owner, and current staged-root identity. HVAIA repeats this validation when admitting the Plan run, immediately before Plan approval, and before enabling the repository tool; an unavailable, revoked, stale, or mismatched stage is rejected with re-attach guidance and remains blocked. That grant exposes only bounded repository inspection for the managed staged copy and does not grant terminal, connector, or file-mutation access. For a repository-only research brief, every nonempty model candidate is finalized, shown, and persisted in provider order before citation checks. Missing or invalid evidence returns exact structured feedback through the ordinary model loop without a HVAIA correction-attempt limit; the application never withholds a draft or publishes replacement prose of its own. The local staging path used for the grant is transient in-process data and is not returned to the desktop, model, lifecycle events, logs, support reports, paired devices, or the public relay. If the task is mirrored to a paired iPhone, these plan fields remain inside the existing end-to-end encrypted chat snapshot or delta; the public relay receives only routing metadata and cannot read or durably store them.

When you explicitly choose Copy on a Plan review, HVAIA places the selected Plan Markdown on the operating-system clipboard, where other applications on your device may be able to access it. When you explicitly choose Download, HVAIA writes that Markdown only to the local destination you select. Neither action uploads the Plan, sends it to a model or the public relay, or creates another HVAIA-managed copy. These explicit local exports use the Plan content and local-device boundary already disclosed above, so they do not require a new Privacy Policy version or renewed consent.

When you start a Goal, HVAIA stores its objective and durable progress state in the active profile’s local lifecycle database so the same chat can continue after reconnect or restart. The current record can include the goal and run identifiers, objective, objective digest, state version, status, turn count, reason code, safe diagnosis, completion claim, and timestamps. A completed Goal remains current until you clear it or start another Goal. Starting another Goal archives a local, read-only summary containing only its history identifier, goal identifier, tenant, workspace and chat scope, objective and objective digest, turn count, original creation time, completion time, and archive time; it does not retain the Goal journal, prompts, answers, tool activity, or run activity. Explicitly choosing Clear removes the current Goal without archiving it. Completed summaries remain until the owning chat is deleted or the profile or local data is reset. Goal event indexes, logs, support artifacts, and public-relay records contain content-free identity, status, version, and reason metadata only; they do not contain the objective or completed summaries. Desktop loads completed summaries locally on demand. A paired iPhone can request a bounded page only while its paired Desktop is live; the request and response remain inside the existing end-to-end encrypted device channel, and the iPhone keeps the page only in process memory for the open view. The iPhone does not write Goal history to its protected chat cache, UserDefaults, Core Data, Keychain, files, or any other offline cache, and clears it on chat switch, disconnect, unpairing, reset, and app teardown. The public relay cannot read, index, log, durably retain, or queue Goal-history content or its ciphertext. This local retention and live-only paired-device display require renewed consent at Privacy Policy version 2026-08-privacy-v62.

To keep remote subagent status current after a restart, the existing local Gateway run row may retain one opaque backend execution-run binding under the same tenant/workspace scope. On each bound status request, the authenticated local backend sends Gateway only a live content-free helper projection: opaque helper and routing identifiers, profile/mode/attachment/depth, status and version, safe reason, timestamps, and a one-way task digest. It does not send task titles or briefs, messages, results, citations, artifacts, tests, changed files, changesets, full-result pointers, or source/target chat relationships. A failed or unverifiable read is shown as unavailable instead of returning the last cached status as current. The binding is removed with the existing Gateway run/database deletion and profile or device-data reset boundaries. This is an opaque routing field in an existing local retention location, introduces no new external recipient or relay-readable content, and does not require a new Privacy Policy version or renewed consent beyond Privacy Policy version 2026-08-privacy-v63.

After an ordinary Desktop chat or local helper lifecycle event has been recorded successfully, HVAIA may send a content-free copy through its authenticated current-session loopback Gateway so a matching Automation Hook can run. That copy is limited to the event type and source, opaque chat/run/helper/tool or Automation identifiers when applicable, status, timestamp, and a bounded safe reason code. It never includes prompts, user or assistant messages, model output, tool arguments, tool results, notification bodies, credentials, or arbitrary event payloads. A Hook-started Automation stores the same safe trigger description and existing one-way fingerprint with its local run so Desktop can show the connected trigger, execution, helpers, and final outcome; manual and scheduled runs store only their true origin. These fields follow the owning Automation run’s existing retention, hard-delete, profile-delete, and local-reset boundaries, and older runs are not backfilled. Hook delivery failure does not change or expose the originating chat or helper. No readable copy is sent to a model provider, paired-device cache, support report, telemetry service, or public relay. This documents an internal on-device metadata path and adds no new external recipient, content category, storage root, retention class, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

When HVAIA delegates work, one durable local orchestration record keeps the child identity, exact join membership, attachment mode, bounded context references, queue lease, state version, and continuation receipt needed to recover safely after restart. An exact replay recognizes a consumed join from that existing pending/last-resumed/status metadata, returns the original identities, and avoids repeating an already completed source continuation; while the source is still running, HVAIA re-enters the callback because the receipt alone cannot prove it finished. The same profile-local lifecycle data can also contain the private title and task brief, child messages, tool and approval receipts, checkpoints, the exact model-authored result, safe reason, artifact references, changed relative file paths, test evidence, changeset reference, and an opaque full-result pointer. HVAIA does not stop delegated work after a fixed number of model turns or tool calls, does not impose an active-work deadline, and does not truncate the model-authored result to a HVAIA character limit. A long delegation can therefore run longer, make more model or connected-tool requests, use more provider quota, and store a larger private local result than before. Hosted model requests are no longer serialized behind one shared HVAIA provider/model slot, so multiple hosted requests may be in flight at once; provider transport timeouts, rate limits, charges, and service-side capacity still apply, and managed local models still honor their actual local concurrency. Work ends when the model finishes, you press Stop, it is cancelled or interrupted, the provider/runtime fails, or an applicable approval, validation, lease, or safety boundary ends it.

A follow-up or retry keeps whether its helper is attached to the source task or runs independently; visible child chats keep their independent Stop boundary. Existing private local control records retain internal references to the current source request and the new helper attempt. Earlier answers and completed results remain unchanged. The encrypted helper timeline uses separate internal display identities for each attempt, so repeated tool identifiers or identical model text cannot overwrite earlier activity; model-provider response identifiers and actionable approval or question identifiers remain unchanged. During Stop, HVAIA retains the existing task state until its owned execution and work leases settle, including attached helpers still running after an earlier result. Later queued messages remain intact. Reconciliation uses the existing authenticated local run information and does not repeat an action whose outcome is uncertain. These changes add no storage root, external recipient, retention period, deletion boundary, readable relay field, or renewed-consent requirement.

When a delegated run fails, its existing bounded failure diagnosis may also be retained in the same private local result packet and supplied to the exact source run’s selected model provider so it can explain the actual failure. The diagnosis is limited to 500 characters and stays separate from the model-authored answer. This adds no separate store, external recipient, retention period, or deletion boundary. The private field is excluded from content-free activity, Gateway/public-relay projections, logs, support data, and telemetry. It follows the existing chat/profile/device deletion and reset rules and does not require renewed consent beyond Privacy Policy version 2026-09-privacy-v71.

A private steering note remains in the local FIFO until it is claimed with an opaque token and acknowledged after the selected provider returns from a model call, or after the same message identity is durably transferred to an ordinary child run. Failure, cancellation, orderly exit, or restart returns unacknowledged claims for retry. A crash after provider delivery but before acknowledgement may replay a note, but a pre-acknowledgement crash does not silently discard it. The delegated run inherits the source run’s selected provider and model. A generic inline helper is read-only and remains nested in the source chat. A named inline specialist also remains nested, but outside Plan mode it may use only tools already assigned to its specialist pack; existing approvals, autonomy settings, authentication, and safety policies still apply, while Plan mode remains non-mutating. General-purpose work that can change state uses a visible delegated chat with its own ordinary history, approvals, user interactions, and isolated staged-workspace snapshot. A completed visible child’s exact base-bound changeset is sealed and changes the source chat’s stage only after explicit integration; only the source chat’s existing Apply changes action can change the original project. Stopping the source abandons its wait and cancellation-requests active descendants connected through joined inline work; detached inline work and visible delegated chats remain independently usable. Deleting the source without first stopping it abandons the wait without cancelling those children. If an independent child is still running, its local delegation record temporarily retains only the execution payload needed to finish; terminal completion or exhausted-worker recovery then automatically removes that retained task, result, message, receipt, test, artifact, path, and changeset data. Deleting the child removes those readable delegation copies immediately. A surviving source may keep only content-free cancelled/deleted activity with the safe reason delegation.target_deleted; an empty cancellation packet may exist only until it releases an exact pending source join and is removed after resumption. Specialist tool activity delegated from a running chat, including DaVinci activity, continues over the same local parent-run stream. Before an approval or user-input card is shown, the exact child stores the existing pending-control request identity and recovery snapshot in the profile-local lifecycle record; resolution removes the pending snapshot through the existing run lifecycle. Its local event stream is only a relationship-free invalidation cursor containing event/delegation identity, type, status, version, reason, and timestamp. The separately authenticated local detail endpoint may return the source/target relationships and requested result evidence needed to render the activity tree; when a delegated child is viewed, omitted ancestors are re-rooted only in that local view. Gateway and the public relay retain only content-free routing and orchestration facts such as opaque identifiers, selected profile, kind, attachment, depth, status, state version, reason code, timestamps, and a task digest; they do not receive readable titles, task briefs, context, messages, tool results, child summaries, test names, file paths, changeset references, or source/child relationships. The selected model provider processes each child task and model-visible context under the inherited provider choice. Local chat, profile, and device deletion/reset rules remove the retained delegation data, subject to the usual limits of storage media and external backups. The original delegation disclosure required renewed consent at Privacy Policy version 2026-08-privacy-v50. The named-specialist action capability and durable pending-control disclosure require renewed consent at Privacy Policy version 2026-08-privacy-v56; they add no new recipient, storage root, relay-readable content, retention period, or data category.

For an inline helper, HVAIA temporarily journals its real user-visible interim and final assistant text, tool inputs and outputs, approval or user-input cards, and any finalized readable provider-authored reasoning summary in an encrypted sidecar inside the existing source-chat capsule so the activity can be restored chronologically after reconnect or restart. Raw reasoning, system instructions, and private runtime context are excluded. During the live run, replayed records may update the visible in-memory chat while writes to that source-chat capsule are grouped until the helper reaches a terminal or attention state, or the app performs an explicit persistence flush. Only after the desktop has persisted those records into the canonical encrypted chat message does it acknowledge and remove the temporary sidecar entries; a paired-device snapshot is derived from that same durable message and does not depend on the sidecar. The helper’s committed child result is used only for internal delegation continuity: it is not delivered as a second standalone Desktop message or Memory turn. Existing duplicate standalone messages are removed only when their generated child identity matches a helper already nested in the same source message, and existing duplicate Memory rows are removed only by that child’s exact publication identity before derived indexes are refreshed. A paired iPhone can retain the same helper assistant segments, tool records, and finalized readable summaries in its existing pair-scoped file-protected chat cache only after they cross the existing end-to-end encrypted device channel. The public relay and plaintext lifecycle database receive only content-free invalidation and orchestration metadata, including the existing reasoning_present projection, and cannot read or durably store the helper text, summaries, tool inputs, tool outputs, or decisions. The local lifecycle record may also retain content-free run-start, first-output, finalization, and exact provider output-token-count metadata so Execution Time and tok/s can be restored after reconnect or restart; when exact usage or first-output timing is unavailable, HVAIA marks the recovered rate as approximate. Deleting the source chat, deleting or resetting the profile, or resetting device data removes the sidecar and lifecycle metadata with the existing chat capsule and run cleanup. A visible cross-chat delegation remains isolated, and the source interface shows only its creation/status and an Open action rather than child content or management controls. Readable provider summaries use the existing encrypted chat and paired-iPhone end-to-end encrypted path; they introduce no new recipient, storage root, relay-readable field, retention boundary, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

The Desktop Sub-agents pane can show existing private local delegation status, saved result excerpts, diagnoses, reported changed-file paths, and reported test outcomes when you select an attempt. It reuses the current chat and delegation information rather than creating another stored copy or requesting new model output. Back/Forward keeps only temporary page identifiers in the current app process; these are cleared on profile/chat change or app exit. Opening a delegated chat uses the existing local chat access checks. This presentation adds no collection, external recipient, logging, retention period, synchronization field, or renewed-consent requirement.

After delegated work begins, HVAIA may stop the live parent response connection while the parent run continues locally. To keep every real parent tool call visible, the Desktop follows a content-free local wake and reads only new events from that run’s existing authenticated durable journal. New events may retain their exact occurrence time; historical events are not backfilled or assigned a new time. The wake contains only an opaque event/run identity, event type, state version, and timestamp—never a tool name, call id, title, arguments, result, terminal output, or assistant content. Desktop merges those model-issued calls and results into the same encrypted chat message and stores only the last applied event sequence there, then performs one final merge before Stop or normal cleanup. It does not poll while nothing changes. Visible delegated child chats use this same local update path even when they have no sub-agents. Their notifications add only the existing opaque delegation identity, so each child receives its own approval, progress, and completion updates. Tool details and the final answer are still read through authenticated local APIs and checked against the existing run and publication records. Parent and sibling subscriptions do not receive that child timeline notification. A paired iPhone may receive the recovered calls only inside the existing end-to-end encrypted chat snapshot and may keep them only in its existing pair-scoped protected cache. The public relay, logs, support reports, telemetry, and content-free event stream receive no readable parent tool content or replay cursor. Chat deletion, profile deletion, device reset, unpairing, and scope rotation use the existing cleanup boundaries. This introduces no new recipient, storage root, relay-readable field, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

For reliable ordinary-task recovery, a new local run may store one opaque identifier for the exact user-message row that started it. A direct send persists that row before admission. A persisted queued prompt instead reserves a deterministic row identity; if HVAIA exits after backend acceptance but before the transcript flush, the retained queue anchor reconstructs that same row rather than inventing a prompt owner. HVAIA does not derive or backfill the identifier for older runs, does not add it to model input, and rejects a retry that tries to bind the same accepted work to a different row. An authenticated current-session Gateway may forward it to the local backend during initial admission, but Gateway run state, notifications, events, control views, logs, support reports, telemetry, and the public relay do not retain or expose it. During recovery, Desktop combines the chat state captured before its read, the latest local state, and the authenticated incoming history so concurrent local additions, edits, and deletions are not lost. If the exact user-row binding is present, the recovered assistant task attaches to that row. If a versioned task has no prompt owner, Desktop may create only a content-empty assistant task shell with the exact run and assistant identities and empty answer, reasoning, tool, and event fields; it does not invent or copy a user prompt or assistant answer.

If an approval is still pending after the live execution owner is gone, the same existing local lifecycle checkpoint may retain the exact model tool name and arguments, internal and provider call identities, display and phase titles, and preceding public assistant content needed to record that unexecuted tool call as superseded when you steer the task. The recovery-only model alias, raw model-argument copy, provider-call identity, phase title, and preceding assistant-content copy remain in the owning local run and are not added to event/control projections, notifications, support data, logs, telemetry, paired-relay routing, or public-relay state. The internal call identity, model-authored display title, and approval-card details continue to follow their pre-existing authenticated local lifecycle and encrypted-chat presentation contract; this recovery path creates no additional shared copy of them. Its new Steer capability contains only opaque approval-request, state-version, and assistant-message preconditions, while the existing approval card keeps its ordinary local decision details. Stop, Approve, Deny, and recovered Steer compete through one exact local compare-and-swap, so only the first valid action changes the run; a winning Steer invalidates the approval without treating it as approved or denied and resumes from the new instruction. An older pending approval without complete provider-valid recovery context remains Steer-disabled but can still be stopped through its authenticated pending-run identity. The opaque message binding, recovery merge, empty task shell, private approval context, and control receipt use the already-disclosed local lifecycle database and encrypted chat capsule, follow the existing run/chat/profile/reset deletion boundaries, and add no new data category, recipient, storage root, retention class, relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v67.

When HVAIA uses chat administration, search returns only a bounded profile-scoped sidebar projection, while create, fork, rename, pin, archive, and open changes use the authenticated local command service. Creating another chat in an attached project first checks that the source chat has no live or paused run; if it does, HVAIA writes no target chat or staged clone and shows an actionable local message naming the source from its already-held title. The backend error remains generic, and the title or source history is not added to the request, error, support data, or relay state. Chat administration cannot start or control delegated work. The active model instead uses the dedicated delegation service, which binds every child to the actual local source run and tool-call identity rather than accepting a browser-supplied run identity or a model-selected provider. A visible delegated chat can store its model-authored title and task brief, a local source/target lineage record, and an exact terminal result only after that child’s run commits it. It never copies the full source transcript or fabricates an assistant response. If chat creation, workspace cloning, dispatch, or publication fails, HVAIA records a truthful durable failure so replay cannot duplicate the child; a new attempt uses a new request identity. Deleting the source does not delete an independently running child, but automatically removes its temporary delegation payload after it becomes terminal. Deleting the child immediately removes its readable delegation payload and leaves a surviving source only content-free terminal/deleted activity needed for truthful status. That deleted activity can be listed but cannot be steered, retried, followed up, interrupted, or detached. The source chat and its paired-iPhone snapshot show only the visible child’s creation/status and Open action; the child chat retains its own readable content and evidence inside the existing end-to-end encrypted chat path. The public relay receives no readable title, task brief, summary, relationship, test, file path, or changeset reference. These encrypted records are removed with normal chat, profile, or device deletion, subject to the usual limitation that local storage media and external backups may retain forensic copies. This clarification adds no recipient, retention period, or readable relay exposure.

When you attach a local code project to a chat, HVAIA stores its selected root, full canonical-folder digest, logical-project owner, opaque code-project identifier, staged-root identity digest, and trust state in protected local profile state. Code diagnostics, definitions, references, symbols, hover results, and formatting diffs are produced by local language-server processes. A hosted model may receive the bounded result needed to answer your request under the provider choice you made, but only after those ownership proofs agree; a mismatch sends no project result to the model. The language server itself is not a hosted service. Absolute paths, raw LSP frames, source snippets, diffs, and language-server process output are not written to lifecycle events, replay records, support reports, telemetry, or the public relay. Formatting writes only after you approve the exact previewed diff. This clarification adds ownership metadata to the existing encrypted local attachment binding; it adds no recipient, readable relay exposure, or retention period.

For startup reliability, HVAIA creates an opaque per-session runtime identifier and keeps it in process environment and local lifecycle diagnostics so source and packaged processes can be matched to the current app session during startup and shutdown. This identifier contains no chat content, credentials, or personal information and is not a public-relay content record.

Before the desktop shell is available, the source/development launcher may append a startup-blocked line to source-dev-launcher.log in the active local source log directory. The line contains only a fixed, user-safe failure reason and recovery instruction; it does not record environment values, repository paths, user content, credentials, or secrets. This log stays on the device, follows the source log directory’s deletion/reset lifecycle, and is not sent to a model provider, public relay, connected service, or another device.

The gateway edge may receive, for the current session only, the purpose-specific wake_up local-service identity/token and local API token through the authenticated loopback bridge. In source/development sessions, Rust owns the public loopback listener, bounded WebSocket framing, connection/authentication sequence, admission, presence, cursor, replay policy, and edge child lifecycle. The listener forwards validated traffic only to a separate private Python business listener on this device; Python retains token validation, JSON-RPC business methods, payload handling, and repositories. Frames are held only while they are forwarded and are not logged or retained by the Rust listener. The packaged app keeps its existing listener behavior in this phase. These values are not durable credentials and are not sent to the public relay, model providers, or connected services.

The desktop-owned gateway edge listens only on this device in both source/development and packaged apps; it is not exposed to the same Wi-Fi or another private network. iPhone connections use hosted Anywhere Access over the internet. User content sent through that route remains protected by the end-to-end encrypted, content-blind relay contract described below.

When a developer stops a source session from the terminal, the launcher may create one empty, content-free shutdown marker in a private operating-system temporary directory so the Rust shell can close its owned services before the development toolchain exits. On macOS that same directory also holds a small current-launch receipt containing a random launch nonce, the HVAIA Dev process identifier and its operating-system start time, plus a bounded startup result containing that nonce and only a ready or failed status. These let the launcher report an unsuccessful startup and verify the exact app before stopping it after a shutdown timeout; they do not adopt another running app. The temporary directory and files are removed when the launcher returns. These files contain no user content, credentials, path inventory or diagnostic payloads, and none is sent off the device.

Local Vault may also be started and stopped by the Rust shell through the authenticated loopback bridge. The lifecycle part of that bridge carries only bounded startup metadata, with the non-secret child environment limited to the configured loopback Vault address; it does not forward arbitrary ambient parent values or carry Vault tokens, unseal keys, OAuth credentials, or user content. A separate authenticated, current-session credential capability is limited to reading, writing, or deleting the active identity’s unseal_key and runtime_token. The native HVAIA desktop process alone uses the operating system’s credential store; Python does not call Keychain, Credential Manager, or Secret Service in a desktop session. Only the requested bootstrap value crosses the loopback capability transiently so Python can initialize, seal or unseal, and validate local Vault, and so the local backend can perform a request-time Vault access check. The capability does not accept a service name, arbitrary account, or ambient environment value, and its values are not logged, placed in status/events/errors, retained by the bridge, sent to a model provider, relayed, or shared with another device. Rust supplies a small cross-platform process baseline such as system path, locale, temporary-directory, certificate, and proxy settings. Secure-storage startup fails closed if either advertised bridge is unavailable.

HVAIA may check the macOS Keychain’s non-secret lock status on this device to distinguish an existing Vault item that needs authorization after an app-signing change from a locked Keychain. That status is used only in memory and is not retained or sent off the device. Access to a protected existing item still requires the existing HVAIA explanation and macOS authorization; denial does not reset or replace your Keychain entries.

For a clean installation with no local Vault data or bootstrap receipt, HVAIA creates new Vault bootstrap entries automatically in the background without requesting access to entries left by a removed installation. One small, owner-only record under the active Vault root’s native-bootstrap directory keeps a random installation identifier, source/development or packaged mode, schema version and a one-way digest of that root. It contains no secret, raw path, profile identity or user content, and is never sent off the device. It persists with the Vault across restarts, updates and ordinary local-data reset, with no automatic expiry. Removing the complete Vault root removes this record; the next installation uses new entries and leaves orphaned operating-system entries untouched. A damaged or mismatched identity stops secure-storage startup without resetting existing data. This change adds only local operational metadata within the existing Vault root and no external recipient or consent purpose.

The core local backend HTTP process may also be started, observed, and stopped by the Rust shell through that same current-session bridge. The backend handoff carries only the fixed policy, Vault, local-service-routing, and gateway-token environment names required to serve the current desktop session, plus separate ephemeral loopback handoffs for typed terminal command start/write/cancel/resize/close operations and isolated local code-intelligence process operations. Each handoff is capability-limited: the terminal handoff cannot manage the backend or start code services, the code-intelligence handoff cannot run terminals or manage services, and Rust rejects either token for every unrelated operation. The terminal handoff carries only the terminal command, agent input, output, and bounded identities needed for that local terminal operation; it does not carry unrelated prompts, assistant prose, connector data, or arbitrary ambient secrets. The other process-control handoffs do not carry chat content, prompts, model output, connector data, or arbitrary secrets. Python continues to own the backend API, readiness, and semantic/data operations while Rust owns terminal and language-server process groups. Source and packaged desktop sessions treat a missing or malformed required handoff as runtime_control_unavailable and stop rather than creating a second process owner. Automated harnesses provide an explicit fake Rust owner; they do not activate a production Python subprocess fallback.

Packaged desktop startup also creates opaque local-service authentication tokens used only between the current desktop shell and its owned local runtime. The tokens are kept in the mode-specific HVAIA app-state directory, are reused across that mode’s restarts, and are protected for the current operating-system user. Concurrent packaged launches converge on one existing token rather than replacing it; HVAIA repairs malformed content only after locking and revalidating the same privately owned file, while a symlink, reparse point, hard link, wrong owner, or unsafe parent stops startup without replacement. Token values and token-file paths are never logged or sent to HVAIA’s public relay, model providers, connected services, or another device. Packaged local-data reset deletes these packaged token files; source/development reset does not. Source/development and packaged sessions use separate token files and separate runtime ownership locks so one mode cannot authenticate as or replace the other. During a desktop session, managed local speech, the selected local chat model, the dedicated local embedding or extractor model, the optional managed Automation MCP worker, the managed Google MCP worker, the optional managed Internet MCP worker, the Telegram gateway worker, or the Automation scheduler/runner workers may use an ephemeral loopback control token and worker receipt so the Rust shell can own the Qwen3-ASR, Chatterbox, llama.cpp, embedding, extractor, Automation MCP, Google MCP, Internet MCP, gateway, scheduler, or runner child while Python performs their bounded semantic and readiness work. Google MCP receives only fixed public startup metadata and the in-memory Vault-derived JWT signing key; the Google OAuth client secret is never passed through this bridge. The gateway worker receives only the purpose-specific in-memory telegram local service identity and token, and the runner receives only the purpose-specific in-memory automation local service identity and token needed for authenticated backend calls; those values exist only in memory for that session, are not durable credentials, and are never logged, relayed, or sent to a model provider. Opening a local file or external web link in the desktop is handled directly by separate on-device Rust components; HVAIA does not send the file path or URL to its Python backend as a fallback. Computer Use uses the separate private native boundary described below and is not a managed MCP worker. For Computer Use, Al-Jazari’s one direct tool reaches a dedicated Rust-owned native manager over a current-session, owner-only Unix socket. A random per-launch capability is transferred through an inherited one-read pipe, held only in process memory, and never written to a command line, settings, logs, events, support data, or the public relay. Rust owns app identity, state generations, app authorization and consequential-action receipts, cancellation, action IDs, deadlines, and native execution in both source and packaged sessions. An execution request can transiently include the exact app target, coordinates, key operation, or text needed for that action, but those values are excluded from local diagnostics and the action ledger. The ledger keeps only opaque identities, one-way fingerprints, outcome classes, and timing for the run plus a 15-minute crash-recovery window so a possibly completed action is not repeated. The Python backend validates the model-facing request and attaches an authorized app image to the selected model, but it does not inspect the desktop or execute an alternate native path. A missing broker or capability fails closed. This direct native-control and outcome-safety contract requires renewed consent at Privacy Policy version 2026-08-privacy-v58. Any expansion of Computer Use collection, retention, recipients, or deletion behavior beyond Privacy Policy version 2026-08-privacy-v58 requires another policy review and version change.

Computer Use now reuses the exact original user instruction from the authenticated originating chat when handing work to Al-Jazari in a runtime where Computer Use is enabled and available to the selected model. The extra instruction copy is limited to 64 KiB of UTF-8 text, kept only in the current invocation, and sent only through the already-selected model-provider path. A missing, ambiguous, cross-profile, or oversized instruction stops that delegation rather than silently dropping restrictions. Runtimes without available Computer Use tools do not load this extra copy. This copy excludes attachments, hidden provider context, and other chat messages; it creates no separate instruction store, native-helper payload, log, support record, or readable relay copy. Existing explicit child steering and cancellation remain in place. If an action may have happened but cannot be verified, the model’s explanation is retained through the existing private chat/run boundaries as a failed, uncertain result, without a successful publication or automatic replay.

After a Computer Use image is securely read for the selected model, its native temporary handoff is deleted. A later native cache eviction or task cleanup accepts that already-deleted file as clean; other deletion failures remain errors. At Computer Use task termination, the native owner closes the exact task context, quiesces only its capture, and removes every capture in its exact private temporary scope, including files whose helper responses were lost. If context cleanup cannot be confirmed, it fences admission and retires the shared owned helper only after settling every affected context; sibling captures are then interrupted truthfully rather than silently reused. An empty session directory may remain for the persistent helper and is removed at shutdown; it contains no screenshot content. Cleanup failure blocks unsafe reuse until cleanup succeeds, and the existing owned-crash cleanup remains available. Capture limits count unacknowledged files as well as returned images. Application references remain in bounded current-session memory across searches; no persistent catalog is added. The floating in-app current-screen preview follows the owning task while you navigate. Its document-viewer action uses only the selected frame’s in-memory bytes and does not persist them; explicitly saved evidence still goes only to that task under the current profile. During delegated Computer Use, the backend keeps only the latest active display state for each invocation in memory: app display name, opaque icon reference, Viewing/Controlling/Paused state, start time, bounded reason code, and opaque owning task identifiers. It sends that state only to the authenticated local Desktop under the matching profile, account, tenant, workspace, and source task, and removes the snapshot when the invocation closes. This transient presentation does not enter durable delegation history, logs, support data, another device, the model, or the public relay. These repairs enforce the existing data categories, selected-provider sharing, local storage, retention and deletion promises; they add no external recipient, storage root, telemetry, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

When you ask Computer Use to find or open an app, its signed macOS helper searches only the standard user and system Applications folders within fixed entry and depth limits. During that request it reads app names, bundle locations, running state, and code-signing identity so it can exclude protected, unsigned, or differently signed software. The searchable catalog, bundle locations, and signing details remain only in current-session process memory; HVAIA does not add them to settings, chat history, logs, diagnostics, support data, another device, or the public relay. The selected model receives only bounded matches containing a display name, opaque session app reference, running state, authorization state, and optional opaque local icon reference; that reference contains no bundle path or icon pixels. For desktop presentation only, HVAIA can redeem a valid current-session icon reference through the same native helper into one metadata-free 32-by-32 PNG. The resolved icon pixels remain only in current desktop-process memory and are not sent to the selected model, written to disk or settings, stored in chat or run history, logged, included in diagnostics or support data, copied to another device, exposed to the public relay, or sent over the network; an invalid, expired, oversized, or malformed result is discarded and the interface keeps its letter fallback. Opening revalidates the exact signed app before asking macOS to launch it. Computer Use returns pixels, structured text, and actionable controls only for the focused or explicitly selected window of an authorized app. Other windows of that app contribute bounded title/focus summaries and a secure-field-presence check so a protected field elsewhere cannot be bypassed; their pixels, ordinary text, and actionable controls are not returned. To coexist with your own work, the helper also keeps only current-session, content-free input-activity facts such as the target process, an event serial, and timing. It does not retain keys, typed text, pointer coordinates, or clipboard content from that activity check. Background-safe actions avoid taking focus; actions that need focus borrow it briefly and restore the prior app only when that app is still the safe current choice. The installed-app discovery, selected-window, and cooperative-input data uses require renewed consent at Privacy Policy version 2026-08-privacy-v60; local icon-pixel collection and presentation require renewed consent at Privacy Policy version 2026-08-privacy-v64. Any later expansion of Computer Use collection, retention, recipients, or deletion behavior beyond this version requires another policy review and version change.

Source-build release qualification can also compare content-free process identifiers and SHA-256 bindings for the signed development app, its Rust-owned backend child, launch contract, and exact source module. Those facts travel only through the authenticated loopback qualification API and current-session private Runtime Control bridge, remain in process memory, and are not exposed to a model, saved in chat or diagnostics, included in support data, sent to the public relay, or shared with an external recipient. The packaged app does not produce this source attestation. This adds no durable data, external recipient, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v58.

App discovery narrows candidates using app names and bundle metadata before reading and validating their signing identities. Missing bundle identifiers still require signing lookup. Every returned match and app opened remains subject to the existing signature and authorization checks. This reduces unnecessary local signing-data collection without adding a storage location, recipient, retention period, or renewed-consent requirement.

The same dedicated policy token may be present, for the current session only, in the gateway edge and Automation scheduler/runner child environments because those children perform content-free gateway admission and scheduler policy checks. Rust validates the allowlisted handoff and rejects it for other child types; full lifecycle-control credentials, prompts, instructions, model output, connector data, tool results, attachments, publication bodies, and secrets do not cross this boundary. If the policy handoff is missing or malformed in a Rust-owned session, the affected operation stops with runtime_control_unavailable rather than selecting a second Python policy owner. This adds no relay, provider, telemetry, or durable storage path.

For durable prompt-run lifecycle changes, the backend may send Rust only the current and target status, the expected/actual state-version values, and whether the separate publication transaction has committed. During an approval resolution it may also receive only the opaque pending-request identifier, matching request identifier, and approval bit so Rust can reject a stale or swapped resolution. For the current-session approval claim fence, Rust may retain those bounded opaque identifiers plus the expected state version in process memory for up to 30 seconds, then releases them on commit or rollback; this is not durable storage and contains no prompt, response, event, or tool content. Rust validates the finite transition and approval-binding policy; Python continues to write the local lifecycle database, events, checkpoints, and publication records. Prompts, messages, attachments, assistant output, evidence payloads, and secrets never cross this policy boundary, and an unavailable advertised bridge rejects the lifecycle change.

Desktop approval cards show the bounded information needed to decide whether an action may proceed: a plain-language purpose, expected effect, reversibility guidance, risk, and the exact target path for a filesystem mutation. They do not display or place in accessible approval content raw internal tool identifiers, argument JSON, shell command text, or LSP/process/protocol details. Showing a target path on the approving desktop is presentation only; it does not create a new collection, storage, transmission, recipient, logging, or retention path.

For the final publication step, Rust may also write only the bounded run id, assistant-message id, state version, lease expiry, and SHA-256 content digest to a short-lived rust_publication_claims table in the existing local lifecycle database while Python performs the durable publication transaction. The digest is not reversible content and Rust never receives the assistant text, event payload, evidence, or publication receipt body. A duplicate or mismatched current-session claim is rejected; commit and rollback delete the claim, and an abandoned claim expires automatically after 30 seconds. This table is local HVAIA metadata, is removed by lifecycle reset with the database, and is never sent to the relay, a provider, or another device.

For a user-requested run cancellation, the full source/packaged desktop session may send Rust only the existing local lifecycle database path, bounded run id, expected state version, target status, event kind, normalized reason code, and timestamp. Rust atomically updates only the indexed lifecycle status/version, bounded continuation/finalization metadata, and a finite reason-code event in that existing database; it does not create another storage destination. The operation contains no prompt, reason prose, event payload, response, tool data, attachment, or secret. Python remains the semantic executor and raw chat-event projection owner. A missing or malformed bridge, database, or schema fails closed in source and packaged desktop sessions; automated harnesses must use an explicit fake Rust owner and cannot activate a Python lifecycle path for this migrated boundary.

Finishing Computer Use normally disables its input and preview without cancelling the chat. Its native session temporarily distinguishes normal cleanup from Stop; this adds no screenshot, command log, storage destination, or recipient. If a stopped specialist exits during finalization, HVAIA reconciles the existing local run/delegation status after its owned work settles. Recovery does not resume the stopped task or turn a cancelled result into a successful answer.

For scheduled Automations and Scheduled tasks, the authenticated policy bridge may also receive only content-free admission and recovery facts: whether another run is active, the autonomy guard bit, bounded attempt counters, retry-delay configuration, the current run-status token, and a configured lease duration. Rust returns only a bounded scheduler decision and optional delay. Scheduled due-time admission and queued-run lease checks use the same content-free path; the Scheduled-task instruction, session messages, model output, publication, and trace remain local to Python’s semantic and durable owners. Prompts, instructions, assistant output, tool results, connector data, attachments, publication content, and secrets never cross this policy boundary. Python remains the sole semantic executor and publication-content owner; Rust may own the bounded desktop Automation/Scheduled-task lifecycle transaction described below; an advertised bridge failure rejects the scheduler or Scheduled-task action rather than falling back to a second policy owner. If a source or packaged session is marked HVAIA_RUNTIME_OWNER=rust-tauri but the narrower policy handoff is missing or malformed, HVAIA reports runtime_control_unavailable and stops the tick/claim/outcome/recovery operation. This adds no relay, provider, telemetry, or new durable storage path.

For non-persisted harnesses, before the Automation or Scheduled-task runner claims a queued run in Python’s local repository, Rust may hold only the opaque run id and current-session worker id for up to 30 seconds. A duplicate worker claim is rejected; the lease is released after the repository claim commits or rolls back, and an abandoned lease expires automatically. No schedule instruction, prompt, model output, tool result, connector data, or secret enters this fence.

Before an Automation scheduler creates a due run or advances its next-run time, Rust may hold the opaque Automation job id and current-session scheduler worker id in the same short-lived fence. The fence is released only after Python’s schedule/run mutation commits or rolls back; schedule expressions, instructions, run history, and all other user content remain in Python’s local store.

In a full Rust-owned desktop session, that due tick may additionally use the existing local SQLite database path as operational handoff metadata. Rust does not create a second database or log the path, and it receives no schedule expression, instruction, prompt, run history, model output, connector data, or secret. Rust rechecks the scoped due row and expected version, then atomically writes only the run’s fixed status summary/identifiers and the next-run/version metadata. Python still owns execution, attempts, retries, dead letters, publication, and user-facing content. A stale/not-due tick performs no write; database, schema, authorization, or transaction failures fail closed. This uses the existing local Automation store and adds no relay, provider, telemetry, retention, or sharing destination.

For a queued or retryable Automation run in a full Rust-owned desktop session, Rust may also use the existing local SQLite path to atomically claim the exact scoped run for the current worker and write its short lease timestamps. It receives only opaque identifiers, bounded status/time metadata, and the lease duration; it does not receive prompts, instructions, model output, connector data, attempts, traces, publication content, or secrets. Python continues to execute the run and write attempt, retry/dead-letter, publication, and user-facing outcome records. A stale, duplicate, invalid, or unavailable claim fails closed and adds no new storage, relay, provider, telemetry, or sharing destination.

For the same queued Automation run, a full Rust-owned desktop session may use the existing local SQLite path to commit one content-free outcome or recover one stale lease. Rust receives only scoped opaque identifiers, a bounded attempt and status code, retry timing, worker/lease metadata, execution/publication ids, runtime/trace references, and the materialization metadata needed to tell an already-finished publication from an unfinished run. It atomically writes the attempt’s bounded reason metadata, run status/version/lease, retry or dead-letter state, and job failure counter; stale recovery either finalizes an already-materialized publication or requeues/dead-letters within the configured budget. Prompts, instructions, assistant text, connector payloads, tool results, attachments, publication bodies, and secrets never cross this bridge. Python remains the model/tool executor and publication-content owner, and the operation adds no relay, provider, telemetry, or additional durable storage destination. Invalid scope, ownership, schema, materialization, or database state fails closed so a run is recovered later rather than written twice.

For a queued Scheduled-task run in a full Rust-owned desktop session, Rust may use the existing local SQLite path to atomically create a due run plus its next schedule, claim the scoped run, and later commit its bounded terminal status, error code, execution/publication references, trace reference, next-run time, and Scheduled-task state version in one transaction. Rust may also mark an expired running Scheduled task as interrupted and move its schedule to needs_attention without reading the instruction or session content. Python continues to read the selected instruction file, execute the model/tools, materialize the committed publication, and write only the user-facing summary after Rust commits lifecycle metadata. No prompt, instruction, assistant text, tool result, connector data, attachment, publication body, or secret crosses this bridge, and no relay/provider/telemetry destination is added.

For the current desktop gateway session, the source/development Rust listener holds each inbound or outbound frame only long enough to enforce the bounded wire limit and forward it to or from the private Python business listener. It does not persist, log, index, or replay payload content. The authenticated loopback policy bridge may receive only bounded routing metadata: an opaque connection id, tenant/workspace/session identifiers, client kind and capability names, a content-free event-cursor flag, and a reconnect cursor. Rust retains only the current-session binding receipt and replay-floor metadata; it never receives or stores WebSocket tokens, prompts, messages, attachments, event payloads, or connector data. Rust owns the source WebSocket transport boundary and rejects duplicate bindings, receipt mismatches, and stale replay cursors; Python remains the private authentication/business handler and content repository. If the advertised policy bridge is unavailable, binding fails closed and a reconnect requiring reconciliation is reported without exposing event content. If a WebSocket transport fails before normal cleanup runs, HVAIA retains only the bounded connection receipt until the current session releases it, so a dead desktop is not left advertised as an active broker target. No event body, prompt, token, or connector data is retained for this cleanup.

For hosted iPhone pairing, the same current-session Rust policy bridge may receive only account, tenant/workspace, device, desktop-host, and iPhone key identifiers. Rust keeps an in-memory active-binding receipt and key epoch so a replaced or revoked pairing cannot authorize an encrypted publication. Python continues to persist the trust record and carry the content-blind relay transport. Refresh tokens, private/public-key material, ciphertext, prompts, messages, and workspace content never cross this policy boundary; a bridge failure or binding mismatch rejects pairing, revocation, or publication instead of falling back to a second owner.

HVAIA is not local-only. If you choose hosted AI models, hosted speech, hosted embeddings, internet search, connected accounts, updates, support reports, or iPhone Anywhere Access, HVAIA may send the specific data needed for those features to the relevant provider or HVAIA-hosted service.

For reliability, HVAIA can also store local retry, idempotency, state-version, and user-activity metadata for app actions such as Scheduled edits, Automation run approvals, status changes, and manual runs. Scheduled sidebar preferences can store bounded non-content timestamps for pin and unpin actions so the most recently organized item stays easy to find. Guarded Automation run history can locally record that a run is waiting for approval, approved, skipped, or denied. This metadata is used to avoid duplicate mutations, stale overwrites, and background-run sidebar reshuffling; it stays in local app storage and is not a public-relay content mirror.

When a Wake Up run finishes, its result and task state are saved together in the existing local task database. An active task keeps the scheduler’s latest next-run time, while a task becoming completed, paused or needing attention clears that time. This prevents an older run from overwriting newer scheduling metadata. It adds no data category, storage location, recipient or retention period and uses the existing task-deletion and local-reset boundaries.

When you send another prompt while a chat response is still running, the desktop stores that queued prompt locally until its run is accepted or you edit, delete, or remove the chat. The local queue record can include the prompt, attachment data or references, the selected submission options, client and assistant acceptance identifiers, ordering and status, and version timestamps. While an attachment remains in that encrypted queue row, an authenticated Open in Files action for the exact owning chat may resolve it and create the same owner-only, current-process temporary plaintext materialization used for another pathless chat attachment. It is removed on tab, chat, profile, or orderly app cleanup, is never relay state or independent read authority, and requires Save As to create a user-owned copy. Each chat accepts at most 32 live queued items and 64 MiB of retained queue payload; if either limit is reached, HVAIA keeps your unsent prompt and attachments available so you can remove an item or wait for one to finish. If you explicitly choose Steer, the active local run keeps that instruction in its private durable run record only until the next safe model boundary, then adds it to the local conversation and continues the same run. The status events used to move the interface to the next assistant message contain identifiers and mode/model metadata only—not the steer prompt, attachments, or partial response. The desktop can retain a one-way request fingerprint derived from the submission on the accepted local user turn, and the local backend can retain a corresponding fingerprint with its durable run receipt, so a conflicting reuse of the same acceptance identity is rejected. For an attachment, the encrypted local draft or queue capsule may retain a one-way SHA-256 content digest alongside the existing attachment metadata so HVAIA can reuse that fingerprint without repeatedly processing its encoded bytes on the interface thread. The digest is not file-read authority, is not sent to a model, support report, log, public relay, or another recipient, and is deleted with the same chat, profile, or local-data-reset boundary as that attachment. This lets HVAIA preserve the exact submission across restart, avoid duplicate runs, and dispatch prompts in order. A paired iPhone may also retain the latest authoritative queued-prompt text, ordering, and status received through the end-to-end encrypted chat response in its existing pair- and workspace-scoped protected local chat cache so the queue remains visible after restart. That cache uses iOS file protection until the device’s first unlock and is removed on chat deletion, unpairing or pairing replacement, scope/profile reset, or device-data reset. It contains no queued attachment bytes, attachment digest, retained-byte total, or durable queue-mutation outbox. When a Desktop queue record becomes dispatched or deleted, HVAIA removes that row from the encrypted chat capsule. Accepted transcript publication and removal of that row use one conflict-safe local scoped mutation; exact terminal recovery may reconstruct the deterministic queue user row but does not send the accepted request to the model again. A connector queue may instead retain a terminal Gateway tombstone; that tombstone clears readable prompt text, attachments, Deep Research and autonomy choices, source-message/history boundaries, and any attachment digest retained only with those fields. These active readable queue records and short-lived same-run steering records remain in the desktop’s local storage; neither is stored as a readable or durable encrypted queue by the public relay. The authenticated Files materialization, atomic handoff, and recovery clarification use the existing local storage, recipient, retention, and deletion boundaries, so Privacy Policy version 2026-09-privacy-v85 remains current.

Prompt-run lifecycle, finalization, event, evidence, and publication records are stored transactionally in the active profile’s local HVAIA data. Lifecycle replay snapshots may use a compressed local representation to reduce repeated-content disk use and secure-deletion work; this does not change what they contain, how long they are kept, or who can access them. Cancelling a run or abandoning its pending Plan review releases that run’s execution ownership and clears any still-pending approval, user-input, or Plan-review snapshot; dismissing the resulting timeline notice changes only the local presentation of that terminal event. Evidence records contain bounded tool-result summaries and reason codes, canonical/wrapper tool identity, mutation classification, and explicit artifact or catalog digests when available; HVAIA stores them with the related lifecycle update rather than in a separate evidence file. Gateway routing projections retain only routing metadata and do not durably copy prompt text, conversation messages, attachments, or uncommitted assistant output. Gateway retry protection stores only opaque hashes of the retry key and request digest, never a second durable prompt copy.

For self-healing reliability, the same local lifecycle record and journal may retain one current content-free recovery episode plus observation, action, and resolution events. These records are limited to opaque correlation and episode identifiers, bounded reason and capability codes, failure class/category, dispatch phase and outcome certainty, retry disposition, an allowlisted recovery-action name, health state and epoch, occurrence count, verification result, and timestamps. They never include prompts, answers, reasoning, tool arguments or results, terminal output, URLs, file paths, application or window names, credentials, response bodies, raw exceptions, stack traces, or the private fingerprints used transiently to recognize a repeated failure. Successful recovery clears the current episode after recording its bounded resolution; historical events remain with the owning run and are removed with normal run/chat, profile, or device-reset cleanup. Gateway, public-relay, support, and paired-device projections may receive only the content-free recovery status already permitted for their authenticated scope; HVAIA adds no remote reliability telemetry.

If Desktop cannot process a live run event, it stores only fixed content-free markers for the processing phase, authoritative reload phase, and recovered run status. It does not place the failed event payload, raw exception, stack trace, prompt, or answer in those markers. Desktop reloads the exact local run, chat, and assistant-message authority; successful reload uses the existing local lifecycle and encrypted chat records, while a failed reload shows only a safe local diagnosis. These recovery markers follow the same run/chat, profile, and device-reset deletion boundary and add no external recipient, public-relay-readable content, storage root, retention period, or renewed-consent requirement.

In assist mode for mechanical recovery, and in every recovery mode for exact-empty model continuation, HVAIA may give the selected model one replaceable private recovery-context block containing the bounded failure and capability facts above, an automatic-action receipt when one exists, the occurrence count, and allowlisted next-action names. A local selected model processes it on the device; a hosted selected model receives it under that provider’s ordinary prompt-processing disclosure. The block is informational context, not assistant text, and replaces the prior block instead of accumulating. It is never published, spoken by text-to-speech, added to Memory, copied into support content, or exposed as readable public-relay content. This local retention and selected-model context require renewed consent at Privacy Policy version 2026-08-privacy-v59.

Every non-success tool result sent to the selected model may also carry the same bounded failure class, category, reason, phase, outcome, retry disposition, capability, safe diagnosis, runtime-action names, and model-remediation fields. HVAIA replaces raw adapter error prose with a safe diagnosis for that model-facing result while retaining only bounded compatibility codes and safe structural facts. This travels through the already disclosed selected-model tool-result flow; it creates no new recipient, storage root, remote telemetry, retention period, deletion boundary, or public-relay-readable content beyond Privacy Policy version 2026-08-privacy-v61.

Automatic runtime incidents also use a profile-local problem_fingerprints.v1.json index beside local support tickets to coalesce recurring copies across backend restarts. Each entry contains only an opaque problem identifier, first and last observation times, occurrence count, bounded affected-build identifiers, the last bounded recovery-outcome label, and its local ticket identity; the raw problem fingerprint and incident content are not stored in the index. The index is capped, stays on the device, is never sent to a model, support relay, paired device, or telemetry service, and is removed with the profile’s support-ticket data or local reset. The underlying local ticket remains support-sensitive under the existing ticket disclosure. This durable local aggregation requires renewed consent at Privacy Policy version 2026-08-privacy-v59.

To make an interrupted interactive chat recoverable, HVAIA can retain intermediate assistant text and model-provided reasoning in a local lifecycle checkpoint for Desktop, Telegram, and iPhone/Gateway chat runs. This checkpoint stays in the active profile’s local data and is deleted with the chat. An authenticated Desktop in that active profile can use a content-free recovery index to retrieve an already-finalized local message after restart; the index contains identifiers and lifecycle status, not assistant text or media. Private, not-yet-finalized checkpoint content is not included in Gateway or public-relay event/replay data, run-control responses, Telegram delivery, iPhone chat snapshots, or support-report assistant content. By contrast, every nonempty public model segment is finalized as its own visible message in provider order and follows the ordinary encrypted chat-sync and publication rules. Telegram and the end-to-end encrypted iPhone mirror receive those same ordinary finalized chat responses that Desktop does. Private checkpoint content is not sent to Memory, text-to-speech, Wake Up, or any other publication-only consumer. An in-progress Wake Up generation remains memory-only until its nonempty public output is finalized and committed. The only Wake Up exception is a backend-verified continuation that actually suspends for its own one-time timer: it may retain the complete, sanitized public tool exchange and resume cursor in the same owner-scoped local run checkpoint. If you send an early message, the same work resumes through steering while its timer remains registered. Its sanitized public history, your new message, and the resume cursor may remain in that same local checkpoint for recovery; the due occurrence adds its saved, possibly edited instructions to the resume history. Active Scheduled work outside this exact continuation remains memory-only; provider-private reasoning and credentials are not retained by this exception. Schedule previews include the execution computer name, resolved time zone, and upcoming run time. Paired iPhone requests and replies keep the draft schedule and this preview inside the existing encrypted envelope; the relay cannot read them, and previews are not a new persistent content store. The existing chat, run, profile, and reset deletion boundaries apply, with no new storage root, external recipient, relay-readable content, or renewed-consent step beyond Privacy Policy version 2026-09-privacy-v85.

For an ordinary interactive chat, including a planned or checked Office-edit turn, HVAIA performs one normal answer-generation cycle. Streamed model-authored content stays visible locally while HVAIA enters a neutral finalizing state and performs deterministic checks for pending decisions, unfinished tools, evidence and catalog integrity, consistency, cancellation, profile authority, and the publication fence. Publication-only consumers receive the answer only after those checks and one atomic commit. A persisted finalizing answer can be committed idempotently after restart without another model request. Exact empty model output creates no assistant message, placeholder, fallback, publication, or downstream delivery. In every recovery mode, HVAIA records only the bounded recovery facts above and starts another ordinary provider turn in the same main-agent run with the replaceable recovery block; this continues until the model produces output, you cancel, or an existing infrastructure, approval, input, or safety boundary is reached. A completed tool remains in the run history and is not dispatched again. HVAIA adds no host-authored response and no model-attempt cap. The iPhone mirror is an end-to-end encrypted chat-sync path, not a publication delivery consumer: it does not claim or acknowledge a publication and receives normal chat messages plus content-free finishing state only through the desktop-owned encrypted snapshot.

During deterministic finalization, HVAIA can compare bounded structured tool receipts and joined-helper results already held in the private local run checkpoint with their backend-owned identities and digests. Pending helper receipts remain excluded, completed, failed, and cancelled outcomes stay distinct, reserved interface metadata and binary payloads are omitted, secret-like fields are redacted, and oversized structure is truncated. This check runs locally without sending a second review request to any model provider. The bounded evidence is not added to ordinary model context, logs, support reports, or the public relay, and no reviewer transcript or reviewer-feedback message is stored or synchronized.

A completed delegated internet or Office child can retain bounded handoff metadata in that same local run lifecycle: up to 32 citation source records already produced by the search workflow, and one content-free Office success receipt containing only specialist identity, file kind, edit count, created/changed status, and a one-way request digest. This lets the exact source run preserve citations and avoid repeating a newly created Office publication after restart. The receipt contains no filename, path, draft, file content, or native capability. These records are removed with the owning chat/profile lifecycle data, are excluded from logs, support reports, telemetry, Memory, and readable public-relay state, and add no new recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

Google Gemini tool calls can include provider-signed private model steps that HVAIA keeps only in process memory and does not write into a durable checkpoint. If a joined helper pauses the source run and that run later resumes, HVAIA starts a fresh stateless Google interaction at the exact delegated result packet. The resumed request can include the original system and user context, nonempty public assistant text, and the bounded exact result packet, but omits the pre-pause function-call envelopes, tool results, and private signatures that cannot be validly replayed. New tool calls made after resume can again use their live memory-only signed context. This changes neither the local durable transcript nor Google’s existing role as the selected model provider, and adds no new data category, recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

Deep Research clarification questions are stored as a local finalized chat message while the chat waits for a separately identified follow-up. Before HVAIA shows the first nonempty clarification text, it stores the original Deep Research request with created and expiry times as a temporary server-owned field inside that same chat’s existing locally encrypted capsule. The field expires after 24 hours. HVAIA removes it after a successfully claimed follow-up consumes it, when you turn off Deep Research, when it expires, on rewind or fork, and when the chat, profile, or local device data is deleted. If HVAIA cannot save it through the exact chat’s encryption boundary, it shows no clarification questions that could not later be resumed. The field is not added to Memory, logs, support data, exports, history or fork snapshots, chat indexes, public-relay-readable data, or iPhone persistence. A follow-up sent from a paired iPhone can resume it only while the live Desktop reads the local encrypted capsule through the existing end-to-end encrypted connection. An exact retry reuses the local clarification message instead of generating or publishing a second turn; clarification turns do not create a committed publication or trigger publication-only consumers. This temporary original-request retention and its deletion boundaries require renewed consent at Privacy Policy version 2026-08-privacy-v65.

For a planned task that asks for complete coverage of a finite connected-data result set, HVAIA can create a private local coverage ledger. It records the backend-owned source scope, source-unit identifiers, completion states, and bounded attempt counts in the active profile’s run lifecycle data. The planner drawer’s Coverage row and ordinary lifecycle projections receive only aggregate progress and status; they do not include the source identifiers, source query, or source-item contents. For deterministic reconciliation, HVAIA keeps source content only in process memory; it remains excluded from the coverage ledger, raw-event journal, logs, support reports, default model context, paired-device snapshot, and public relay.

Scheduled Automation and ordinary Scheduled-task output remain process-memory-only while their normal agent execution is in progress; only the exact suspended continuation checkpoint described above is excepted. A nonempty result is finalized, deterministically checked, and committed under at most one publication ID. Automation attempts and traces retain the singular publication reference and content-free lifecycle metadata rather than another raw token copy. Exact empty output creates no publication or substitute summary. When Automation run retention or hard deletion removes database records, HVAIA first stores a content-free cleanup row in the existing local Gateway database and then deletes that exact run’s profile-owned and legacy trace directories. The row contains only bounded run/job/profile/scope identifiers, retry count, safe reason code, and timestamps—not trace content—and remains queued with bounded retry after a filesystem failure. A content-free per-root sweep cursor stores only the last directory name and completion state so older orphaned traces can be reconciled in bounded batches. Webhook-secret replacement or job deletion may also store a retryable local cleanup row containing the exact opaque Vault reference, complete owner scope, operation identity, status, safe reason code, attempt count, and timestamps—never the secret value. HVAIA creates that row only with a successful version-checked mutation, then verifies that the reference is no longer active and confirms local Vault deletion after commit; failure or restart leaves it pending for safe retry, while a stale delete changes neither the live job nor its current secret. Profile deletion removes only the exact profile-owned Automation definitions, runs, cleanup rows, and profile/legacy trace directories for those runs, plus that profile root’s cursor. Legacy rows without an exact profile/account owner are not guessed into the deleting profile; deletion remains visibly incomplete and retryable instead. Local reset may remove the entire Gateway database and all trace roots. Scheduled-task retry/dead-letter handling stores only bounded attempt number, retry/dead-letter timestamps, status, reason code, and schedule-version metadata in the existing local gateway database; an explicit transient transport retry is allowed once, while ordinary failures remain attention states. The committed publication receipt makes the scheduled answer, media item, or artifact available to its authorized downstream consumers. This Vault-reference cleanup narrows deletion reliability within the existing local Automation and Vault boundaries and adds no data category, recipient, storage root, retention promise, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

After deterministic finalization, Automation stores its committed result and committed materialization parts locally under the immutable publication ID, and retains that ID with the backend execution ID so delivery recovery does not repeat completed actions. Hard deletion of the Automation removes that local materialization with its run. For Telegram, HVAIA waits for the single committed publication, claims its fenced delivery, and then creates a content-free local send intent keyed by that message’s opaque delivery identifier immediately before the first Telegram write. That intent retains only the message delivery key, run, account, thread, and delivery-version identifiers. A repeated delivery of the same committed publication reuses the mapped intent and does not send a duplicate reply. If HVAIA restarts while an external send is unresolved, it does not automatically resend; the delivery remains outcome-unknown for reconciliation. Thread or account deletion removes these intent and message-mapping records without storing another assistant copy.

Delivery claims use a random fencing value and a monotonically increasing version. These claim rules apply only to downstream publication consumers, never to the iPhone’s encrypted normal-chat mirror. HVAIA stores only a hash of the fencing value and requires the value and version again immediately before a consumer writes or acknowledges published content. Delivery processing can be pending, materializing, retryable failed, outcome unknown, or acknowledged; an uncertain external send is not automatically repeated because that could create a duplicate message. The Desktop acknowledges delivery only after its writable local chat repository durably saves the publication-bearing chat snapshot. When content is deleted, a tombstone prevents further materialization and the associated delivery rows are removed. Each committed publication includes an ordered manifest of text, media, and artifact parts with a content reference, MIME type, byte length, and SHA-256 digest; optional filenames and media categories are stored only as metadata bound to that manifest. The corresponding part bytes are stored locally as immutable publication material and are released to a consumer only through a committed, fenced delivery claim. Before a publication is committed, HVAIA deterministically checks the exact text and ordered digests, lengths, MIME types, filenames, and media categories of binary parts against the finalized message; this check uses no reviewer-model request or verdict. Candidate answer text and generated media remain in process memory until the generation is finalized, and downstream consumers receive them only through the single committed publication. HVAIA does not impose an application-level byte ceiling on candidate text, a generated-media item-count ceiling, per-item or aggregate decoded-media byte ceilings, or a generated-image source-size ceiling before creating the bounded preview sent to a paired iPhone. Malformed or empty generated media is still rejected before publication. The selected provider, available device memory and storage, and operating-system or protocol constraints can still impose practical limits.

Local profile and authentication data

HVAIA stores local account and profile metadata, including your username, profile ID, account ID, tenant ID, workspace ID, lockout state, remember-me state, onboarding acceptance state, and password verification metadata. HVAIA stores password hashes for normal sign-in verification. If you turn on Remember me on this device, HVAIA stores a local remember-me token and may preselect your username, but it must not return or prefill your saved password. Remember-me token and key-wrapping material are stored through the local secret store.

Multiple HVAIA profiles may exist under one macOS (or other operating-system) user account. Only one profile is shown in the foreground at a time. Authenticated background gateway, scheduler, Telegram, and iPhone callbacks may continue for an explicitly enabled profile, but every callback must retain and resolve its exact account/tenant/workspace owner; it is never reassigned to the next foreground profile. Profile-owned desktop chat state, Studio projects, visual artifacts, Scheduled/Automation traces, speech files, tickets, and relay runtime state are stored beneath separate profile roots. Configured profile chat state is encrypted at rest with AES-GCM using a profile data key wrapped by the local secure store; if that key is unavailable or a scope is ambiguous, the read or write fails closed. The managed STT/TTS watchdog endpoint and its start/stop/health state are one machine-wide operational runtime: an authenticated profile can observe or control its availability, and a start/stop can affect another profile, but the runtime does not store profile chat/content data and speech settings and generated artifacts remain profile-scoped. Managed local chat/embedding/extractor inference and MCP worker processes are likewise machine-wide operational resources; their health or availability may affect another profile, while profile content and settings remain scoped. The shared lifecycle database and owner-scoped raw-event journal are not blanket-encrypted; raw web-capture events can contain page text and are retained only under the owning scope. While locked, the sign-in chooser may show profile usernames, but HVAIA does not return account, tenant, or workspace identifiers.

Locking, signing out, or switching the foreground to another profile does not cancel work that the owner already authorized. Running or queued chats and delegations, plus future due Scheduled tasks and Automations, may continue in the background under the exact stored profile, account, tenant, and workspace owner. During that work, HVAIA may access that owner’s encrypted local data, model settings, memory, tools, and Vault-scoped integrations even while the UI is locked or another profile is visible. Results, traces, history, workspace changes, and publication state remain isolated to the owner and are not shown to the foreground profile. A new approval or user-input request waits for the owner and cannot be answered by the foreground profile. Missing, ambiguous, deleted, reset, or mismatched ownership stops execution or publication without falling back to another profile.

On Desktop, the active Automation workspace and its archived Automation list are shown only when their in-memory interface state belongs to the exact currently unlocked profile, account, tenant, and workspace. If that identity changes or becomes unavailable while the Desktop interface remains open, HVAIA immediately hides and clears the prior Automation rows, selection, unsaved creation draft, run details, and Automation loading, error, and restore state. Network or restore results that finish for the earlier identity are discarded from the foreground interface. This narrows possible cross-profile presentation without adding a data category, recipient, storage root, retention period, deletion boundary, or renewed-consent requirement.

Sign-out immediately hides the active profile in the desktop UI, clears the foreground request-local profile context, and fences profile-owned foreground routes until the next unlock. It does not revoke the exact task-local authority of already authorized background work described above. Removing one profile uses the profile-only reset flow and purges that profile’s local roots, scoped lifecycle/raw-event records, traces, TTS files, tickets, caches, and relay runtime state; the full reset flow is separate and is intended for an explicit device-level cleanup. If the operating system temporarily prevents a file or runtime resource from being removed, HVAIA reports profile cleanup as incomplete and retries it after reopening the app rather than claiming that deletion finished. Profile-scoped support tickets omit machine-wide process logs because those logs cannot be reliably attributed to one user. HVAIA does not promise isolation from a hostile process running as the same OS user, a user with filesystem access, or shared OS applications such as Chrome; shared browser/computer-use actions remain approval-gated and should be treated as machine-wide activity.

Computer Use stores your enabled choice, action limits, and always-allowed app identities locally in the active HVAIA profile. It does not store a network endpoint, runtime-health history, or a user-editable confirmation mode. The exact retired settings record is migrated locally once by preserving your enabled choice and limits and removing those retired fields; unknown or malformed older records remain untouched for explicit recovery. To prevent simultaneous app processes from replacing one another’s settings or allowed-app decisions, HVAIA uses content-free local locks and short-lived same-folder temporary files while saving. These files are not sent to a model, the public relay, a connected service, or another device.

HVAIA Dev holds a separate content-free operating-system app-state lease while its desktop shell is open. The lease contains no chat, profile, or secret data; it only prevents a second source/dev shell from using the same operating-system profile and is released when that shell exits. While a Rust-owned local Vault is running in source/development or packaged mode, HVAIA also keeps a content-free ownership proof in that mode’s existing operating-system app state. It contains only the desktop owner and Vault process identifiers and start times, the Vault process group/session identifiers, and its loopback endpoint. HVAIA removes that proof after confirmed Vault shutdown. If the desktop exits abruptly, the next launch may use the exact proof to stop only the matching orphan before starting its own Vault; an occupied port or matching executable signature alone never authorizes termination, and unmatched processes remain untouched. This proof is not sent to a model provider, paired iPhone, public relay, log, support report, or another third party, and this lifecycle clarification adds no user-content category, storage root, external recipient, retention class, or renewed-consent step beyond Privacy Policy version 2026-08-privacy-v62.

Normal chat saves update only the encrypted capsule or capsules an action actually affects, together with a compact encrypted summary index. Sending a prompt, changing its draft or queue, renaming, pinning or unpinning, archiving or restoring, and changing unread status update one chat; create adds one, while fork, project actions, dispatch, and deletion update only their bounded related set. Search and startup hydration may read multiple chat summaries or capsules but do not rewrite them. For the chat rows in a paired iPhone’s workspace list, Desktop reads only that compact encrypted summary index and the current in-memory foreground state. An index row may retain the chat title, project display and ordering fields, pinned, archived and unread state, durable activity, handoff and run status, draft toggle state, opaque identifiers, timestamps, and revisions; it does not retain or return message text, draft or queued-prompt text, attachments, handoff excerpts, bundle digests, or administration receipts. The row can reach the paired iPhone only inside the existing end-to-end encrypted response, while the public relay sees routing metadata and ciphertext. A timed-out iPhone workspace or chat-detail read cancels its remaining Desktop read work but does not cancel or replay a mutation. These summary fields follow the owning capsule’s existing profile, chat, deletion, and device-reset boundaries and add no new storage root, external recipient, retention period, or public-relay-readable content beyond Privacy Policy version 2026-08-privacy-v57. Production does not expose full chat-state replacement, legacy chat import, or writable browser-storage fallback. Startup accepts chat storage only when the backend declares the chat_scoped_v1 contract and supplies a revision for every chat. After that authoritative read succeeds, HVAIA may delete only the exact retired IndexedDB chat database for the active profile; it does not inspect, import, synchronize, or recover chat data from IndexedDB or localStorage. If authority is unavailable, HVAIA keeps a previously hydrated same-profile list and already typed composer text visible in read-only memory, or shows a storage-unavailable state on cold start or profile switch. It does not persist a placeholder chat, replace the sidebar, or start a model run. Pending-run recovery is checked separately, so a run-recovery warning appears only when that authority check itself fails. HVAIA may record local content-free performance diagnostics containing the operation category, number of affected capsules, bytes processed, queue and storage duration, and conflict retry count. These diagnostics never contain chat titles, messages, attachments, or raw chat identifiers. This changes only how much of the same encrypted local chat store is processed: it adds no new data category, path, recipient, relay exposure, retention period, deletion rule, or readable telemetry, and does not require renewed consent beyond Privacy Policy version 2026-07-privacy-v49.

Secrets and API keys

API keys, OAuth tokens, relay credentials, bot tokens, and similar account or provider secrets are stored in local HashiCorp Vault or the local operating-system secret store. Hosted inference and Memory provider API keys are read only from the active profile’s local HashiCorp Vault; legacy provider-key values in process environment variables or plaintext TOML configuration are ignored. The packaged local-runtime bearer tokens described above are the narrow exception: they live only in private packaged app-state files so separately owned local processes can authenticate across restarts. HVAIA does not intentionally store these secrets in chats, localStorage, plaintext settings files, or logs. Secret-dependent features fail closed when their required protected storage is unavailable.

When you connect ChatGPT for OpenAI inference, HVAIA opens OpenAI’s browser or device sign-in and stores the resulting access token, refresh token, ChatGPT workspace identifier, token expiry, and available plan type only in the active profile’s local HashiCorp Vault. Browser sign-in returns through a temporary callback listener bound only to this device’s loopback interface; the callback is not sent through HVAIA’s public relay. HVAIA reads the returned identity token only in memory to derive the workspace and plan, then discards it without storing it. The callback waits until the secure save finishes before showing success, prevents the result page from being cached, and removes the authorization code from the displayed browser URL. HVAIA does not read ChatGPT browser cookies, write Codex authentication files, or return those credentials or the workspace identifier through Settings status APIs. During ordinary ChatGPT requests, HVAIA supplies the Vault-derived access token and safe workspace metadata in memory to a pinned, HVAIA-owned Codex app-server process. Computer-enabled requests instead use the same Vault-held identity through HVAIA’s own in-memory subscription transport, as described above. That process uses an ephemeral authentication store plus a private temporary home and working directory that HVAIA removes during normal owned-process teardown. Token refreshes rotate the complete credential bundle in Vault and fail closed if Vault or OpenAI authentication is unavailable. If a saved ChatGPT credential bundle is already incomplete and unusable, explicitly reconnecting treats it as non-restorable and may remove it while installing the replacement; valid prior credentials keep rollback protection.

OpenAI API keys and ChatGPT subscription credentials are separate Vault secrets. Switching authentication modes does not silently delete the inactive credential. Disconnecting ChatGPT removes only the ChatGPT credential bundle and preserves your selected inference, Internet Search, Image Generation, and Image Editing providers. Features that still select the disconnected account show connection guidance instead of using API-key billing. Deleting the API key does not disconnect ChatGPT.

The first successful explicit ChatGPT connection selects OpenAI subscription inference, Internet Search, Image Generation, and Image Editing together. HVAIA stores these non-secret choices and a one-time defaults marker in the active profile’s existing inference settings. A failed connection restores the previous valid credentials and selections. Later reconnects, token refreshes, Settings reads, and restarts preserve your independent choices. An already-connected profile is not changed automatically during startup. These selections do not change speech-to-text, text-to-speech, or embeddings.

HVAIA keeps source/development and packaged-app secure-storage identities separate on the same device. Rust selects each mode’s fixed operating-system credential-store identity from the native launch mode, not from a Python or caller-provided service name, so one mode does not read or overwrite the other mode’s credentials. For an existing Vault created before installation-scoped custody, if older Python-owned macOS Keychain entries exist and the new HVAIA-owned entries do not, the native HVAIA app first explains a one-time authorization, copies and verifies each available value, and leaves the older item unchanged. If the native unseal key is already accessible but only the replaceable runtime token is missing, HVAIA does not request access to an interaction-gated older runtime token; it leaves that older item unchanged and creates a fresh scoped runtime token after local Vault starts. Cancelling, a locked or out-of-sync login keychain, an interrupted copy, or failed verification of required unseal material stops startup without deleting, resetting, or replacing the older data. No migration value is logged or sent off the device. A regenerated runtime token is also never logged or sent off the device. This on-device ownership change adds no external recipient, retention period, or readable relay exposure.

The Vault bootstrap credential remains limited to the native desktop owner and the local backend’s authenticated secure-storage bridge; HVAIA does not give that credential to Gateway, Telegram, Automation, Memory, speech, or connector workers. For the current desktop session, an authenticated loopback authority can give the Telegram worker only the bot token for one exact owner-bound account and only while it is needed for Telegram API calls. Automation workers receive only webhook verification or secure-storage readiness results, never the webhook secret. The Automation scheduler also receives a short-lived session capability limited to asking the local backend to poll saved Gmail watchdogs. Each poll uses the watchdog owner’s Google connection through backend-owned Vault access and returns only scanned, matched, enqueued, and failed counts. Google credentials and message metadata never cross this polling boundary to the scheduler; diagnostics contain safe failure codes and recovery guidance. A hosted Memory embedding worker sends bounded owner-scoped text to the local backend and receives vectors plus non-secret model metadata; it never receives the embedding provider API key. These loopback values and results are not sent to HVAIA’s public relay, another device, logs, or an unrelated model or connector. A selected hosted provider still receives only the content and feature credential needed for the request you chose, under that provider’s privacy practices.

If local Vault startup detects an unusable empty bootstrap state before any Vault secret data exists, HVAIA may quarantine that empty broken Vault data and create a fresh local Vault so the desktop can start. HVAIA does not silently replace Vault storage that contains user secret data; those cases require explicit recovery or re-onboarding.

AI model providers

Regular Chrome page content and context derived from it require a qualified model destination. HVAIA currently permits this data only with configured local models using local loopback destinations. Hosted accounts are not qualified merely because you accepted their terms, supplied an API key, or disabled response storage. If a conversation contains Chrome data and you select an unqualified provider, HVAIA blocks the request before transmitting the protected context and explains that you need a local model. The same protection applies to specialist extraction and hosted image or video requests from that conversation. It does not silently select another provider. Ordinary conversations without Chrome-derived context keep their existing provider choices.

HVAIA records a content-free Chrome restriction in the existing profile-encrypted chat capsule. It remains with the conversation across restart and renderer updates, and follows forks, derived chat context and cross-chat task handoffs. A handoff’s restriction is committed in the same local transaction as its transcript. Separate hosted ChatGPT Internet Search, hosted Voice, and hosted Text-to-Speech transports cannot receive that conversation’s protected context or committed replies. Local speech playback retains the existing managed-runtime requirements. Chrome-derived canonical Memory records retain a provenance field with their existing local content; protected sources cannot be recalled into an unqualified model or sent to an unqualified embedding destination. Empty Memory templates and unrelated records remain unrestricted. These markers contain no page text, secret, or credential, introduce no separate storage root, and are removed with the existing chat or Memory deletion and reset boundaries.

HVAIA’s use of information received from Chrome APIs adheres to the Chrome Web Store User Data Policy, including its Limited Use requirements. This includes raw Chrome data and retained or derived context. HVAIA uses that data only to provide or improve the user-facing browser assistance you request; it is not used for advertising, sold to data brokers, or used to train a general-purpose AI model. A provider configuration must meet these requirements before receiving Chrome-derived model context. When you use hosted AI providers, HVAIA sends the prompts, messages, selected context, tool results, attachments, images, or other inputs needed to complete your request to the provider you selected or configured. Supported hosted providers can include Qwen/DashScope, Kimi, Z.AI, MiniMax, Anthropic, xAI/Grok, OpenAI, Hugging Face managed endpoints you configure, and other configured providers. Those providers process the data under their own terms and privacy practices.

By connecting or using a provider through HVAIA, you confirm that you have reviewed its privacy policy, accepted its applicable terms, and are authorized to share the data needed for your requests. That provider processes the data under its own terms and privacy practices.

For Claude Opus 5.5 tool calls, HVAIA keeps Anthropic’s signed thinking and tool-use blocks only in process memory while the exact tool continuation is active and sends them back only to Anthropic with the matching tool results. These provider-private blocks are not saved in chat history or durable checkpoints, shown in the interface, logged, sent to support data or paired devices, or exposed to the public relay. A resumed run without those live blocks starts a fresh provider interaction from permitted public context. This uses the existing selected-provider transmission and in-memory continuation boundaries, with no new external recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond the current Privacy Policy version.

For OpenAI chat inference, you can choose either OpenAI API-key billing or an eligible ChatGPT subscription. Ordinary ChatGPT subscription requests are handled through the pinned OpenAI Codex app-server runtime. Computer-enabled requests use HVAIA’s in-memory transport to the same OpenAI subscription service. Both count against the limits and availability of the connected ChatGPT plan, while API-key requests use separate OpenAI API billing. In either mode, OpenAI receives the model-visible conversation and context needed for the request, including the bytes of any supported image you attach when the model needs to inspect it. HVAIA converts supported local images to in-memory provider inputs and does not send their local file paths, local artifact URLs, or public-relay-readable copies. HVAIA disables the Codex runtime’s built-in shell and web tools for this integration and exposes only HVAIA’s existing tool catalog, approval rules, and result path. The Codex bridge does not add Codex-native user, repository, plugin, or bundled skills to model-visible context; only skills installed through HVAIA can contribute compact metadata or on-demand instructions through HVAIA’s existing skill controls. This narrows unintended local-file exposure and adds no new recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v65.

When an authorized tool returns a supported image, including an explicit Browser frame, HVAIA passes its validated image bytes to the selected model as the result of that exact tool call. Subscription inference uses the same in-memory image handoff. The call association is process-local and cannot select older or unrelated images; local paths and artifact URLs are not sent as substitutes. This restores the existing selected-provider image flow and adds no recipient, storage root, retention period, deletion boundary or renewed-consent requirement; Privacy Policy version 2026-09-privacy-v85 remains current.

During an explicitly requested engineering check of ChatGPT subscription capabilities, HVAIA can send the supplied test query or prompt, a reference image generated by that check or a small test image constructed in local memory, a voice-preview phrase and voice choice, or a synthetic audio test signal to OpenAI. These checks use the current unlocked profile’s existing Vault-held ChatGPT connection and can consume its plan allowance. Voice signaling also sends a random temporary connection identifier to OpenAI; it contains no profile or chat identifier and is discarded when the connection owner closes. They do not run automatically when you open Settings, read chat history or files, capture your microphone or screen, dispatch ordinary chat work or tools, or substitute API-key billing. Test responses and images remain transient. Returned diagnostics and local backend qualification logs contain only the capability, runtime version, safe outcome and reason codes, fixed test-stage names, HTTP status, recognized provider error classifications and parameter names, and named boolean or numeric measurements. These records contain no prompt, image, transcript, voice choice, credential, account or session identity; they follow the existing operational-log retention, support-report, and deletion rules. The isolated local audio test peer receives no credentials, and its temporary profile is removed during owned teardown. These manual connection checks are separate from HVAIA’s model-evaluation suites and add no new external recipient or retained personal-content category. Live Voice, personal microphone input, screenshots, and a dictation dictionary require their separate feature disclosures before rollout.

When an exact joined specialist suspends a live main-model tool loop, HVAIA may keep only eligible provider continuation state alive until that joined result is ready: a pending ChatGPT Codex app-server turn, or the provider-private thought signature required by Claude Opus 5.5, Google, Kimi, Z.AI, or Qwen to continue the exact tool call. For ChatGPT, the HVAIA-owned app-server process and its private temporary home remain alive, so the conversation, instructions, tool declarations, and pending call already supplied for that turn remain available to that local provider runtime; before continuing, HVAIA checks the exact thread, turn, tool call, and unresolved status within two seconds and supplies a freshly rebuilt temporal-context instruction to OpenAI. HVAIA always rebuilds the current profile, repository, project, grant, tool-executor, and request authority first, and falls back to the encrypted durable checkpoint if any scope, authority, provider state, or readiness proof differs. Live continuation entries are one-use, process-local, and bounded to the same maximum of eight active delegated descendants. They are never written to chat storage, Memory, settings, logs, support data, telemetry, paired-device state, or public-relay-readable storage, and are discarded on use, mismatch, fallback, replacement, capacity eviction, steering, cancellation, failure, chat or profile deletion, sign-out, or process shutdown. A crash or restart therefore uses the durable replay path instead of recovering live provider state. This extends only the current live tool loop across its exact delegation wait and adds no new external recipient, durable storage root, relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

If you configure a Hugging Face Inference Endpoint, HVAIA stores its endpoint URL, selected access level, discovered chat model identifier, safe readiness status, and a non-secret internal reference used to switch a saved token safely in local HVAIA settings. HVAIA sends a small compatibility check to that endpoint before saving it, and then sends chat requests or embedding text only to the endpoint you configured. For Private or Authenticated endpoints, your Hugging Face token is used for those requests and is stored only in local HashiCorp Vault; it is not included in settings, API status responses, or logs. When you replace a protected token, HVAIA removes the superseded Vault token after the new endpoint setup is safely saved; if that removal is temporarily unavailable, HVAIA records the pending cleanup locally and retries it without using the old token. Public endpoints are contacted without a bearer token.

HVAIA does not send planned chat, checked Office, Automation, or Scheduled answers to a second review model. It stores no completion-review packet, provider fallback record, reviewer output, reviewer tool transcript, verdict, reviewer feedback, or reviewer-triggered answer generation. Those surfaces use the same local deterministic finalization and singular publication boundary described above.

When a model emits a malformed tool call in Main Chat, a specialist, or Automation, HVAIA retains the redacted original argument text, tool name or model-authored title when recoverable, and the exact validator reason and schema path in ordered local chat or run history so you can inspect the rejected call. Side Chat shows the same details only in its temporary process-memory transcript. Credential and explicit-secret values—including values under exact secret names or delimiter-separated names such as user_token, github-access-token, and service.client_secret—are redacted before display, local history, encrypted sync, or provider correction context receives the malformed syntax; similarly named non-secret fields remain intact. Rejected calls never reach approval or execution, while valid sibling calls continue independently; the model can make later correction calls without a HVAIA attempt limit. For a successful plan update, the model may also author a separate short phase-transition title. HVAIA shows that title on the distinct phase row and retains it in the same existing local lifecycle and encrypted chat presentation paths so the timeline can replay it; a paired iPhone may receive it only inside the existing end-to-end encrypted chat payload. Raw diagnostics, support payloads, logs, content-free Gateway projections, Telegram, and the public relay do not receive that phase title. It follows the owning chat, profile, run, and device-reset deletion boundaries and adds no new recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57. A paired iPhone receives other eligible Main Chat malformed-call details only through HVAIA’s existing end-to-end encrypted chat channel and protected local cache; the public relay, support payloads, logs, and content-free Gateway projections do not receive them. Telegram receives neither the malformed-call trace nor a replacement message.

During API-key onboarding, a plan or key-region choice determines which supported provider service HVAIA configures. When a region is selected, hosted prompts, messages, attachments, microphone audio, text-to-speech input, and embedding text chunks are sent to the matching provider service region when the corresponding hosted feature is used. If no Qwen region is explicitly selected, the default hosted Qwen route is the Singapore/international service; choosing a different supported region changes that route. A plan choice can instead select a provider’s dedicated subscription or coding service. HVAIA stores the selected non-secret plan and region identifiers locally so Settings and runtime routing use the same configuration; API keys remain in local secure storage. Choosing a region does not move existing local HVAIA data, and HVAIA does not automatically make that provider the active chat model.

When you save an Alibaba/Qwen key during onboarding, HVAIA selects the supported hosted speech, embedding, image-generation, and image-editing services for that chosen region. Local image models are currently unavailable, so the image cards remain on their hosted option. The provider transaction keeps the affected model overrides and speech settings recoverable until setup either succeeds or is restored; this does not add a new cloud recipient or send speech or image preferences to the relay.

To prevent an interrupted provider setup from leaving your settings and credentials out of sync, HVAIA temporarily stores only the affected prior provider settings and prior credentials in local HashiCorp Vault for crash recovery. A non-secret transaction identifier and phase are stored in local inference state so HVAIA can finish recovery after a restart. The new credential being saved is never written to this rollback record, and all recovery data is deleted after setup commits or rollback completes. While recovery is incomplete, provider setup, model startup, and destructive local-data reset stop safely until recovery succeeds.

For Grok and OpenAI Responses requests, HVAIA sends store: false so it does not opt into those APIs’ server-side response storage. xAI and OpenAI still process each request under their own terms and privacy practices.

Reasoning effort, Standard/Pro mode, and Thinking on/off choices are non-secret local inference preferences. HVAIA does not store or display raw provider reasoning traces in chat history, encrypted sidecars, settings, logs, support reports, lifecycle/raw events, exports, client streams, or relay projections. This includes MiniMax reasoning_content and text inside reasoning_details, which HVAIA treats only as private provider context for the immediate model loop. A provider-authored summary that arrives in HVAIA’s typed, complete public-summary format is different from raw reasoning: HVAIA may display and store that exact finalized summary only with the encrypted chat and may send it to a paired iPhone only through the existing end-to-end encrypted chat path. It is not assistant text, TTS content, Memory input, or a tool title. Plain, incomplete, malformed, or provider-private reasoning never becomes that public summary. This narrows exposure without adding a data category, recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

When you send or queue a Desktop chat prompt, HVAIA stores the exact non-secret inference selection for that prompt with the existing encrypted queue record and, after acceptance, with the local run lifecycle record. This selection can include the provider, catalog and effective model identifiers, a normalized non-secret endpoint, and supported request options such as reasoning, Thinking, or Standard/Fast mode. It does not include API keys, ChatGPT tokens or workspace identifiers, Vault references, raw provider reasoning, prompts, responses, attachments, or tool content. This lets queued, active, resumed, and same-run steered work keep the selection you made even if you change global inference settings later. Queue dispatch or deletion removes the queued copy; chat/profile deletion and local-data reset remove the run copy under the existing rules. HVAIA does not add this selection to logs, support reports, or public-relay-readable state. Because this stores existing non-secret preferences inside existing queue/run retention and adds no new recipient or user-content category, Privacy Policy version 2026-09-privacy-v85 remains current.

When a hosted model provider cannot be reached, is briefly rate-limited or is overloaded, HVAIA retries the same request to the same provider you selected; it never switches providers. Waiting for an unreachable provider continues until the connection returns or the work is stopped. While HVAIA waits, the local run lifecycle record and its event history keep a content-free connection status: the provider name, a reason code, when waiting began, the attempt count and the next retry time. It contains no prompt, response, attachment, provider error text, credential or account identity. Desktop shows it as a Reconnecting status, and operational logs receive only the same content-free fields. It is not sent to support reports or public-relay-readable state, and chat/profile deletion and local-data reset remove it under the existing rules. For classified provider failures, HVAIA records a safe reason code and fixed guidance instead of the provider’s error text. When an answer stops because of an unexpected internal error, the chat status, run lifecycle record and any paused Goal keep only a fixed sentence naming the error type; the full error text and stack trace go only to the local support diagnostic record under support-reports/tickets. Because this adds no recipient, user-content category, storage root or retention period, Privacy Policy version 2026-09-privacy-v91 remains current.

When you use local models or local managed runtimes, inference is intended to run on your device. On Apple Silicon, HVAIA can use Apple MLX versions of local embedding, speech-to-text, and text-to-speech models. Model downloads, including required speech-tokenizer weights, update checks, and catalog checks can still contact provider-hosted download services such as Hugging Face. After installation, managed local inference loads installer-owned files rather than silently downloading additional model files. HVAIA keeps non-secret schema-v2 installation progress locally and replaces that state atomically so a failed write preserves the prior bytes. On startup, it may recover a catalog bundle as ready only after verifying every expected artifact’s regular-file type, exact size, and checksum without following symlinks; startup recovery does not download, bootstrap, quarantine, or adopt unknown files. Existing valid operation and notification ownership values are retained, while missing or invalid state does not invent them. These reliability safeguards add no data category, recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

If a desktop session has local-model auto-start turned off, HVAIA does not start or repeatedly restart its managed local chat, embedding, or extractor runtimes merely because their files are installed.

Speech, voice, and embeddings

Voice transcript batches preserve speech around typed messages in the order it arrived. A typed message separates earlier and later speech, even when speech is waiting to be saved. This uses the same encrypted chat history and existing retention, deletion and synchronization rules; no additional transcript store, recipient or data category is introduced.

If desktop speech shortcut setup, Voice startup or dictation fails, HVAIA may write a fixed operation category and an approved technical reason code to the local renderer console. These transient diagnostics exclude raw errors and stacks, audio, transcripts, receiving-field contents, microphone identifiers, and account, profile, chat or capture identifiers. They do not create a durable HVAIA log, support report or external transmission. This clarification adds no external recipient, storage root or renewed-consent requirement.

Uploaded-recording preferences are separate from microphone dictation and are off by default. They keep only the enablement choice, Alibaba region/workspace and recording-consent version in your existing profile speech-settings file. Enabling processing or changing its active region/workspace requires explicit consent. The recording API key stays in that profile’s Vault; settings responses show only whether it is configured, never its value. Removing this key verifies permanent removal of its saved versions without changing your dictation key. Turning recording processing off prevents later audio-transfer or submission steps, but an already-started request may finish. Accepted source files remain available for an explicit retry; disabling does not delete recordings or their transcripts. Restart recovery stays bound to the original profile and saved provider task. These settings do not enroll a voice or grant automatic consent.

When you ask about an uploaded recording, HVAIA may send relevant transcript excerpts or requested chronological transcript pages, including speaker labels and timestamps, to your selected chat model. Complete-meeting summaries can require all pages. Reading this text does not retransmit the audio to Alibaba or create a voiceprint. Read results retained in another chat remain that chat’s independent content if the original recording is later deleted.

When Alibaba FileTrans is explicitly invoked for a recording, its provider request contains a temporary audio-object URL and uses the configured regional Alibaba endpoint. Entering the optional Alibaba workspace in Desktop or iPhone Settings selects that workspace’s endpoint in your chosen region; clearing the field selects Alibaba’s regional endpoint. Saving either change while recording processing is enabled requires renewed transfer consent. This does not add a recipient, change retention, or change the Privacy Policy version. Its result can include transcript text, timestamps, and speaker labels within each processed audio window. These labels alone do not identify real people. The dedicated API key is read from the recording owner’s local Vault profile and is not sent to the signed transcript-download address. Signed transfer URLs and transcript bodies are excluded from this adapter’s HTTP logs. Canceling a queued provider task does not establish that all provider-held data was immediately deleted. The adapter alone does not enable chat or Knowledge uploads, enroll voices, or change recording retention; those features require their own explicit activation and disclosures.

On a paired iPhone, uploaded-recording preferences and the dedicated API key use the existing end-to-end encrypted Settings channel to the exact owning Desktop profile. Key input stays in the phone’s current form memory until an explicit Save sends it to that profile’s local Vault; snapshots return only key-presence status. Recording preferences do not change microphone dictation. Chat and Knowledge audio uploads reuse the encrypted, bounded chunk uploader and its existing private Desktop staging/expiry cleanup, then enter the same scoped recording lifecycle. Chat uploads begin when you send the message; after the upload is acknowledged, the message carries a document reference rather than another copy of the audio or a server path. The Desktop validates that reference against the exact owning profile and chat. Retrying an interrupted upload reuses its identity. Unsaved phone upload bytes stay in memory and are cleared on owner change or completion; incomplete Desktop staging expires through the existing upload cleanup. No key or readable audio is stored by the public relay.

The recording-job component keeps content-free recovery checkpoints in the existing local document database. They include the owning profile/chat/document, audio hashes, window timing, chosen provider region/workspace, temporary object and provider task identifiers, processing state and worker lease. They contain no audio, transcript, speaker name, voiceprint, API key or signed link. A deletion checkpoint can outlive the local document solely to finish temporary-VPS cleanup; it is removed after that cleanup is confirmed. An interrupted paid submission without a confirmed task identifier is not automatically submitted again. This checkpoint component alone does not enable recording uploads.

The recording worker uses those checkpoints to resume the same upload or known transcription task, renew temporary worker ownership and finish VPS deletion. It saves a returned provider task identifier before honoring a late cancellation and rejects results from an invalidated document owner. A received transcript must be saved by its scoped document owner before temporary-source cleanup can be marked complete. Provider cancellation remains best effort and does not prove provider data deletion. The worker adds no storage location or recipient and does not itself enable the upload interface.

If Alibaba explicitly refuses a transcription request, or the request never leaves HVAIA (for example a missing key or locked Vault), no paid task exists. After you fix the setting, a retry may send the same temporary audio link again. An upload to HVAIA’s temporary VPS storage that was interrupted or expired before any transcription request may be re-sent under a new temporary reference. Audio not yet sent to Alibaba uses the region and workspace saved in Settings at that time. Deleting a finished recording removes its local data without contacting the VPS or Alibaba, because its temporary VPS copy was already deleted. Recording lists offered to your chat model may include each recording’s upload time. These clarifications add no recipient, retention period or Privacy Policy version.

The scoped recording-file component uses the existing Chat or Knowledge document directory, not a separate global recording library. Original audio and per-window transcripts are private local files. Transcript files include their exact owner, source checksum, timing, words and window-local speaker labels, but no provider credentials or signed URLs. A current document and worker must authorize publication; missing, changed or deletion-marked owners cannot publish. Reads verify the saved checksum. Indexing uses the verified transcript text with speaker labels and timestamps in the existing scoped document indexes, without another transcription request. Incomplete windows are not presented as a complete meeting. These files and derived indexes must be removed with their owning chat or Knowledge document. This storage component does not yet activate uploads or change consent on your behalf.

If you assign a name to a speaker in a recording, that confirmed name is kept with the original recording and used in its transcript and search text. This does not enroll a reusable voiceprint. A fork copies the names known at the time of the fork; renaming or deleting the original does not change that independent copy. Confirmed names and transcript pages may be included in your selected chat model’s context when needed to answer your question.

Document-owned preparation may also retain a verified mono audio copy and a small checksum/duration receipt in that same private document directory. This copy supports bounded transcription windows and later local speaker samples; it is removed with the recording’s owning document. A temporary WAV window is also document-owned and can be removed once its transfer no longer needs it. Preparation preserves a 1 GiB free-space reserve and clears its provisional file on cancellation or failure. Restart verifies completed preparation and reuses existing window identities; it does not treat a partial file as ready or silently change an already-submitted window’s provider configuration.

Recording preparation uses the current desktop’s authenticated private native channel. It passes bounded compressed-audio chunks to a local decoder and receives provisional mono audio chunks back. The native decoder keeps audio in memory only, has no file or network access, and does not log audio or parser details. Cancellation, app shutdown, inactivity or its processing deadline releases that owned buffer. The backend verifies the complete audio checksum before accepting prepared audio; failed or cancelled preparation clears its caller-owned provisional output. Preparation itself makes no provider request and creates no new storage location or upload permission. It does not change microphone dictation or activate Chat/Knowledge recording uploads.

The local speaker-embedding component processes a short audio sample on a supported GPU using a checksum-verified model already installed on the device. It produces a numerical voice representation in process memory, without uploading that sample or downloading a model during inference. The component alone does not save voiceprints, enroll anyone, assign names or activate speaker recognition. Reusable voiceprints require a separate, explicit profile-local opt-in and enrollment, with deletion controls. They are biometric information; speaker similarity is not proof of identity, and unclear matches must remain unnamed. Qualification uses generated samples, not your recordings.

Installing the optional speaker model uses HVAIA’s existing managed model storage and installer. Downloads contact the model host and, for source installations, the package registry for the pinned local runtime dependencies. A speaker operation runs briefly in the current local backend on MPS or CUDA and closes its engine afterward. It adds no always-running service or network listener. Missing packaged runtime components require an updated build, not an unverified replacement. No sample or voiceprint is sent by installation.

The saved-speaker storage component requires explicit enrollment permission. It keeps the name you confirm and a model-specific numerical voiceprint only in your profile’s local Vault, with no source recording, transcript or filename in that record. It creates no new encryption key or cloud copy. An enrolled voiceprint is separate from its source recording and remains until you remove the saved speaker or the profile; deleting the original chat is not deletion of a voiceprint you separately enrolled. Removing a saved speaker destroys all its Vault versions and verifies removal; an unconfirmed failure remains retryable. Matching produces a suggestion requiring confirmation before a person’s name is applied to the transcript. Weak or ambiguous matches stay unnamed. This component alone does not activate the app feature or enroll you or anyone else. The upload and enrollment interfaces require their own explicit activation and renewed consent.

When you explicitly save or match a speaker from a recording, HVAIA selects up to three short, non-overlapping speech samples from that recording’s verified local audio copy. The samples and computed vectors stay in transient process memory during recognition; no additional sample file is saved. Enrollment requires your confirmation before the numerical voiceprint is saved in Vault. The app receives saved names and ids, or a possible-match id requiring your confirmation, never the voiceprint itself. Switching profiles or deleting the source before completion prevents a late enrollment save.

Recording settings and saved-speaker names load only for the currently unlocked profile. API-key drafts stay masked in current form memory until you choose Save, and are cleared after that attempt or when you leave the form. Settings requests use authenticated local APIs; opening the controls does not upload a recording, install a speaker model, or enroll anyone. Profile changes discard late responses and clear the prior profile’s drafts and displayed names. An uncertain settings change requires a refresh before another write is allowed. Leaving Desktop Inference settings with edited recording preferences or a key draft uses the existing Save/Discard confirmation. Refreshing status does not silently discard an edited configuration. These drafts add no storage location or recipient; a key is sent only when you choose Save.

Opening a ready recording displays one bounded transcript part at a time in temporary app memory. The existing native Files player may create a private temporary playback copy, removed through its normal close, failure and restart cleanup. Reopening resolves the original source again. Timestamp controls seek that same recording; they do not send audio elsewhere. If you enable Files sharing, currently visible transcript rows can be supplied to your selected chat model as untrusted source text. Full-recording questions use transcript retrieval under the same profile rules below. Saving a name, checking a saved voice and saving a reusable voiceprint are distinct, explicit actions. A possible voice match never assigns a person’s name without your confirmation.

For the recording feature, retrieval and source ownership are separate. Recordings uploaded in Chat may be retrieved from other chats in the same profile; recordings in Knowledge are also available across that profile. Deleting an upload or its owning chat removes that source, its transcript and its search index. It does not erase information already copied into another chat, exported, or retained through ordinary Memory. Forking makes an independent snapshot of the history and attachments at the chosen checkpoint; uploads added to the original afterward are not added to that fork. Explicit forks and exports may retain their copies after the original source is deleted. These rules apply when the recording interface is activated below.

The private recording-transfer implementation uses a separate service on HVAIA’s managed VPS, not Alibaba OSS storage or the public relay’s content store. When explicitly enabled and used, it receives bounded audio windows over HTTPS and makes them available to Alibaba through signed links that expire within two hours. This service can read the temporary audio; this transfer is not end-to-end encrypted against the staging service. Audio is held in private, non-swappable RAM storage, excluded from disk backups and request logs, and is removed after the owning recording job confirms processing. At expiry it becomes inaccessible; the cleanup worker normally removes expired bytes on its next 30-second pass. Activation also requires safeguards preventing recording-service and HTTPS-proxy memory from being saved in crash dumps; a missing safeguard blocks deployment. An independent cleanup timer enforces expiry when the web service is stopped; a host reboot discards temporary audio. A failed cleanup remains a retryable obligation, never a successful deletion claim. Revoking a link cannot recall bytes Alibaba has already downloaded, and Alibaba’s own retention terms apply.

The public relay only exchanges your existing verified desktop enrollment for a five-minute, purpose-bound transfer credential. It receives no audio, filename, temporary object identifier, signed download link or transcript. The transfer service retains only opaque ownership/object identifiers, byte counts, content hashes, state and expiry beside its temporary audio; there is no public directory, permanent recording library or voice-identification store. An issued management credential can remain valid for up to five minutes after ordinary relay revocation. Profile deletion is stricter: after revoking the profile’s relay access, the relay sends only its existing one-way owner-scope digest in a short-lived, deletion-only credential to the separate transfer service. Deletion cannot report success until that service has closed active audio transfers, removed that owner’s temporary copies and rejected remaining management credentials. This adds no recording list or content at the relay. A bounded owner-digest/expiry barrier stays in the same private RAM store for at most five minutes and one second after the latest deletion attempt. Service startup rejects credentials issued before that startup, so losing RAM cannot revive old access. Explicit object deletion invalidates its fetch link; otherwise the original two-hour expiry applies. These backend components alone do not activate recording uploads. Explicit in-app activation and consent are required before the Chat/Knowledge recording flow uses this new transfer boundary. Existing Chat/Knowledge retention is unchanged by these components.

Recording-service signing keys, service access credentials, HTTPS private keys and certificate-renewal account/recovery records are kept in the server’s Vault, with operator-authorized recovery copies in a separate local operator Vault. They are not embedded in desktop or iPhone builds or written to plaintext operator notes. Short-lived runtime credentials and rendered HTTPS keys use protected memory-backed files; encrypted system credentials bootstrap the dedicated service identities. These infrastructure credentials are separate from your profile’s Alibaba API key and do not create an operator copy of your audio or transcript. Renewal reuses the saved keys; missing account state requires operator approval, not automatic replacement.

When a Voice task uses Al-Jazari for Computer Use, HVAIA reads the human speech already saved for that same call through the exact task handoff. The selected Computer Use model receives that ordered human transcript prefix, including earlier spoken restrictions and corrections, separately labeled from the Voice model’s task assignment. This may include several human turns from the current call; it is not limited to your last sentence. Other calls, later speech, assistant speech, unsent drafts and unshared files are excluded. HVAIA verifies the existing private task association and the exact assignment’s one-way digest in the existing local task record before using this context. The digest is not added to public task projections. HVAIA fails without Computer Use actions if the source cannot be verified, is incomplete or exceeds the existing bounded context size; it does not guess a human message or truncate your restrictions. This additional source copy is temporary and creates no separate transcript store or log.

Voice-created tasks also use the existing private local run checkpoint to keep public model text, issued tool calls and settled results while delegated work finishes or the run recovers. These checkpoints follow ordinary run, chat and profile deletion and device-reset rules. They exclude raw audio, provider-private reasoning, automatic Screen-context images, Shared Files content envelopes and peer-message content through the existing filters. A compact current planner phase and status counts may accompany the resumed task only in model context; they contain no plan text or transcript and create no new stored record. Ending Voice still prevents results from speaking in another call while already admitted tasks remain usable in chat. These changes use the same selected task model recipients, existing conversation and tool data categories, encrypted chat and private lifecycle storage, retention and deletion boundaries. They are part of the unshipped Voice boundary covered by then-current Privacy Policy version 2026-09-privacy-v77; they did not independently advance that version. They do not accept consent on your behalf. They add no operational-log content, support payload or public-relay-readable data. If hosted speech-to-text is enabled, HVAIA sends microphone audio or audio files selected for transcription to the hosted STT provider. If local STT is enabled, transcription is intended to run locally.

Chat transcription uses the microphone selected in Settings > Voice. An explicit device selection is requested exactly and does not silently fall back to another device. Starting transcription also supplies the active profile’s encrypted dictionary phrases as recognition hints to the selected local or hosted STT model, alongside the existing draft context. HVAIA preserves the model’s returned transcription and does not replace words using the dictionary. Dictionary hints are resolved by the authenticated local backend for the captured owner; the dictionary does not pass through the renderer’s audio upload or a readable relay field. Changing chat or profile cancels pending capture and transcription, stops owned microphone tracks, and prevents a late response from changing another chat’s draft. Audio already delivered to a hosted provider remains subject to that provider’s processing and retention practices.

OpenAI conversational voice samples are prerecorded audio bundled with HVAIA. Playing one uses local audio playback only: it does not record your microphone, send your chat or other data to OpenAI, open a Voice session, or consume subscription allowance. Preview playback stops when you cancel it, replace it with another sample, leave the picker, or start a Voice conversation. HVAIA does not keep a playback history for these samples.

Voice preferences keep your selected microphone identifier, conversational voice, shortcut choices, and screen-context preference in the active profile’s existing local speech settings. System default remains a symbolic choice, rather than saving whichever microphone is currently connected. Saving these preferences does not activate capture or send their values to a model. They are excluded from iPhone speech-settings responses. Dictation dictionary words and phrases are stored in one encrypted profile record using the same Vault-protected data key as private chats, with a separate encryption purpose. The record preserves the spelling you enter, is unavailable while secure storage is locked or unavailable, and is deleted with the profile or its device-data reset. Deleting an entry removes it from the current record. Dictionary words are excluded from logs and support diagnostics. Saving or reading a dictionary does not itself send those words to a provider.

When you separately start an OpenAI Voice conversation, HVAIA reads the current profile’s dictionary and sends all saved words and phrases to OpenAI with the Voice session’s startup instructions as spelling guidance. The entries are marked as user-authored, untrusted data rather than instructions; entry identifiers are not sent. HVAIA does not use the dictionary to replace or rewrite OpenAI’s returned transcript. The complete guidance is bounded and all-or-nothing: if the dictionary cannot be loaded safely or every entry cannot fit, HVAIA opens no Voice provider call and asks you to unlock secure storage or shorten the dictionary. Dictionary entries remain excluded from logs, support data and public-relay-readable fields. This uses the already selected OpenAI Voice recipient and the existing speech-recognition purpose, creates no new storage, retention or deletion boundary, and completes the same unshipped Voice data-sharing boundary already covered by this policy; Privacy Policy version 2026-09-privacy-v85 remains current and HVAIA does not accept consent on your behalf.

Voice settings requests carry the active profile, account, tenant, and workspace identifiers only to the authenticated local backend as a precondition. A delayed request is rejected if that owner has changed. The header grants no access and is not sent to a speech provider. Microphone listing reads the device information already available to HVAIA without activating the microphone. An uncertain dictionary save requires an explicit refresh before another change so a lost acknowledgment cannot cause a duplicate entry. Unsaved dictionary edits remain in the settings view’s memory and use the existing unsaved-settings navigation prompt.

Starting a Voice conversation sends your selected microphone’s live audio and the owning chat’s saved public conversation to OpenAI through the connected ChatGPT account. Spoken replies, your transcribed speech, and model-issued task delegations are saved in that original encrypted chat, including public speech interrupted before a turn finishes. They are saved when each spoken turn ends, at least every 5 seconds during a long turn, and right away when Voice hands off a task or you end Voice or switch chats; until then they wait only in the running app’s memory, so an unexpected end such as a crash or lost connection can leave up to the last 5 seconds unsaved. Native audio and private connection events remain temporary; HVAIA does not save a Voice recording. Saved public transcript events include opaque local generation and event references for ordering and provenance, under ordinary chat retention, deletion, and encrypted device-sync rules. A model-issued delegation may also retain one encrypted execution association containing only its local event reference, durable run and assistant-message references, and authoritative start time. A spoken final reply may retain one encrypted association containing the current Voice generation, durable run and assistant-message references, committed-publication identifier and revision, and a one-way digest of the committed answer. HVAIA records that association only on the public assistant transcript events causally produced after the exact validated answer is sent to the same current Voice call; it is never inferred or backfilled for an older, missing, conflicting, interrupted, or ambiguous row. This lets the existing Desktop chat show and recover the regular agent’s tools, approvals, progress and canonical answer after Voice ends, and—only for an exact association—show the Voice model’s separately stored spoken wording from a temporary text popover attached to that answer; it does not create or replay work, replace either authored text, or save a second transcript. These references are excluded from raw provider event data, operational diagnostics, support reports, and readable relay fields. Existing unsent drafts, queued input, attachments and unshared viewer content remain unsent. Voice task admission uses only the saved mode and Deep Research controls together with the existing selected model, project and permission authority. During a model-issued tool task, an exact finalized model-authored progress segment may be sent to the same OpenAI Voice session as silent commentary only after the ordered durable run proves that a tool call follows it. HVAIA may also send that session one finite task-lifecycle state when its meaning changes, such as running, awaiting approval or finalizing. This lifecycle context contains no task identifiers, tool arguments or results, approval body, paths or arbitrary diagnostics. The Voice model may use current lifecycle state and summarize only the latest eligible commentary when you ask for status. When a Voice task needs your approval, Plan review or an answer, or stops without an answer, HVAIA sends that same session one short notice so Voice can tell you; for a question, the notice includes the task’s question text and answer labels as shown in the chat. Your next spoken reply is then saved as your free-text answer to that question in the existing encrypted task history and can never select an option that grants access. A request you make while earlier work in the chat is running waits in the current backend process and starts when that work finishes, while the call stays open; it is discarded if Voice ends first. The local backend log records only fixed Voice handoff and call-ending reason codes and the order of speaking turns (who spoke, whether speech was heard, and whether it was a spoken answer), never speech, task text or identifiers. Everything Voice says after an answer, until you speak again or another task or announcement begins, is kept together as that answer’s spoken version. Only the validated committed authored answer is sent as speakable completion; Voice may phrase it naturally while the exact agent-authored answer, sources and tool history remain in chat, and the encrypted Voice transcript records what was actually said. HVAIA does not generate acknowledgement, progress, or replacement assistant text. Ending Voice preserves already-admitted work and prevents later commentary or results from speaking in another call. This uses the same already-selected OpenAI Voice recipient and conversation/task data category and adds no storage root, retention period, deletion boundary, logging content or relay-readable data. This Voice addition did not independently advance then-current Privacy Policy version 2026-09-privacy-v77 or accept consent on your behalf.

If Voice supplies the first completed exchange in a new chat, HVAIA sends that first user transcript to the chat’s already selected inference provider and model for the same one-time low-effort title purpose used after a typed first message. The prompt-derived fallback remains if the service is unavailable, and a manual title is never overwritten. The title is retained as ordinary encrypted chat metadata and follows the same existing retention, deletion, and encrypted device-sync rules. This title parity uses the existing selected-provider title-generation purpose and adds no storage root, retention period, deletion boundary, logging content, or relay-readable data, so Privacy Policy version 2026-09-privacy-v85 remains current and HVAIA does not accept consent on your behalf.

The native Voice floating panel may temporarily receive and display a normalized current chat title of at most 120 characters and, for an attached project, its display-only basename of at most 80 characters. These labels stay in temporary memory for the current running Desktop session, are inserted as text rather than markup, and are not persisted, logged, relayed, sent to OpenAI, or included in model input. This adds no storage root, recipient, retention period, deletion boundary, logging content, or relay-readable data. This presentation change did not independently advance then-current Privacy Policy version 2026-09-privacy-v77 or accept consent on your behalf.

When automatic Screen context is on, each task that OpenAI Voice delegates may capture one image of the foreground application’s focused window at that handoff. The exact active Voice owner, chat and call generation must still hold the native microphone lease, and HVAIA rechecks the original process, window, focus and protected-content state before using the frame. A changed target, missing permission, protected window, unsupported selected model, disabled setting or ended/switched call sends no pixels and does not choose another window. The PNG and its digest are held only in the current native/backend operation, move in bounded local-memory chunks, and are discarded after the single selected HVAIA inference request is admitted or cancelled. The selected inference provider receives the pixels as temporary task context; OpenAI Voice receives only the resulting model-authored findings or answer through its existing call. The frame is not saved as a chat attachment, run checkpoint, automatic screenshot history, log, support record, paired-device payload or readable relay field. A content-free omission marker may remain in the encrypted run lifecycle, and the selected model’s authored interpretation may remain in normal encrypted chat history. Turning Screen context off stops later observations and discards an uncommitted one without changing the explicit Screenshot control. This automatic context was part of the same unshipped Voice data-sharing boundary covered by then-current Privacy Policy version 2026-09-privacy-v77; it did not independently advance that version or accept consent on your behalf.

Voice startup uses a one-use local reservation and a content-free client heartbeat. They contain only the exact owner, chat, connection generation, lifecycle state and expiry in local process memory, with no persistent connection history or automatic restart. They are discarded when replaced or the app stops. A missing controller heartbeat, changed owner, locked secure storage, or disconnected account ends the call. If transcript storage cannot safely commit, Voice closes instead of silently losing speech or saving it to another chat. A delayed event cannot recreate deleted chat content. Status requests return only the lifecycle and encrypted-chat revision; transcript content is read through the existing authorized chat repository.

Spoken task requests queued behind running or queued chat work retain their order in the current call’s temporary memory. Ending or replacing the call discards unadmitted requests; already admitted tasks keep their ordinary encrypted chat and run records. An admission race can keep an already-queued request pending only when HVAIA proves that no task was created. It never automatically repeats a task whose start is uncertain. These queued requests capture no automatic Screen context. This ordering repair adds no recipient, persistent queue, storage root, retention period or consent purpose.

Native desktop microphone ownership is shared across Voice and transcription windows. The authenticated local backend attests your exact profile scope through HVAIA’s private native channel and issues a one-use microphone reservation. The native host retains only that scope, capture kind, random lease reference, owning window, expiry and revocation status in memory. A short heartbeat keeps an active lease alive; expiry or an authentication transition revokes it. HVAIA waits for confirmed microphone release or destruction of its owning window before admitting another capture. On macOS, enabled Voice and dictation shortcuts are registered with the operating system for the current signed-in renderer only. Shortcut configuration and finite pressed/released events contain no microphone audio, transcript or receiver text; reload, lock, sign-out, profile change and shutdown revoke their authority. These records are not written to logs or support reports and disappear with the owned runtime. Browser-only transcription keeps its existing local page ownership and cannot claim native cross-window authority.

The separate Voice control panel receives only the current call’s local generation, microphone and playback state, measured microphone level, public reply text and structural reply boundaries, and finite control actions. The native host binds it to the owning call before provider startup. Public text is transferred in small ordered chunks and displayed one reply at a time as text, with no separate transcript file or network connection from the panel; Previous and Next controls only select among those temporary replies. Its document cannot access HVAIA’s credentials, general API, filesystem, or other chats. Panel state and displayed replies remain in native and isolated renderer memory until the call changes or the panel closes; the original encrypted chat remains the retained transcript. Closing, reloading, crashing, or losing the panel revokes that Voice capture without restarting it or cancelling previously admitted work. These temporary display copies and control records are excluded from logs and support reports.

The Voice panel’s Screenshot control explicitly shares one window image with the chat and Voice call active when you select it, even if automatic screen context is off. HVAIA captures the bound window directly and checks its process, focus and protected fields before sharing; a changed or unavailable target sends nothing. The native host temporarily holds window and process identity, capture status, a private PNG and its digest. The PNG uses the existing owner-only Computer Use temporary frame area and is removed after attachment import; owned crash remnants follow that area’s cleanup and reset rules. Pixels pass through the normal attachment pipeline to the selected HVAIA inference provider. Existing unsent text and attachments remain in your draft. The new image is retained only as an ordinary encrypted queued or sent chat attachment, with normal deletion and encrypted device-sync rules; the resulting authored answer may return to the original OpenAI Voice call. The floating panel receives status without image bytes or file paths. Changing chat or ending Voice cancels uncommitted sharing, while an already admitted image stays in its original chat. Uncertain sends are not automatically repeated. Temporary images, target identities and digests are excluded from operational logs and support reports. This explicit sharing uses the existing screenshot and attachment data categories, provider recipients and retention rules; it creates no separate screenshot archive.

During screenshot import, temporary image chunks pass between the local native host and the owning HVAIA view. Remaining native image bytes stay only in memory and are discarded when import completes or sharing is cancelled. An incomplete import cannot be submitted to a provider. This local transfer adds no separate image history or provider transmission.

When external dictation is used, its receiver state and native control references remain local and temporary. HVAIA sends the final recording and your enabled dictionary hints to the selected speech-to-text provider without unrelated HVAIA chat text or the receiving field’s contents. The returned transcript is passed once to the original validated text field; that destination application then controls its retention. HVAIA does not save an external-dictation transcript as a chat message or keep a separate recording. Cancelling discards unsent audio and prevents later insertion. Uncertain insertion is not automatically repeated, and temporary audio, transcript and receiver state are excluded from operational logs and support reports.

If hosted text-to-speech is enabled, HVAIA sends committed assistant text, voice options, and the minimum voice-generation data needed to the hosted TTS provider. Ordinary chat, Telegram, and iPhone assistant-speech requests identify an already committed assistant publication; HVAIA resolves that accepted text locally and rejects arbitrary supplied assistant text. A visible planned response that has not been committed is not sent to text-to-speech. Voice previews remain separate explicit preview requests. If you create a hosted custom voice, HVAIA sends the authorized voice sample to the provider for enrollment; HVAIA stores local metadata about the custom voice, not the uploaded sample audio. Generated Studio audio and speech caches can be stored locally.

Studio speech generation follows the text-to-speech provider and voice preferences you save in Speech settings. When Hosted Qwen TTS is selected, the Studio script you explicitly submit and the selected voice options are sent to Alibaba Model Studio for speech generation; local Chatterbox generation keeps those inputs on your desktop. Generated Studio audio remains in the existing profile-owned Studio storage and follows Studio project, profile, and device-data deletion rules. This clarifies the existing opt-in hosted speech boundary without adding a provider, storage location, retention period, or consent purpose.

For a local cloned voice, HVAIA derives a friendly identifier from a newly uploaded filename, but every later saved or supplied identifier must be a bounded ASCII letter, number, underscore, or hyphen value. Listing and synthesis use only exact-stem non-symlink regular files. Deletion removes every exact-stem file variant or link without following it and does not remove a similarly named voice; invalid legacy files remain untouched and unlisted. These local validation and deletion safeguards add no external recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

If hosted embeddings are enabled, HVAIA sends the text chunks needed for semantic retrieval or memory search to the hosted embedding provider, including a Hugging Face Text Embeddings Inference endpoint if you select one. If local embeddings are selected, embedding generation is intended to run locally.

An explicit engineering check can also ask OpenAI Voice to author a harmless task delegation. HVAIA validates the provider’s task text and identity only in memory and returns counts and presence flags. That check does not execute the task, add it to a chat, or publish a substitute assistant answer. It uses an outgoing silent audio signal or one fixed computer-generated speech fixture, without microphone access or audible playback, and consumes the same subscription Voice allowance as its connection. On macOS, the speech fixture is generated offline into the owned temporary testing directory, validated, loaded into memory, and immediately deleted before a provider connection opens. Cancellation also removes the temporary file. This is an engineering input fixture, not HVAIA’s voice provider or a recording of you. Task text, audio, and native identities are excluded from diagnostics and discarded when the check ends.

A separate, explicitly started source Voice connection and task check can capture your selected microphone, play spoken replies, and send the selected chat’s saved public conversation to OpenAI through your Vault-held ChatGPT subscription connection. Its Start control explains that spoken tasks can execute through HVAIA. It excludes unsent composer drafts, queued inputs, attached files, internal tool records, and screen capture from startup context. Native Voice may author a task for your selected HVAIA inference provider; that provider receives the authorized task and context through the ordinary chat execution and approval path. The resulting model-authored answer can be sent back to the same OpenAI Voice call for speech. Ordinary typed messages and attachments keep their existing HVAIA processing path; when bound to that active call, only the resulting committed answer is forwarded for speech, without submitting the task twice. Already-started work continues in its original chat after Voice ends, with normal encrypted chat, artifact, retention, and deletion rules.

Desktop captures the current ready Voice connection when you select Send or Queue, before asynchronous submission preparation. A queued prompt may retain that opaque connection generation in its existing encrypted chat queue record, under the same retention and deletion rules as the prompt. It is not included in model input, task identity fingerprints, logs, support reports, or readable relay metadata. A stale, ended, or explicitly unbound submission cannot acquire a newer Voice connection when it eventually runs. Resuming an existing task never creates a new Voice binding.

Starting that source check in an unsaved new chat first saves the chat and its existing draft through the normal encrypted chat repository. The draft remains unsent and is excluded from Voice startup context. Cancelling or changing the active chat or profile during this save prevents microphone and provider startup; a saved chat keeps its ordinary retention and deletion rules.

This source check keeps raw audio transient and parsed Voice events in bounded temporary process memory until the check’s private handle is released. It does not yet save a conversational Voice transcript. The renderer receives only signaling needed for its connection and finite status controls; provider credentials and native call identifiers remain in the backend. Status evidence and diagnostics exclude audio, transcript text, chat history, task input, model output, and credentials. A temporary local request identifier lets HVAIA stop the original connection after a lost response; it is not sent to a model as chat content. Lock, sign-out, profile change, or disconnection revoke the call and its ability to speak later task results. Cleanup checks never start another paid connection. These explicit developer checks do not start from ordinary app navigation and remain separate from the complete Voice, floating screenshot, and external dictation interface.

The source panel may also display a fixed audio-setup stage, the browser’s audio state, and two yes/no flags indicating current or prior user activation. These temporary local facts distinguish audio setup, microphone permission, and connection waits. They contain no device name or identifier, are not sent to OpenAI or stored, and disappear when the panel closes.

After that source connection becomes ready, the panel sends the local backend one confirmation bound to the same temporary request, chat, and HVAIA connection generation. This confirmation contains no audio or message text, remains in process memory, and is not sent to OpenAI or written to logs. It lets the backend return a completed typed task to the ready connection without requiring OpenAI to repeat an initialization event. A lost confirmation stops the original connection; it does not start another call.

If that Voice event connection fails abnormally, the existing backend log can record its fixed processing stage, a known failure category and transport reason, and standard numeric connection-close codes. It excludes provider close-reason text, raw errors, connection identities, event contents, audio, and transcripts. Normal closure and cancellation do not create this diagnostic. These limited records follow the existing operational-log retention and deletion rules.

If OpenAI reports an error during that source call, HVAIA stops the Voice connection and microphone while already-started chat work continues. The private temporary event capture preserves the original event; only a recognized error category becomes a connection or allowance status in the panel. Provider message text is not used for classification, returned to the panel, or added to logs. This adds no stored content, recipient, retention period, or automatic reconnection.

The separate generated-speech task check uses the same authorized chat execution path with a fixed offline-generated test sentence instead of your microphone. It can use your ChatGPT Voice and selected inference allowances, execute the model-authored task, and retain its normal encrypted chat output. Its local media peer receives no credentials, does not record you, and does not play audio. Temporary fixture files are deleted before the provider connection; cancellation closes the owned peer and Voice call while any already-admitted task keeps its original chat ownership. The check returns only finite measurements and flags, with no audio or native conversation content. A successful decoded-audio measurement does not establish what a human would hear.

Detached chat windows control the same main-window Voice call. The local window bridge carries only the current profile scope, chat and call references, lifecycle and microphone/playback state, measured microphone level, finite errors and explicit control acknowledgements. It carries no raw audio, draft, attachment, transcript, provider credential or microphone lease. These temporary records and submission bindings are cleared when the window or profile changes, controls time out or the window closes, and are excluded from logs and support reports. Opening or reloading a detached window never starts Voice. Starting Voice there selects that chat without sending its unsent draft. Closing the detached window leaves the call under the main window and floating panel’s controls.

Image generation and editing

When hosted Alibaba image generation or editing is selected, HVAIA sends the image prompt, optional negative prompt and generation controls, and any source images you explicitly attach to the Alibaba Model Studio endpoint and model configured in Settings. Alibaba processes those inputs under its own terms and privacy practices. If you stop asynchronous image work after Alibaba returns a task identifier, HVAIA can send that identifier back to the same Alibaba endpoint in one bounded best-effort cancellation request; provider-side work may continue if it is no longer pending, but HVAIA discards late results and does not attach them to the cancelled run. Generated image URLs returned by Alibaba are temporary (the provider documents a 24-hour lifetime), so HVAIA downloads successful outputs promptly. Studio outputs are stored in the active profile’s local Studio image storage; images created by DaVinci in chat are stored in that profile’s local visual-artifact storage. For a successful Studio image, the authenticated desktop can enlarge it, show its exact local output path, and open that path through the operating system. For a successful chat image, the authenticated desktop can show the exact local output path in the timeline and Changes pane, open that path through your operating system, and fetch the protected loopback artifact into a temporary in-app preview URL. The absolute path and loopback artifact URL remain in the local desktop stream and chat history for that presentation; HVAIA removes both from model-facing tool results before the main or specialist model continues. A paired iPhone may receive bounded generated-chat and Studio previews inside the existing end-to-end encrypted device channel; the desktop-only path and loopback URL are removed before that projection. Chat previews follow the existing pair-scoped protected iPhone cache and deletion rules, while Studio detail previews are loaded from the live desktop. The iPhone share sheet receives a chat image preview only after you tap Share/Save, and HVAIA does not automatically write it to Photos or another app. A file written locally just as cancellation wins remains an unreferenced profile-owned visual artifact with no time-based expiry. Chat visual artifacts, including that unreferenced file, are removed only by profile reset or profile deletion; Studio image drafts, source-image metadata, generated-image metadata, and local output files are removed with the owning Studio project, profile reset, or profile deletion. This changes local visual-artifact retention but adds no new content category, provider, storage location, automatic cloud recipient, or public-relay-readable content. The public relay does not receive readable image content: iPhone image prompts, source-image bytes, generation status, generated-chat previews, and Studio previews travel only inside the existing end-to-end encrypted desktop-to-iPhone broker paths. Local image models currently show as Coming Soon and do not send image data anywhere.

When OpenAI is selected for image generation or editing, HVAIA sends the image prompt, supported generation options, and explicitly supplied reference images to OpenAI through an experimental ChatGPT subscription route using your Vault-held connection. These requests can use your subscription allowance. The selected chat inference provider can be different. Validated image bytes use the same DaVinci or Studio storage, previews, sharing, retention, and deletion boundaries described above; no separate OpenAI image folder is created. HVAIA does not fall back to an API key or another image provider. Cancellation closes the local request and discards late results, but cannot guarantee that OpenAI stopped an already submitted operation.

Failed subscription Search and image requests may record a local diagnostic containing only the fixed operation category, fixed connection or timeout classification, HTTP status when known, and whether the provider outcome is uncertain. These diagnostics contain no prompt, image, page content, URL, credential, account or request identifier, provider response text, or raw exception. They use the existing operational-log retention, support-report, and deletion rules and do not trigger another provider request.

Developer-run model evaluations use a separate disposable local Vault and temporary HVAIA data identity. After validating that isolation, the evaluator supplies its Vault client directly to its local evaluation backend. The disposable Vault access token stays in the evaluation process, and model credentials are retrieved from that Vault through the existing credential store. Readiness checks and evaluation cases use the same isolated client; they do not use the Desktop app’s credential bridge or personal Keychain identity. The access identity is checked again before each Vault use. This does not add credential logging, plaintext credential files, a new recipient, or a desktop secure-storage fallback.

Memory, documents, and retrieval

Relative staged paths are traversed from the trusted staged-project root without following symlink or reparse ancestors; if HVAIA cannot prove that authority, it records a readless outcome-unknown review item and does not probe or retain content through the untrusted path.

HVAIA can store memory, knowledge documents, chat-scoped attachments, document chunks, citations, and vector indexes locally for your active profile and workspace. These records help HVAIA retrieve relevant context. An exact retry of the same chat-document upload reuses the matching local document record; reusing that upload identity for different content is rejected instead of replacing or duplicating the record. If a hosted model or hosted embedding provider is selected, retrieved context or document chunks can be sent to that provider as part of the request.

When you opt in to Visual Memory, its content-free references are part of the same chat-scoped Memory session and its derived visual vectors use a separate workspace collection in the same embedded Qdrant store. Searchable text indexes project only actual row text: visual identifiers and digests never become searchable text. Exact publication retries do not rewrite, reorder, re-index, re-embed, or duplicate a provider call; a partial retry adds only missing content or references at the original transcript position, and conflicting source identity is rejected.

HVAIA stores semantic-search vectors in an embedded Qdrant index under the active profile’s existing local Memory data. Qdrant stores vectors plus scoped identifiers, workspace-relative Memory paths, chunk locators, and generation metadata; it does not store secrets, absolute paths, or raw uploaded-document text. Canonical Memory files, original documents, and local document chunks remain the source of truth. The local backend is the only Qdrant owner. An authenticated Memory worker can ask that backend over the current-session loopback connection to reconcile changed canonical Memory and return bounded workspace-relative snippets; this operation does not expose knowledge documents, provider credentials, or content to the public relay. If the vector format, selected embedding model, dimensions, or derived index becomes incompatible or corrupt, HVAIA can automatically rebuild the affected Memory and document vectors. When your selected embedding provider is hosted, that rebuild resends the stored Memory and document text chunks needed to recreate the index to that same provider and can consume provider quota; it runs without a separate confirmation or workload preview under the hosted-embedding choice already disclosed above. During rebuild, documents are not searchable until both required keyword and semantic indexing are complete. Chat deletion removes the exact session’s keyword, vector, and manifest entries before reporting success, and startup removes any orphaned derived entries before retrieval. This changes the local derived-index implementation and can repeat the already disclosed hosted-embedding transmission, but adds no new content category, external recipient, public-relay-readable storage, retention class, or separate consent flow beyond Privacy Policy version 2026-08-privacy-v63.

Hard document deletion makes the document non-searchable before removing its metadata, chunks, vectors, and files, and it reports success only after verifying that all four are absent. If deletion is interrupted, it remains non-searchable and can be retried; a same-root staged artifact directory can remain only until that retry succeeds or the owning profile or device data is reset. Pending Qdrant rebuild state stores only a required flag, monotonic epoch, and validated quarantine directory name, never Memory text, document content, absolute paths, credentials, or provider data. These details restore the existing local deletion and derived-index guarantees and add no new data category, recipient, storage root, retention class, relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

To make supported local-file mutations reviewable, undoable, and redoable, HVAIA may retain bounded before-and-after contents, checksums, modes, and exact local authority paths for affected regular, non-sensitive files. Supported UTF-8 text and bounded binary bytes are stored in the encrypted Changes record; sensitive, symlinked, non-regular, oversized, outside-limit, hard-linked, or otherwise incomplete items remain review-only metadata and do not gain unsupported Undo. The encrypted authority binds each resolved containing directory and leaf name to the directory’s filesystem device and inode. For Memory, this includes the before-and-after contents of the affected canonical domains/<domain_id>/records.json file. Each chat-scoped snapshot is bound to the active profile and originating chat’s Changes scope, is available only through authenticated local access, and is removed when that chat, profile, or local data is deleted or reset. Automation and standalone Scheduled/runtime Changes without a canonical chat capsule currently use an owner-only local compatibility ledger; those compatibility rows remain until a full local-data reset unless a future canonical owner mapping migrates them. Snapshot and transition-intent content is not added to model context, logs, support reports, telemetry, or readable public-relay storage. Before Undo or Redo writes a live project file, HVAIA compares the current state with the recorded common ancestor and desired state under that project’s short mutation lease. Disjoint UTF-8 line edits can be merged so a later chat’s unrelated work remains; overlapping edits fail closed without writing. Binary and other non-mergeable supported content changes only when the current bytes exactly match the expected source state. HVAIA persists the exact source and desired result as an encrypted transition intent before publication, so restart recovery can recognize an interrupted merged state instead of guessing. During Undo, Redo, rollback, or interrupted-operation recovery, HVAIA may briefly create operation-named hidden sibling files and empty owner-marker directories beside the affected local file so it can publish or restore without overwriting a concurrent replacement. Normal completion and proven restart recovery remove these artifacts. HVAIA does not adopt, replace, or silently delete an artifact whose exact operation, owner marker, content, mode, directory authority, or file identity cannot be proven; such an artifact can remain beside the user-owned file for manual review and is outside the active-profile data root. A paired iPhone may request bounded Changes list metadata, a diff, an exact undo, or an exact redo only through the existing end-to-end encrypted live Desktop broker. For readable content, the public relay sees ciphertext only; its separate metadata is limited to authenticated tenant/workspace/chat/request routing and a mutation idempotency key. The live response carries the same opaque encrypted-client request identity separately from the relay’s internal RPC identity so Gateway can validate both correlations without exposing Changes content. Target scope, changeset identifiers, sanitized relative file metadata and counts, diff text, redo capability/reason, conflict/manual-review detail, authority, and outcomes remain encrypted. Desktop derives chat scope from the exact paired owner session. For an Automation run trace, iPhone encrypts only an opaque run id; Desktop requires matching nonempty profile, account, tenant, and workspace ownership on both the durable run and its job, derives an opaque owner-and-job-bound Changes scope, and performs the operation server-side. It neither trusts nor returns a reusable target scope or job id, and ownerless or mismatched records fail closed. Historical cards target their exact changeset, redo is shown only when the refreshed list marks that exact undone filesystem snapshot redoable, ambiguous mutations reuse an operation- and changeset-bound client request identity, and the relay keeps no durable ciphertext queue. The chat review screen enables Undo latest changes only after an authoritative list loads, binds that control to the first undo-supported row, and sends an exact-ID undo. The ios.changesets.undo_latest broker method remains wire compatibility only and is not used by a visible control. This expanded binary capture, live-project merge behavior, and crash-recovery intent require renewed consent at Privacy Policy version 2026-09-privacy-v68.

Before HVAIA dispatches a potentially mutating tool in a profile-scoped chat, it stores an owner-bound pending intent and bounded before-state in that same encrypted chat capsule. The completed before-and-after Changes record is committed before the tool result is acknowledged. If HVAIA stops after dispatch but before that final commit, the pending item remains visible as outcome unknown and requires manual review; Undo is unavailable unless HVAIA has authoritative post-state proof. For Automation or standalone runtimes that still use the local compatibility ledger, the pending marker contains no file content or exact local authority path. This crash-recovery hardening adds no new data category, storage root, external recipient, relay-readable field, retention boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

For completed desktop chats, HVAIA writes each nonempty committed user/assistant turn to the chat-scoped Memory session only after its publication receipt exists; a text-empty row exists only when it contains a valid Visual Memory reference. An exact empty output creates no assistant Memory row. An eligible turn that has only a committed assistant reply is still saved as that assistant row. Delivery fails closed and writes nothing only when the publication carries no prompt text, no reply text, and no verified user image input. Your full chat history is saved for you regardless of whether a turn is eligible for searchable Memory, and internal delegation and peer-coordination content stay excluded from Memory. Searchable text projection filters out raw base64 data URIs completely, indexes only actual row text, preserves structured JSON text, and unescapes quoted repr strings safely. Derived keyword indexes invalidate and rebuild derived text projections via schema versioning without rewriting or modifying historical canonical .jsonl source records. In support reporting, when device storage is exhausted, HVAIA reports a clear storage-full error without fabricating synthetic ticket identifiers or silently dismissing the report interface. HVAIA does not also copy that full raw turn into the workspace-wide learning log, and deleting the chat prevents delayed delivery from recreating its Memory session. The Visual Memory additions and renewed-consent boundary are described at Privacy Policy version 2026-09-privacy-v83 above.

For Apply in an explicit isolated, delegated-integration, or legacy staged workspace, the frozen attachment boundary includes the applicable ordered global Git excludes, repository-local info/exclude, per-directory .gitignore files (including an ignored .gitignore), and independently rooted nested repositories in addition to .hvaiaignore. Apply publishes only the exact changed source leaves; it does not copy or swap the full selected project or its .git directory. Its encrypted local recovery journal retains the changed relative paths and manifests, pinned source-parent and temporary-artifact identities, and content-free Git authority digests needed to detect a concurrent repository change. HVAIA may create random owner-only .hvaia-apply-... backup, staging, hold, and removal directories beside the selected project so publication and restart recovery stay on the same volume. It removes only an exact journal-proven artifact with the expected contents; a replaced, altered, unexpectedly populated, or otherwise unprovable artifact is preserved for manual review, and chat/profile/device reset does not guess at it after the proving journal is gone. Files with multiple hard links remain metadata-only and review-only because replacing one directory entry cannot safely restore every linked name’s shared inode semantics. Ordinary direct project chats do not use this Apply path. These protections do not add a new content category, external recipient, readable relay field, or retention boundary.

For each desktop chat turn, HVAIA may attach recalled Memory excerpts and document evidence to that turn’s model request, after your message. Each item carries its source label, its date and a Memory-relative location, never a path on your computer. So that an interrupted turn can retry or resume with the same context, HVAIA keeps that recalled context only as encrypted data in the chat’s local capsule; the local run record holds only an identifier and a checksum. The encrypted copy is deleted when the run completes or when a newer request in that chat replaces it. Deleting the chat, or resetting or deleting the profile, also removes it. Later turns do not resend it. Because this removes recalled excerpts from plaintext local run records and adds no recipient, data category or retention period, Privacy Policy version 2026-09-privacy-v91 remains current.

Learned memory

“Learn from my chats” is on by default. After a chat has been idle for two hours and its Memory capture has finished, HVAIA sends that chat’s committed prompts and answers to the model you selected for chats. Tool output, attachments and files are never sent for learning. The model writes a short task record of what you worked on. Any personal fact or preference in it must be backed by an exact quote of your own words, which HVAIA checks before saving. HVAIA then combines records into a learned summary of at most 10 KB: profile, preferences, tips and an index of past work. Chats from delegated tasks, Wake Up and automation runs, peer coordination and Side Chat are not learned. A Chrome-restricted chat is learned only by a qualified local model, and its record never enters the learned summary.

Learning runs in the background only while your profile is unlocked, you have accepted this policy version, and no model work for you is in progress. With a local model it stops as soon as you start chatting. It may use your ChatGPT subscription quota and does not pause as you approach a limit. A real rate-limit or credit error makes it wait and retry later. Each learning request appears under memory learning in Profile › Reported model usage. Before anything is sent or saved, HVAIA replaces secret-looking values, such as API keys, tokens, passwords and private keys, with a redaction marker.

The records, the summary, one previous copy of the summary and your on/off choice are stored locally in the profile’s Memory folder under learned/. Your corrections, your saved profile facts and, while learning is on, the learned summary form a profile block of up to 2,500 tokens (or 2% of the model’s context window, if smaller). The block is included with every chat request to the provider you select. This includes a hosted provider you choose later, even if the learned content came from chats you held with a local model. HVAIA keeps an encrypted copy of each chat’s block in that chat’s local capsule so that requests stay consistent between turns.

In Settings › Knowledge › Memory, and from a paired iPhone through the existing encrypted Desktop-bound Settings connection, you can:

view what was learned;
edit or delete any learned claim;
add a correction, which always takes priority and is never overwritten by learning;
turn learning off;
reset learned memory.

Turning learning off stops learning and stops sending the learned summary; your corrections and saved profile facts stay in the profile block. The agent records a correction or removes a learned claim only when you explicitly ask it to. Deleting a chat deletes its record and every learned claim that only it supports, including the previous copy and each chat’s pinned copy, and learning already in progress cannot recreate them. Reset deletes all records, the summary, its previous copy and your corrections. Deleting the profile or resetting local data removes all learned memory with the profile’s Memory folder.

Because learning adds background sending of your committed chat text to your selected model and a new local learned-memory store, version 2026-10-privacy-v92 requires fresh acceptance. Learning starts only after you accept it.

Connected accounts and tools

When you connect accounts or tools such as Google, YouTube, Telegram, WooCommerce, OBS, browser automation, computer use, or MCP-based apps, HVAIA processes the account data and tool results needed for the actions you ask it to perform. OAuth tokens and connector secrets remain desktop-owned and secret-store-backed where the connector supports that model. OAuth callback authorization codes, state values, scopes, account hints, consent parameters, and other callback query data are excluded from HVAIA access logs; logs retain only the safe callback path, request status, and bounded presence diagnostics. This logging hardening reduces local diagnostic collection and adds no new recipient, storage root, retention period, or renewed-consent requirement.

To describe locally available MCP tools to the selected model, HVAIA keeps resettable schema-catalog files under the active local identity. A catalog can contain the server’s exposed tool names, descriptions, input schemas, and safety annotations, but not connector credentials, account content, or tool results. The selected model may read those schemas as part of its existing tool context. Removing a registered MCP server removes its matching catalog, authoritative rebuilds remove stale server catalogs, and local-data reset removes the catalog cache. This shortens retention of derived connector schemas and adds no new data category, recipient, storage root, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

When an MCP tool result contains embedded images, HVAIA removes every raw Base64 image field before that JSON is stored in model context, including unsupported and later images. At most the first supported PNG, JPEG, or WebP image may be saved as a local visual artifact and sent separately to the selected model. If saving or resolving that artifact fails, HVAIA keeps only the sanitized JSON and sends no image continuation; it never restores the raw bytes. This enforces the existing minimization promise and narrows exposure without adding collection, storage, transmission, sharing, retention, or renewed-consent requirements beyond Privacy Policy version 2026-08-privacy-v65.

For Google Workspace, HVAIA requests access only to the enabled Gmail, Drive, Calendar, Docs, Sheets, Chat, Forms, Slides, Tasks, Contacts, and basic Google identity functions needed by its managed Google tools. Google Custom Search and Apps Script are excluded. When you use a Google tool, Google receives the API request and the account or Workspace content needed to perform that action and processes it under Google’s own terms and privacy practices. Your active profile’s local Vault stores its Google OAuth state, user tokens, and public OAuth client identity. A confidential Google app secret is not stored in a profile: source development can read the exact matching secret from the desktop-wide local Vault, while packaged hosted-broker sign-in keeps it in relay-side Vault and transfers user tokens back only through an encrypted, short-lived handoff. Google tool execution remains local to the desktop. Ordinary shutdown, restart, or in-memory connector-cache cleanup does not disconnect your account or delete its stored tokens. Choosing Disconnect Google reports success only after both exact Google token records are deleted and read back as absent; if deletion cannot be verified, HVAIA keeps the connection state, publishes no disconnected event, and asks you to retry. Managed and stateless Google connector processes do not create a second raw debug log; standalone connector logs are owner-only and size-bounded. This enforces the existing deletion promise and narrows exposure without adding a data category, provider, storage location, recipient, retention rule, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v65.

Hosted Google Workspace and YouTube sign-in request each connector’s complete required permissions separately. HVAIA does not ask Google to combine permissions from earlier connections when creating a new sign-in request, so previously granted YouTube permissions are not implicitly added to Workspace consent, or vice versa. Existing connector tokens remain separate in the local Vault. This narrows the authorization request without adding data categories, recipients, storage locations, retention periods, or a renewed-consent requirement.

While a Google Workspace or YouTube sign-in is unfinished, HVAIA rechecks its status using the existing local and hosted authorization services and keeps only an opaque attempt digest and deadline in desktop interface memory. Cancel removes that attempt’s private pending authorization material from its existing local profile Vault record without removing saved connections. Expiry also clears private pending material; YouTube may retain only an “expired” outcome in that same record until another connection, disconnect, profile deletion, or reset. Relay sessions keep their existing short expiry. Cancel does not revoke permissions already granted at Google. This recovery behavior adds no recipient, secret storage location, readable relay content, or renewed-consent requirement.

For that packaged Google or YouTube handoff, the desktop creates one random claim identity and the relay stores only its one-way digest. The first successful claim binds the encrypted token bundle to that identity; another identity is rejected, while the same identity can replay the bundle after a crash or interrupted local save. The relay removes the encrypted bundle only after the desktop writes the credentials to its local Vault, reads them back, and explicitly acknowledges that exact claim. The relay may retain the content-free claim digest and acknowledged session status only until the existing short session expires. A YouTube browser-return link contains another high-entropy random value but no profile, account, or workspace identifier or stable derivative; Desktop compares it only with pending state in local profile Vaults. The Google browser-return link also carries a random nonce and is checked only against the authenticated active profile’s local Vault state. If Desktop status finishes either connection before that browser return, the same profile Vault temporarily keeps only one-way digests of the return value and saved token plus the completion time for at most 15 minutes, so the exact page can report success without another token claim. A different return value cannot change this receipt. A new connection, disconnect, profile removal, reset, or expiry removes it, and it is not copied to logs, WebView storage, model context, support data, or readable relay state. This strengthens profile isolation and token-loss recovery without adding a recipient, readable relay token, storage root, retention class, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v65.

On HVAIA Desktop, Ibn Battuta can use the browser shown in the shared side panel. You and Ibn Battuta see and operate the same tabs and signed-in session. When you select an ordinary credential-free HTTP(S) link rendered by HVAIA, HVAIA first offers its URL to the active chat’s in-app Browser. That routing request stays only in current Desktop process memory and is removed after handling, loss of its profile scope, or deletion of its owning chat. Deleting that chat discards a still-pending link before it can be handed to either browser; selecting another existing chat alone preserves the request in its original chat. If Browser accepts it, the destination becomes ordinary tab state governed by the existing tabs-only storage and deletion rules below. If the native Browser is unavailable, its pane refuses presentation, or native navigation fails, HVAIA gives the same validated URL to the operating-system default browser once so the link does not become inert. Settings sign-in, browser-extension installation, update, and explicitly labeled external actions continue to use the operating-system browser directly. Websites receive normal browser requests, cookies, IP address, and any information entered or submitted to them. When Ibn Battuta acts on a located page element, HVAIA may briefly draw the bundled compact HVAIA cursor symbol inside the live page so you can follow the action. On the first located action in each document, the indicator starts at the viewport center and moves to the exact target over 180 milliseconds, or moves immediately when Reduce Motion is enabled; later located actions move from the preceding target. The active website can observe that transient page mutation just as it can observe the action or focus it receives; the indicator, viewport-center seed, and target coordinates stay in current browser-process memory, receive no input, disappear after 1.2 seconds or trusted human input, and are not separately stored, logged, synchronized, included in support data, or exposed to the public relay. This presentation-timing correction adds no data category, recipient, storage root, retention period, deletion boundary, or readable relay content, does not independently change Privacy Policy version 2026-09-privacy-v77, and does not accept consent on your behalf. An on-demand visual frame requested while the indicator is visible can include it, while semantic snapshots exclude it. On Linux, the continuously displayed human view stays inside the sandboxed Chromium compositor shared by HVAIA’s interface and the native page view; no CEF off-screen frame, shared texture, DMA-BUF, anonymous-memory pixel ring, GTK/Cairo frame, PNG stream, or React image copy crosses that display boundary. macOS and current Windows retain bounded native GPU presentation slots in their current Desktop/browser processes. On every platform, live presentation resources and page pixels are not stored as screenshots, written to WebView storage or logs, sent to a model, included in support data, copied to another device, or exposed to the public relay. They are resized in place for ordinary same-view geometry changes and are released or hidden when the view detaches, its tab or scope changes, the Desktop interface reloads or loses ownership, the browser stops, or HVAIA exits. A Desktop-interface reload removes only that live display lease; it does not clear the task’s saved tabs or the profile’s sign-in cookies. Ibn Battuta may send the selected model a compact semantic description of the visible page or form and, when visual confirmation is needed, one rendered frame captured on demand from the requested current tab and browser revision. The same bounded, on-demand semantic path can include controls and nearby visible context from an accessible embedded document. Model-facing embedded items use only opaque element references and a main-or-embedded scope; child-document URLs, origins, link destinations, and raw frame, document, loader, or browser-engine identifiers are not included. Restricted, inaccessible, or detached child documents are not read, and a replaced document must be observed again before its fresh opaque elements can be changed. To make modern forms operable, that semantic description can pair a control with bounded nearby question, option, placeholder, or editor text and can include rendered form controls outside the current viewport; it does not indiscriminately copy generic page containers. A visually hidden checkbox or radio is included only when a nonempty visible associated label or bounded visible question or option makes it meaningful, the native control is connected and not marked hidden or inert, and its surrounding context is not hidden or inert. Bounded rich-editor context is included only when the existing placeholder-plus-toolbar rule identifies a typeable surface. Semantic results are bounded and marked when truncated. A requested frame is stored as an ordinary profile-owned visual artifact, while its raw encoded bytes are removed from the browser tool result before local history is written. Browser operations and their bounded results may remain in local chat, run, or specialist history; readable page content is excluded from public-relay, support, and external runtime projections. Linux website state lives in an in-memory, non-persistent Chromium partition; macOS and current Windows live CEF data use a private current-session temporary directory removed on normal shutdown. This embedded-document clarification uses the same existing Browser data category, selected-model recipient, storage and deletion boundaries, so Privacy Policy version 2026-09-privacy-v85 remains current. Default in-app routing reduces ordinary OS-browser handoffs and introduces no new data category, recipient, storage root, retention period, deletion boundary, relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v70.

When you choose Print in the in-app browser or use its print shortcut, HVAIA asks the native browser engine to open the operating system’s print dialog for that page. Page content can then be passed to the printer, print service or file destination you select. Those destinations and the operating system may retain print jobs or files under their own settings. HVAIA does not automatically print, send a print copy to a model or relay, or add page content to its logs or browser snapshots. Cancelling the dialog does not confirm that anything was printed; a dispatched or submitted request is not proof of physical delivery. Device-toolbar dimensions, fit and zoom controls remain in current process memory for the live tab and are discarded on tab recreation, hibernation or browser-host restart. Screen-size previews preserve browser identity, touch behavior and device pixel density; their live page remains governed by the browser data boundaries above.

Browser sign-in cookies are shared across chats within one profile and are stored once in that profile’s local Vault namespace. Each chat has a separate bounded tabs-only snapshot; deleting a chat closes and removes only that chat’s tabs and ordinary history, not the shared profile sign-in. On the first Linux Chromium-browser startup, HVAIA preserves saved tabs but intentionally clears legacy CEF website cookies once, shows a concise notice that sites require signing in again, and records the new chromium-v1 engine epoch only after the local Vault confirms the reset. If that confirmation fails, the browser remains blocked instead of using plaintext or an ambiguous old session. Later Linux cookies move only between the in-memory Chromium session and the profile’s local Vault cookie store. A larger cookie jar may use a committed set of bounded Vault records rather than one record. During save or restore, bounded cookie pages remain briefly in the native browser and HVAIA process memory and cross only the authenticated local browser-control connection before the Vault write or native restore finishes. They are not staged as plaintext files, logged, sent to a model or paired phone, or exposed to the public relay. Those Vault records remain on this device and are removed with the profile’s Browser data. A storage-generation check prevents an older queued cookie snapshot from replacing a later committed jar. An explicit confirmed browser-session reset, profile deletion, or local-data reset removes the shared browser cookies and every chat’s saved tabs. The selective Clear browsing data screen currently does not offer Cookies and site data while its complete native cleanup is unqualified. If secure browser state is malformed, HVAIA blocks restore instead of opening an unprotected or partially recovered session; a visible repair action explains that all tabs and site sign-ins for the active profile will be removed and requires direct human confirmation before the scoped reset runs. Older builds can temporarily duplicate cookies into chat records after a downgrade; after re-upgrade, HVAIA scrubs those duplicated arrays, but pre-epoch CEF cookies are never re-imported into Chromium. This one-time engine migration removes old sign-in data, adds no plaintext or non-Vault storage, and requires no renewed consent beyond Privacy Policy version 2026-08-privacy-v66.

Routine typed preparation and ordinary credential-free HTTP(S) links can remain autonomous. The first generic script-capable routine control on an exact top-level origin in an Ibn Battuta task asks whether to allow routine controls on that site for that task; the resulting grant stays only in current Rust process memory and is not written to Vault, history, logs, events, support data, or model context. Consequential actions such as form submission, deletion, upload, download, permissions, page evaluation, bounded network override, opening a credential-free HTTP(S) URL in the default browser or an authority-free mailto: URI in the operating system’s mail application, and clearing the browser session continue to require a separate action confirmation. Authority-style mailto:// values, credential-bearing URLs, relative values, and every other protocol are rejected. Public arbitrary DevTools access is unavailable. Free-text address-bar searches are sent to the selected Google or DuckDuckGo service; Google remains the default. Direct HTTP(S) URLs are opened as URLs and are not transformed into search queries. These shared-cookie storage and deletion semantics require renewed consent at Privacy Policy version 2026-08-privacy-v61; the search-provider disclosure is secondary to that change.

On Linux, direct human keyboard, pointer, scrolling, clipboard, gesture, and multilingual composition input goes only to the focused sandboxed Chromium page and does not pass through React or browser-command JSON. macOS and current Windows retain HVAIA’s bounded, authenticated current-session native browser connection. Human pointer/button state, focus, find state, one-use context-menu capabilities, and per-tab zoom remain in current Desktop/browser-process memory and are not added to chat history, model input, logs, support data, another device, the public relay, or the saved tab-and-cookie snapshot. Clipboard editing stays inside the active browser engine, so clipboard contents never enter React state or browser-command JSON. For each live tab, the engine may download an icon from a URL declared by the page or from the website’s same-origin /favicon.ico location without sending or accepting cookies, then give the Desktop interface a PNG limited to 32 pixels and 32 KiB; the icon and its revision stay in current-process memory and are not stored, logged, sent to a model or another device, included in support data, or exposed to the public relay. When HVAIA uses the unavailable-pane fallback described above, or when you choose Open in default browser or Open externally, HVAIA gives the operating system only the selected credential-free HTTP(S) page, link, or image URL. When you approve a mailto: handoff, HVAIA gives the operating system’s mail application the recipient and optional URI fields such as subject or body. Neither handoff transfers the in-app browser’s cookies, signed-in session, form or composition text, clipboard contents, or passkey material; you may need to sign in again in the default browser. This bounded human-input, favicon, and explicit or fallback on-device browser or mail handoff path adds no HVAIA storage root, retention period, model recipient, or public-relay-readable copy and requires no renewed consent beyond Privacy Policy version 2026-09-privacy-v70.

HVAIA does not create a persistent raw browser log. Nonfatal page-content diagnostics are not copied into a HVAIA log. Bounded local reason codes for startup, renderer, GPU, or sandbox failures may reach the launching process. On Linux, optional performance diagnosis enabled by HVAIA_ELECTRON_PERFORMANCE_DIAGNOSTICS=1 may additionally record Electron/Chromium version, display backend, GPU feature status, renderer crashes, event-loop delay, input-to-paint timing, and dropped-frame counts, but not URLs, page text, typed values, cookies, screenshots, Vault data, or account identifiers. These content-free local diagnostics use the existing local diagnostic boundary, add no external recipient or public-relay exposure, and require no renewed consent beyond Privacy Policy version 2026-08-privacy-v66.

If chat deletion cannot remove its browser state, HVAIA keeps the chat visible and does not report deletion complete. If the exact browser process owned by the current Desktop session cannot confirm that cleanup finished, HVAIA stops only that current-session browser process so its live tabs close; other chats’ separate Vault snapshots remain available for later restoration. This deletion-reliability clarification adds no data category, storage root, recipient, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

If you use Telegram, HVAIA sends the messages in that conversation through the Telegram bot. When the assistant starts an action and provides an activity label, HVAIA may send that label to Telegram exactly as provided; it can reflect your request or task. HVAIA does not send routine action-result progress messages. Approval requests and questions can still be sent when needed so that you can respond. Telegram processes content it receives under its own privacy practices. This does not change HVAIA’s public-relay privacy boundary or the encrypted desktop-to-iPhone chat connection.

Chrome Extension browser-control diagnostics are designed to be bounded and redacted. HVAIA can process page URLs, domains, tab metadata, visible page structure, and action reason codes needed to complete browser tasks, but type-verification errors must not include the text you asked HVAIA to type or the observed final form-field value. When a page embeds another document that the installed extension can access, including a third-party frame, the same bounded visible form and control structure can be included in the Chrome Specialist snapshot and ordinary local tool history. The model-facing snapshot identifies those controls only with opaque frame and element references; it does not include child-frame URLs, origins, or Chrome document identifiers. It also excludes child-link destinations and raw child-injection errors; child controls and links remain actionable through their opaque references. Restricted, sandboxed, unavailable, or site-access-denied frames are not read. Mutating an accessible embedded control uses the same user approval boundary as other Chrome Extension mutations. This clarifies which visible page structure is covered by the existing Chrome Extension disclosure and adds no new data category, recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

Chrome Specialist uses only the HVAIA extension you install in a regular Chrome or Chromium profile. The public packaged extension is installed through the Chrome Web Store; source development may use a separately identified unpacked development extension. Each extension connects through Chrome Native Messaging to the signed HVAIA desktop executable and a private current-user local bridge. The extension does not receive HVAIA’s local API token, and HVAIA does not expose a general local HTTP, filesystem, or command proxy to it. The Native Messaging registration stores the fixed host name, exact allowed extension origin, and current HVAIA executable path in Chrome’s user-scope manifest location; on Windows, user-scope registry values point to that manifest. Source and packaged registrations, origins, and local state remain separate. Removing or repairing the connection removes or rewrites only these HVAIA-owned registration artifacts; it does not uninstall the Web Store extension or delete Chrome.

Each Chrome profile creates one random UUID and stores it with that profile’s automation pause flag in chrome.storage.local. The UUID identifies which profile is connected; it is not a password or credential. In its owner-only, source-or-packaged local state, HVAIA stores only the schema version and UUID of the profile you explicitly selected. HVAIA does not store that profile’s name, visited sites, page content, form content, or timestamps in this selection record. Connection IDs, command ownership, last-seen state, and command/result queues remain only in current-process memory and are cleared when the backend restarts. HVAIA remembers your selected UUID across restarts and does not silently switch to another connected profile when the selected profile is offline. Disconnecting the packaged connector or resetting its HVAIA-owned state removes the selected UUID and current sessions; Chrome’s profile UUID and pause preference remain until you remove the extension data in Chrome.

Website access is optional and Chrome asks for it only after you choose Allow HVAIA on websites in the extension popup. When access is granted and you ask Chrome Specialist to work, the extension may read the requested page’s bounded visible and structural content, identify controls, type or select form content, click, submit a structurally identified form, upload a selected file, and initiate or observe downloads. Navigation does not require an action confirmation. Form edits, clicks, uploads, and structural submissions use HVAIA approvals according to their risk; every click, upload, and submit receives a distinct confirmation. Approval previews may show only the hostname, safe target label or structural description, action type, form field count and total character count, and upload basenames and sizes. They exclude typed field values, passwords and secrets, full page content, and absolute local file paths. A browser dispatch is not represented as proof that a website or business operation succeeded, and HVAIA does not automatically repeat a mutation whose dispatch may have occurred.

The popup’s explicit Save this page to active chat action may read the current page URL, title, readable text, and capture time and store that capture in the active HVAIA chat under the chat’s existing local history, synchronization, retention, and deletion rules. This explicit capture remains available while automation is paused. Pausing blocks automated Chrome control and persists only the pause flag in that Chrome profile. HVAIA may ask the operating system to open regular Chrome at a requested credential-free HTTP(S) URL, but it does not create a separate managed browser profile, stage or sideload the extension into another browser, launch a test browser, or copy or directly read Chrome cookies and sign-in data. User downloads and original upload files remain user-owned and are not removed by HVAIA reset. Chat deletion removes captured page records with that chat; profile/device reset removes HVAIA-owned Chrome selection and installation state and exact retired control-database files, while Chrome extension data must be removed through Chrome. These Native Messaging, optional website-access, profile-identifier, control, capture, registration, approval, and deletion disclosures require renewed consent at Privacy Policy version 2026-08-privacy-v65.

Some OAuth flows can use a HVAIA-hosted broker so the desktop app does not need to ship third-party app secrets. In those flows, the broker participates in the authorization exchange, while durable user token storage and tool execution remain owned by the desktop app. Google Workspace OAuth env files, client-secret files, raw token files, broker bearer tokens, enrollment bearer tokens, and generated local connector packages are not intended to be bundled with shipped HVAIA builds. The hosted broker can publish content-free readiness and failure reason codes so HVAIA can distinguish a temporary service problem from an account reconnect. Those diagnostics must not include Vault tokens, OAuth secrets, secret-storage paths, authorization values, or raw exception text.

Internet search and external retrieval

When you use internet search, deep research, webpage retrieval, or similar tools, HVAIA sends the search query, URL, or lookup request to the configured search or retrieval provider, such as Exa. Search results, citations, and retrieved snippets can be stored in local conversation or diagnostic records when they are part of your workflow.

After a completed assistant response contains a supported public YouTube link, the iPhone app may automatically request that video’s public thumbnail from i.ytimg.com so the chat can show the same preview card as Desktop. The request sends the public YouTube video identifier in the thumbnail URL plus ordinary connection metadata such as the iPhone’s IP address to Google/YouTube, which processes it under its own terms and privacy policy. HVAIA uses an ephemeral, cookie-free request, sends no HVAIA referrer, and does not add the thumbnail response to HVAIA’s disk cache, chat snapshot, public relay, logs, support data, or telemetry. If the request fails, the message remains available with a generic video card. Selecting the card opens the canonical HTTPS YouTube page through iOS. This automatic third-party preview request is included in the fresh acceptance required by Privacy Policy version 2026-08-privacy-v67.

When OpenAI Internet Search is selected, HVAIA sends model-authored search questions and necessary follow-up source-reading requests through an experimental ChatGPT subscription route using the active profile’s Vault-held connection. Returned sources and model-authored research follow the existing citation and chat-history boundaries. OpenAI processes these requests under its own terms and they may consume subscription allowance. This choice is independent of the inference and image providers. HVAIA does not send those searches through Exa or substitute API-key billing, and merely viewing provider readiness makes no search request.

During delegated research, the selected inference provider can read the selected Search provider’s tool names and input schemas through HVAIA’s restricted catalog tool. These catalogs contain capability descriptions, not credentials, search results, or unrelated local files. HVAIA creates temporary derived catalog files beneath the profile’s existing tool-catalog storage and serves only the original in-memory contents for that task. The read authority ends with the task, and normal cleanup removes its temporary files; interruption of the app or a cleanup failure may leave those non-secret derived files within the existing profile/reset boundary. Catalog tool exchanges follow the existing chat-history rules. This scoped discovery introduces no new external recipient or personal-content category.

When you save an Exa API key or choose Test connection, HVAIA sends the fixed non-user query Example Domain to Exa once with a one-result limit. This checks authentication and connectivity, may consume provider quota, and sends no chat, Deep Research request, user search, or attachment content. The returned result is not retained for search quality. HVAIA stores the key only in your active profile’s local HashiCorp Vault. It keeps only a safe verification reason and check time in process memory, associated with the active profile and a process-salted one-way key tag; it stores no key, provider response body, query result, endpoint, or raw exception there. Saving, deleting, replacing the key, or restarting HVAIA clears that verification state, and merely opening or refreshing Settings does not contact Exa. This verification request and process-memory state require renewed consent at Privacy Policy version 2026-08-privacy-v65.

System One (Jev by TypeSafe)

System One is optional and off until you save a Jev API key in Settings → Inference → System One. HVAIA stores the key only in your active profile’s local HashiCorp Vault and never shows it again. When you save the key or choose Test connection, HVAIA asks TypeSafe to list the models the key can use; this checks the key and sends no chat, page or browser content. HVAIA keeps only the check’s safe reason and time in process memory, tied to the active profile and a process-salted one-way key tag; saving, replacing or deleting the key, or restarting HVAIA, clears it. Opening or refreshing Settings does not contact TypeSafe.

With a saved key, when Ibn Battuta uses the optional Uber app in the in-app browser, HVAIA sends TypeSafe the current Uber page as a numbered list of its visible controls — their roles, labels and shown values, such as place names, fares, pickup times, ride names, rider names and payment-method labels as Uber shows them, and whether a control is selected, checked, expanded or focused — with the page title and path and short questions about the page, which can include the pickup and destination you asked for. HVAIA uses one full current semantic observation for this reading and the helper’s compact view. Private browser revision identifiers used to check freshness stay in process memory and are never sent to a model or TypeSafe. Controls too small to see, password and one-time-code values, card numbers and security codes the browser already hides, cookies, full page addresses and their query strings are not sent. TypeSafe returns only choices and probabilities. HVAIA uses them to find where to act; they grant no permission, never press a booking control and never decide whether a ride was requested, and every action still follows your permission mode and the browser’s checks. Page content from your regular Chrome profile is never sent to TypeSafe.

HVAIA checks the fresh page before each read; navigating that tab to another site does not allow its content to be sent to TypeSafe. Visible list rows that activate an editable field are included with that field, using their existing labels and shown values. Targeted page search can also return short visible labels rendered in plain DIV or SPAN elements, including custom controls whose text is split into inline spans or accompanied by a decorative icon. These labels are limited to 300 characters; ordinary snapshots do not collect generic page containers. These use the same browser-page data, recipient and retention rules. Deleting or replacing the key prevents the old read from sending retries or additional reading passes. Stop cancels an active read or retry wait, and a late answer is ignored. These safeguards add no recipient, stored content or retention period beyond this policy version.

HVAIA keeps no copy of what it sends. The Uber result and run history keep only content-free reading diagnostics: whether System One or the built-in reading was used, the model version, time taken, page size, confidence band, whether an answer was used and a failure reason code. Bounded phase timings and counts of browser actions, page reads, waits and recoveries help identify delays. The browser assistant receives compact diagnostic totals; the detailed phase breakdown remains in the original local run result. These diagnostics contain no page text, addresses, payment labels or Jev answers, use ordinary chat/run retention and deletion, and create no new storage location or recipient. TypeSafe processes these requests under its own terms and privacy policy; TypeSafe states that it does not train on customer requests, and offers zero data retention only on enterprise plans. Deleting the key stops all further sending, and profile deletion or local data reset removes it with the profile’s other Vault secrets. This new recipient requires renewed consent at Privacy Policy version 2026-09-privacy-v91.

Separately, the in-app browser’s page reads now include the page’s current width and height so Ibn Battuta can notice when you resize or zoom the browser. This layout size is sent to the selected model like other browser observations and is not stored separately.

To activate an ordinary text field, the browser can privately derive a click point from that field’s observed bounds and check that the field receives the hit. That point stays in the current browser process; it is not added to model responses, logs or stored history. This uses the same page geometry and adds no recipient or retention period.

iPhone Anywhere Access and public relay

The iPhone app uses app-owned preferences for pairing and routing hints, checks metadata of its own files and user-selected imports, and checks available device storage before writing protected local files. Import metadata lets the phone reject a selected file that changes while it is being read; storage checks can stop a write when space is insufficient. The app’s Apple privacy manifest declares these existing purposes. These declarations add no tracking, recipient, data collection, storage location, or retention period and do not change the current consent version. For a successful generated chat video, Desktop may derive one bounded JPEG first-frame poster and include only that poster in the existing end-to-end encrypted chat snapshot. The original MP4 bytes, desktop path, provider URL, and authenticated loopback URL are excluded. The poster may remain in the paired iPhone’s file-protected Chats cache with the message, under the existing per-message preview budgets, and is removed by chat deletion, unpairing, pairing replacement, profile reset, or device-data reset. The public relay sees only ciphertext and routing metadata and cannot read or durably store the poster.

The protected iPhone chat snapshot can include delegated-chat lineage and bounded activity needed to match the desktop experience: child labels, kind, attachment and join state, source and target chat/run identifiers, status, reason code, state version, changed relative file paths, test names and outcomes, and whether a sealed changeset is ready. Its ordinary encrypted assistant_segments, tool_invocations, and reasoning_segments may also contain the user-visible inline-helper prose, tool or interaction records, and finalized readable provider-authored summaries already persisted in the source chat; raw reasoning and private runtime context are excluded. This readable delegation information exists only inside the end-to-end encrypted device envelope and the pair-scoped iOS file-protected cache. It is removed by the existing chat deletion, unpair, pairing replacement, profile reset, and device-reset paths. The public relay may route the opaque encrypted envelope and content-free ordering metadata, but it cannot read or durably store delegation labels, lineage, task content, helper prose, summaries, tool inputs or outputs, results, tests, file paths, or changeset references.

Before you accept the current Terms and Privacy Policy, HVAIA only checks the local sign-in and legal-consent state needed to show the legal-consent gate. It does not hydrate chats, workspace data, connector settings, direct-update checks, or iPhone Anywhere Access synchronization. This prevents hidden iPhone runtime-config, gateway, or relay-key activity while HVAIA is showing the legal-consent gate.

Source/development HVAIA includes the HVAIA-operated development relay address in code so iPhone Anywhere Access does not require a developer or user to configure a relay URL on each machine. Merely loading that public address creates no relay request. After the active signed-in profile accepts the current Terms and Privacy Policy, HVAIA offers an optional email-verification step during onboarding and from Profile settings; skipping it leaves local HVAIA usable but keeps online relay access unavailable. When verification starts, the local backend sends the active profile’s raw email plus opaque install and profile bindings to the HVAIA relay solely to deliver a six-digit code. The relay sends Hostinger Email that recipient address, code, and minimal transactional delivery metadata over certificate-validated TLS SMTP from no-reply@hvaia.com; the message contains no open or click tracking. Hostinger processes that delivery under its service terms and privacy policy. The relay does not persist the raw email, raw code, or plaintext verification proof: it keeps the normalized-email SHA-256 digest, a keyed one-way code check, bounded challenge state and timestamps, and the digest and opaque install/profile binding of the current proof. Codes expire after 10 minutes and allow at most five failed completion attempts. Digest-only challenge records remain for one rolling hour solely to enforce a restart-persistent one-minute resend cooldown and five sends per email digest; this includes mail attempts whose status remains delivery_pending or delivery_uncertain, neither of which can be completed. Admission is persisted before SMTP, so unavailable/full storage prevents transmission rather than losing the limit evidence. A new verified proof for the same install/profile replaces the prior proof. After the user enters the code, Desktop stores the opaque plaintext proof, verification time, email digest, and profile id only in that profile’s local HashiCorp Vault. Enrollment then sends the proof rather than the raw email; the relay derives opaque hosted desktop principal, tenant, and workspace identifiers from the verified authorization digest plus the proof-bound local profile, derives the host identifier from that owner binding plus the install, and separately checks the approved-email digest. These hosted identifiers need not equal the local profile’s identifiers, and the local runtime keeps only the separate profile binding needed to select its Vault credential. Verification therefore remains distinct from approval for online access. An invalid proof is removed locally before retry, and removing the profile removes its local proof, relay credential, relay runtime state, and install id. An explicit development route can override the code-owned address but cannot weaken these consent, proof-binding, Vault, TLS, approval, or content-blind relay boundaries. This one-hour limit-evidence clarification adds no raw-email/code persistence, new recipient, or renewed-consent requirement beyond the current Privacy Policy version 2026-09-privacy-v71.

HVAIA’s iPhone Anywhere Access uses a content-blind relay design. While the iPhone onboarding step or Desktop Settings > Remote Control is visible and no trusted iPhone exists, HVAIA may automatically create and renew a transient pairing session after secure relay readiness is confirmed. The pairing QR stays hidden until you choose Connect; background preparation does not trust or connect an iPhone. This display change adds no data category, recipient, storage, retention, or consent requirement. Relay enrollment is initiated only by the desktop process that can securely save the returned credential in local Vault; least-privileged connector workers without Vault access do not submit a second enrollment request. The public relay is allowed to store routing, trust, activation, presence, transient pairing-session status, the desktop public-key metadata (public key, key identifier, and algorithm) bound to that QR session, a content-free retry idempotency key, and a content-free completion snapshot for a consumed pairing session (device identifier and name, replaced-device identifier, host identifier, and iPhone public-key metadata), plus desktop broker readiness/health reason codes, connection/session capability labels, rate-limit, revocation, and diagnostic metadata needed to connect your phone and desktop. The desktop key metadata expires with the transient QR session and never includes a private key. Replacement pairing polls only the exact QR-session nonce it created to determine whether that session is pending, completed, or expired and may return that trusted-device snapshot after completion. This does not expose readable workspace content, refresh tokens, private keys, chats, automations, Scheduled tasks, Studio projects, drafts, attachments, approvals, run histories, or tool timelines to the relay.

The relay accepts a nested value only for the exact encrypted envelope, validates that envelope’s closed authenticated schema, and then treats its ciphertext as opaque. All other readable routing metadata is limited to allowlisted strings no longer than 512 characters, finite numbers, booleans, or null. Any other object or list is rejected at its parent field without inspecting or exposing child keys; unknown readable strings are also rejected. This enforces the existing content-blind guarantee and adds no data category, recipient, storage, retention, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

Pair replacement uses a two-phase trust transition. Until the iPhone confirms that it saved and read back its candidate Keychain bundle, the relay keeps the existing trusted device active and stores only an expiring, content-free provisional record: device and workspace routing metadata, iPhone and desktop public-key metadata, creation/expiry time, and one-way hashes of the candidate refresh and commit credentials. The relay does not store the raw refresh credential, raw commit credential, either device’s private key, or readable user content. The iPhone keeps the candidate credential and one-time confirmation proof only in its app-scoped Keychain across an ambiguous timeout, transport loss, or relay failure so it can retry the same confirmation after reopening; it removes that candidate after successful promotion, an explicit invalid or unrecoverable confirmation, disconnect, reset, or scoped local-data cleanup. Confirmation promotes the new device and deactivates the old one; expiry or explicit revocation removes abandoned provisional relay state without replacing the existing trusted device. This recovery clarification adds no new recipient, readable content, relay storage, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v50.

When you select Cancel Pairing, HVAIA asks the relay to delete the still-pending pairing session for the current account and workspace before the desktop treats cancellation as complete. A cancelled code can no longer be used to establish iPhone trust.

To keep an uncertain QR-creation response from leaving a usable code behind, the desktop may retain the content-free pairing idempotency key, exact QR nonce, and the already-authenticated account, tenant, workspace, and desktop-host identifiers that owned the request in app memory while it reconciles that uncertain response across onboarding and Settings. Those four content-free owner fields are required on every creation and cancellation request and are compared with the authenticated relay owner and the nonce’s stored desktop host; missing, partial, or changed owners fail closed; raw access tokens are not stored with this record. HVAIA clears the transient lifecycle after the exact session is adopted, cancelled, confirmed inactive, or has passed the relay’s maximum QR lifetime plus a safety margin. This adds no readable user content or durable local storage.

When user content crosses the public relay, it must be end-to-end encrypted between your devices and only ephemerally buffered by the relay as needed to transmit it. Your iPhone may keep its own protected local cache for offline or app-continuity behavior; chat and workspace cache files use iOS file protection so the cache is protected by the device’s local data-protection controls. For Chats, that iPhone cache can include active chat sidebar rows, cached message history, bounded validated display previews for image attachments, user-safe run status, reason, and diagnosis metadata (run_status, run_reason_code, and run_diagnosis), and text-only unresolved-prompt continuity records for direct or queued submissions in the paired workspace so conversations, unsent turns, and actionable failure guidance survive an app restart. A text-only continuity record can include the prompt text, client and retry identity, submission order, attachment count, compact submission options, and draft base revision needed to preserve order and retry the same logical text turn. A normal response can be included in this encrypted device-to-device cache while the backend is finalizing; the encrypted snapshot carries only neutral run status, reason, and diagnosis metadata, not any reviewer state, transcript, or feedback. The public relay cannot read or durably store either the response or that status. Every encrypted desktop-to-iPhone write is checked by the relay against the currently active paired iPhone public-key identifier before storage or forwarding. If an iPhone key changes while the desktop is encrypting a frame, or its pairing is no longer active, HVAIA discards or refuses that ciphertext and rebuilds only for the current paired device; it never sends a plaintext fallback or returns ciphertext for a former key. HVAIA does not derive a substitute key or send readable content as a fallback. HVAIA canonicalizes relay encryption metadata locally before every outbound envelope so content-routing and status fields are normalized consistently. Original attachment bytes retained only to retry an unsent prompt stay in iPhone app memory and are not written to this cache. They may survive a transient network interruption for the bounded automatic-retry window and remain memory-only for a same-session manual retry, and are purged on chat deletion, explicit disconnect or unpair, successful pairing replacement, or app termination. A restored unsent attachment prompt is therefore shown as interrupted and asks you to attach the file again instead of offering a retry that no longer has the original bytes. Pair-scoped cache filenames and cleanup prevent content from an earlier paired desktop from loading after a replacement pairing. Those cached fields stay inside the end-to-end encrypted device envelope in transit; the public relay cannot read or durably store them. For Automations, Scheduled tasks, and Studio, that iPhone cache can include active sidebar rows and the last selected item, including the selected Studio project/take summary, so those lists load quickly and remain available as read-only offline views when the desktop is unreachable. Scheduled changes are refreshed from a complete encrypted desktop snapshot; a failed refresh keeps the prior protected list rather than erasing it. A pending Scheduled save or rename can retain the user’s local draft only until it succeeds, fails, or is retried. Archived chats, archived automations, archived Scheduled tasks, and archived Studio projects are not part of the active offline lists.

For encrypted Studio and Wake Up workspace updates, Desktop keeps the latest snapshot in current-session memory until it is published. If an updated snapshot fails after bounded retries, Desktop can try that same version again during reconciliation, including when an earlier version was already delivered. Desktop marks the submitted version delivered only after relay publication and its local commit succeed. This adds no readable or durable content store on the public relay.

Your iPhone stores the paired gateway or relay route locally so reconnect and short-lived token refresh can return to the same paired desktop route after app restarts or rebuilds. The route is connection metadata, not chat or workspace content. Its protected local composer cache may also store content-free per-field desktop revision counters and pending base revisions alongside each draft so an older phone edit cannot replace a newer desktop edit. Temporary composer edit generations used to keep focused typing stable exist only in iPhone app memory; they do not add relay-visible fields, durable storage, logging, retention, or sharing. The iPhone may also store local sidebar organization preferences, such as pinned Automation, Scheduled, or Studio row ids, so the mobile workspace stays consistent across refreshes. Automation, Scheduled, and Studio pin changes from iPhone can also update the paired desktop’s local sidebar preference when the desktop is online. Refreshed iPhone access tokens are short-lived, scoped connection credentials; they let the public relay verify the paired phone across relay workers without storing readable workspace content. The durable iPhone refresh credential and device-to-device private key are stored in the app-scoped iOS Keychain so an ordinary app relaunch can restore the same protected pairing without replaying a one-time QR session. Those protected credentials rotate only after a refresh completes successfully for the still-current pairing and are removed when the pairing is disconnected or replaced. If you disconnect, unpair, or replace the paired desktop while an older refresh is in progress, HVAIA discards that stale result before it can replace the new refresh credential, trusted desktop key, route, or connection. Starting Disconnect cancels older pairing and reconnect work and keeps control of the connection until revoke either succeeds or reports a terminal failure, so a late refresh cannot silently reconnect the phone. If two accepted pairing attempts overlap, only the newest attempt may store its pairing identity, refresh credential, iPhone private key, trusted desktop key, route, workspace scope, or connection; a late result from the older attempt is discarded. A disconnect/revoke attempt is also bound to the pairing that started it: a newer pairing cancels the old disconnect before it can use the newer pairing’s credential, clear the newer pairing, or show a stale disconnect error. If the refreshed authorization identifies a different tenant or workspace for the same pairing, the iPhone clears the prior workspace’s protected cache, in-memory retry data, and visible workspace state before adopting the new scope.

The iPhone treats only Apple’s explicit Keychain item-not-found result as a missing credential. A lock, entitlement, decoding, I/O, or other Keychain failure is shown as a secure-storage problem and never interpreted as unpaired state. Disconnect, revoke, replacement, and reset remove and verify candidate and legacy copies before deleting the active pairing bundle, and clear non-secret routing and workspace state only after readback proves all credential material absent. If remote revocation succeeds but local Keychain cleanup remains incomplete, HVAIA keeps a visible cleanup-pending state and retries instead of reporting a clean local disconnect. This narrows accidental credential retention and adds no data category, recipient, storage root, or renewed-consent requirement.

If an iPhone composer-draft write or readback verification fails, the newest edit remains authoritative in current app memory, stays marked unsaved, and produces a visible retry warning; serialized protected writes prevent an older overlapping save or protected file from replacing it while the app remains open. The next save for that draft retries the dirty record, and HVAIA reports it saved only after exact protected-file readback succeeds. An app exit before a successful retry can still lose that memory-only newest edit. This reliability behavior adds no external recipient, relay-readable field, storage root, or renewed-consent requirement.

HVAIA iPhone pairing and control use hosted Anywhere Access only. HVAIA does not offer a Local Wi-Fi or VPN fallback path for iPhone pairing or desktop control. Hosted relay traffic still receives only routing metadata, content-free ordering and status facts such as state version, last-updated time, and whether a chat has any messages, plus encrypted envelopes. It does not receive readable chats, drafts, workspace content, or generated audio, or generated images.

The local profile identifiers used to authorize an unlocked Desktop and the opaque account/workspace identifiers issued by the hosted relay remain separate identities. Before Desktop decrypts an iPhone envelope addressed to a hosted relay scope, it authorizes the exact local owner and verifies server-side that the owner’s current ready relay enrollment maps to that exact hosted scope; a caller-supplied scope is never sufficient. A missing, stale, disabled, or mismatched mapping fails closed. This tightens the existing end-to-end encrypted authorization boundary without adding a data category, recipient, storage root, retention period, deletion boundary, relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

For Gateway connection security, HVAIA checks the requested host and, when a browser supplies one, the browser origin before accepting a WebSocket. A trusted relay proxy may supply the immediate client network address only when that proxy was explicitly configured. After a failed authentication attempt, the current Gateway process converts that address into a salted one-way digest and keeps only the digest, a bounded failure count, and an expiry time in process memory; it does not retain the raw address in its throttle state, and the record is removed after success, idle expiry, or process shutdown. Gateway reconnect replay is likewise bounded and separated by tenant, workspace, and session. It may keep public-safe event payloads in process memory, but an end-to-end encrypted mobile frame leaves only a content-free cursor barrier and never its ciphertext or plaintext in replay history; a phone that missed such a frame refreshes from its encrypted Desktop source of truth. APNs registration updates only the existing push-token record for the authenticated phone and uses a stable one-way idempotency value derived on that phone; another paired-device identity cannot overwrite it. The mobile access-token signing key is separate from Gateway administrator credentials, remains in local HashiCorp Vault, and is supplied only to the Gateway edge process that signs or verifies those tokens. These changes narrow existing security metadata and secret handling without adding a new data category, recipient, durable storage location, retention period, telemetry path, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v64.

While macOS notification permission is pending, HVAIA keeps only a temporary in-process pending flag and completion state. This prevents duplicate prompts while other local operations continue. If the local service bridge is busy, Saved Logins receives only a fixed busy status and refresh guidance. Rejected local request bytes are discarded within bounded time and memory without executing the request or retaining its contents. These recovery changes add no stored record, logging, external recipient, or credential disclosure, and do not automatically repeat a saved-login action.

Notification consent is checked against the exact profile, account, and workspace identity currently held by your local app. Switching profiles does not transfer consent, and deleting or changing that identity prevents an existing notification service from using its earlier acceptance. A successful check reads your existing acceptance without changing it or accepting a policy on your behalf. This clarification adds no data category, recipient, storage location, or retention period.

If you enable Notifications, HVAIA Desktop keeps a profile-owned local notification database containing your notification choices, content-free event type and urgency, opaque source and route identifiers, versions and one-way semantic keys, generic per-channel delivery state, retry timing, Desktop-seen acknowledgement timestamps, badge/resolution/activation state, and short device-presence leases. That database also keeps one content-free last-notified receipt for each installed Cloud App or Skill update and quarantined add-on source/version so pruning an old delivery row does not repeat an unchanged alert; the receipt is removed after confirmed source removal or replaced when the source version changes. The store is bound to its exact profile owner, and mismatched legacy rows are not exposed or reassigned. It does not store notification copies of prompts, chat messages, model answers, task or project titles, tool arguments or results, file names or paths, generated media, credentials, or raw error diagnoses. Opening an exact destination records all existing matching notifications as seen on this Desktop and removes them from its app-badge count without resolving the shared source or changing paired-iPhone eligibility; a route already visible when an event arrives records the same acknowledgement and suppresses only its redundant Desktop banner. The authenticated local notification panel may temporarily hold the active profile’s bounded current source label, fixed event phrase, and creation time in renderer memory; opening the panel makes no acknowledgement, and selecting a notification resolves its current stored route, navigates, then records only that notification as seen on Desktop. The panel clears this memory on lock, profile change, or unmount and never writes it to browser storage. While a paired Desktop is live, the iPhone Notifications sheet may receive the same bounded current source label, fixed event phrase, creation time, and total only inside its end-to-end encrypted response and hold them temporarily in current-process memory. It does not write them to UserDefaults, the protected chat cache, Core Data, files, or Keychain. A transient connection loss may preserve the same-scope process view as stale and read-only; explicit disconnect, unpairing, pairing/scope replacement, reset, or app exit clears it. Opening the sheet does not acknowledge anything; selecting an item atomically activates that existing notification before navigating to a supported live Chat, Automation, Scheduled, or Studio route. During the additive migration, pre-existing notification rows are treated as already acknowledged instead of appearing as newly unseen. Start alerts are eligible for delivery for up to five minutes, ordinary update alerts for up to 24 hours, and attention alerts until resolved or for up to 30 days. An expired quiet alert’s content-free intent and notification identifier may remain for up to 30 days so profile deletion can remove a matching pending native activation without exposing or reopening the route; resolved attention metadata is likewise removed after 30 days, and local-data/profile reset removes the owning notification database. This uses the existing notification database, authenticated loopback API, end-to-end encrypted live iPhone broker, and retention/deletion boundaries; it adds no new content category, persistence root, external recipient, public-relay-readable field, retention period, or renewed-consent requirement.

Native Desktop activation additionally keeps an owner-only atomic file in HVAIA’s identity-scoped application-state directory with at most 64 pending records for up to 30 days. Each record contains only a random activation id, random notification id, and capture time. The record is written before a live click event, is read non-destructively, and is removed after authenticated navigation succeeds or the backend confirms the route is terminally unavailable. Lock, wrong-profile, or temporary backend failures retain it for retry. Profile deletion removes matching notification activations before deleting that profile’s notification store, and full local-data reset removes the complete file. Immediately before native delivery or authenticated notification-panel rendering, HVAIA may read the current profile’s user-facing Chat, Automation, Scheduled, Studio, model, Cloud App, or Skill name, normalize it to one bounded line, and use it as the banner title for native delivery or the panel title for in-app presentation; if no safe current name is available, the title is HVAIA. The body is a fixed event phrase such as Response ready, Approval needed, or Task failed and cannot be supplied by a user, model, connector, or notification producer. HVAIA does not add the source name to its notification database, activation file, logs, support data, or diagnostics. Desktop passes it only to the local native notification boundary or its authenticated local renderer. The renderer discards it with the notification panel state; the operating system’s Notification Center may retain the rendered title and body until the user or operating system dismisses them under normal notification settings. Delivered or already-submitted Desktop notifications remain there after HVAIA exits so a click can cold-launch HVAIA and revalidate the opaque route; HVAIA clears its app badge on exit but does not erase those system notifications. The content-free local activation and discovery records add no readable work content or external recipient. Opening a banner resolves its opaque route only after local authentication or authenticated paired-device revalidation.

For iPhone push delivery, the authenticated HVAIA iPhone sends its Apple Push Notification service device token and sandbox/production environment to the Gateway only after you explicitly enable iPhone notification permission; merely opening the app does not show the first permission prompt. Notification creation and delivery also fail closed while the owning Desktop profile has not accepted the current Terms and Privacy Policy. The raw token and HVAIA’s APNs signing key remain only in HashiCorp Vault. The Gateway database keeps a keyed one-way token digest, Vault reference, exact canonical account/device/workspace ownership, notification preferences, opaque route-capability digest, delivery reservation/finality, expiry, and bounded reason codes. HVAIA supports one active iPhone notification registration for that owner scope. Trust revocation, replacement, explicit push deregistration, or an APNs invalid-token response atomically deactivates the exact registration and records a content-free cleanup obligation containing only its digest/reference, owner scope, environment, safe reason, attempts, and retry time until Vault deletion succeeds. The obligation contains no raw token and cannot delete a newer registration.

If you pair the same iPhone to a different account or workspace, HVAIA retires its previous notification registration through that same cleanup process before registering it for the new pairing. An authenticated retry can finish interrupted cleanup. Recovery checks the current pairing and exact registration so a late attempt cannot remove or replace a newer registration; it never reveals the previous owner’s identifiers to the new owner. While the app is active and notifications remain permitted, the iPhone can retry temporary registration failures with a delay, keeping retry state only in app memory. A Desktop configured for hosted delivery can also resume delivery after enrollment becomes ready during the same session; each send still rechecks the current profile, host, enrollment expiry, and Vault credentials, and explicitly disabled delivery stays disabled. These recovery paths add no data category, external recipient, storage root, or renewed-consent requirement.

HVAIA sends Apple only a closed notification payload containing the device token, generic HVAIA fallback title, one fixed event-specific localized phrase, nonnegative integer badge and optional default sound, HVAIA category, expiry/priority, opaque collapse/thread identifiers, random notification and route-capability identifiers, a positive source version, and—when available—one source name encrypted end to end to the exact active paired iPhone. The public relay and Apple can observe the fixed event class and encrypted envelope but cannot read the source name, and the relay does not durably store that ciphertext. The iPhone notification service extension may decrypt the source name from Keychain-held pairing material only after the encrypted tenant, workspace, host, device, notification, source-version, and event scope all match; it then replaces only the banner title. If encryption, delivery-extension execution, decryption, or validation fails, the notification still shows HVAIA plus its fixed event phrase. mutable-content is present only to run that extension when an encrypted source name is attached; content-available and silent notification behavior remain forbidden. HVAIA does not send Apple readable chats, prompts, answers, schedules, automation instructions, Studio content, connector data, file data, error details, a plaintext source name, custom payload fields, or the exact destination route. Only live Chat, Automation, Scheduled, and Studio destinations can be resolved on iPhone; Settings and Desktop Update stay on Desktop. Hosted delivery uses the configured content-blind HVAIA WebSocket relay, while an explicitly enabled managed Direct APNs alpha sends the same closed envelope through an authenticated loopback authority. Neither mode exposes APNs credentials or raw stored tokens outside its Vault-owning authority, and one mode is never selected as a silent fallback for the other. Apple can process the device token, fixed event metadata, ciphertext, and normal network/delivery metadata under Apple’s service terms and privacy policy. This source-name presentation and encrypted Apple delivery flow requires renewed consent at Privacy Policy version 2026-09-privacy-v70.

To enforce that boundary, HVAIA deletes legacy durable chat-mirror envelopes during SQLite compatibility upgrade, hosted PostgreSQL migration, and repository startup. It also scrubs any legacy workspace-mirror row that lacks the current content-blind schema marker instead of treating it as a cache. Current relay mirror metadata contains only routing-safe ordering and status facts; it never restores legacy chat or workspace content.

HVAIA sends encrypted desktop chat mirror and live-update payloads for iPhone only after it has an active trusted iPhone public key for that paired device. In Tauri source and packaged desktop sessions, HVAIA constructs outbound envelopes through a native Rust boundary in memory before the existing content-blind broker call; the boundary returns only an opaque envelope and has no production private-key or inbound-decryption path. Its derived encryption key is explicitly cleared when the one encryption operation ends, and its ECDH secret and cipher are kept only within that operation. Inbound desktop decryption remains in Python next to the Vault-held private key. Neither direction persists or logs plaintext or key material, and the Rust outbound boundary does not persist ciphertext. Before the public relay accepts a chat mirror or live update, it rejects readable chat content placed beside the encrypted envelope and checks that the encrypted scope, chat, safe ordering version, purpose, and recipient identifiers match the outer routing metadata and the currently trusted iPhone key. The iPhone also requires hosted chat-detail versions inside encrypted content to match their authenticated envelope versions before changing chat state. Invalid, readable, mismatched, or outdated payloads are rejected before storage, delivery, or display. If that key or the configured hosted route is unavailable—including temporary token or broker-socket unavailability—HVAIA waits for pairing/key and hosted-route readiness instead of treating a local-only publication as delivered to your iPhone. Assistant speech for a Chat is generated by the live desktop after it validates the already committed assistant publication. The audio result is sent only in a bounded end-to-end encrypted response to the paired iPhone; the public relay does not receive or store raw audio, speech text, or a readable audio URL. The iPhone may write that audio to its protected local playback file and shows retry guidance if the request fails, disconnects, cannot be decrypted, is malformed, or does not finish within its bounded wait. This narrows in-memory key lifetime without adding a recipient, storage location, collection category, retention period, or telemetry.

For an iPhone selected-chat detail refresh, the desktop’s authenticated local loopback read loads only that chat’s profile-scoped capsule, draft, and queued prompts instead of reading unrelated chat capsules. The selected detail still crosses Anywhere Access only inside the same end-to-end encrypted desktop-to-iPhone response; this narrower local read adds no recipient, collection category, storage location, retention period, telemetry, or relay-readable content.

Run diagnostics shown beside a failed assistant turn are system status, not substituted assistant output. The iPhone receives the desktop-authored diagnosis unchanged, uses the reason code only to choose a user-safe system-card title, and does not show the raw code. This synchronization adds no new storage path, retention rule, telemetry, secret handling, or public-relay persistence.

During pairing and reconnect, HVAIA may store the iPhone device name, desktop host identity, and device public-key metadata needed for end-to-end encrypted iPhone sync so desktop Settings can show a recognizable trusted device and both devices can decrypt each other’s brokered messages. Desktop Settings may also check whether the trusted iPhone has a live authenticated workspace connection before showing it as connected. This is trust and presence metadata, not workspace content.

An authenticated iPhone transport is shown as connecting until the relay acknowledges the exact tenant, workspace, and desktop session binding. That acknowledgement and the resulting online/offline presence use only the existing content-free connection metadata. They do not add relay-readable chats, drafts, attachments, workspace details, or credentials.

When you send prompts, drafts, attachments, queued-prompt edits, queued-prompt deletions, steering requests, approval responses, user-input responses, chat controls, Automation controls, Scheduled controls, Studio controls, or assistant speech requests from iPhone through Anywhere Access, that content is encrypted on iPhone for your desktop before it crosses the public relay. An iPhone assistant-speech request identifies the already committed publication and does not supply assistant text. Queue prompt text, queue item identifiers, and active run identifiers stay inside that encrypted live request; the relay sees only the routing, version, idempotency, and user-safe status metadata needed to deliver it. Queue and prompt requests repeat their routing identity inside the encrypted content so the desktop can reject a swapped or mismatched envelope without revealing the content. Authoritative queue and prompt results return inside request-bound encrypted envelopes; an unencrypted timeout or relay error is treated only as uncertain delivery, and the iPhone safely retries or refreshes with the same identity. The public relay also rejects every generic plaintext prompt.queue.* method before queue-handler dispatch or queue-storage access; those methods remain available only on local/private gateways, while iPhone Anywhere Access uses the encrypted broker path. This includes Approve or Deny decisions for live desktop-owned chat requests: the approval request, decision, and any response remain end-to-end encrypted for the paired desktop and are unreadable to the public relay. HVAIA rejects public-relay broker requests that contain readable user content outside the encrypted device-to-device envelope before forwarding them to the desktop. The relay may route the request and keep non-content status metadata, but it is not allowed to store readable content or durable encrypted content queues. When the desktop generates assistant speech or Studio speech, a paired iPhone receives generated audio inside the approved encrypted desktop-bound control path; the public relay must not store or serve readable generated audio.

If the paired desktop encryption key is unavailable or iPhone encryption fails, hosted Automation and Scheduled changes are not sent through a readable fallback. HVAIA cancels the pending request, restores any optimistic local change, and asks you to reconnect or pair again before retrying.

When you disconnect an iPhone, HVAIA sends the device identity and short-lived authentication material needed to revoke trust; the relay stores only trust and routing metadata for that revocation. HVAIA may send a non-content trust-status event, and while the desktop Settings iPhone card shows a paired device, HVAIA may periodically check the same trust and live-presence metadata so the desktop can stop showing a disconnected phone as paired.

Automation, Scheduled, and Studio workspace data sent for iPhone views uses the same content-blind design. Automation, Scheduled, and Studio controls sent from iPhone, including run, pause, resume, clone, rename, pin, unpin, archive, delete, report, create, edit, draft update, generate speech, regenerate, and take-audio retrieval where supported, use the same encrypted desktop-bound path. Desktop-owned results for content-bearing Studio actions, such as created or edited projects and generated takes, return to the paired iPhone inside encrypted envelopes. Automation, Scheduled, and Studio pin and unpin changes from iPhone are desktop-bound sidebar preference updates when the paired desktop is online. The relay should receive only routing metadata and encrypted envelopes, not readable automation names, instructions, schedules, approvals, run history, traces, Automation/Scheduled mutation payloads or report feedback, Studio project titles, compose drafts, take input text, generated audio, Studio action payloads, Studio report feedback, or Studio action results.

HVAIA Live public publishing

HVAIA Live lets you publish an explicitly approved static website or client-side application at a public address such as https://your-name.hvaia.site. Preparing a candidate and publishing it are two separate approvals. Candidate preparation shows the exact build command, runs the build locally without network access, and creates one encrypted candidate without contacting the publisher. Before the final upload, the main HVAIA agent shows the selected subdomain, exact file count, content and archive byte sizes, manifest digest, and static-only/public limitations and asks for a separate approval. That final approval is bound to one immutable candidate receipt: HVAIA uploads those exact prepared bytes and does not rebuild or regenerate the archive after approval. If you approve, HVAIA sends the built site artifact and its manifest/checksums from your Desktop to the HVAIA-operated publisher on Hostinger. The published files are intentionally public to anyone who knows or discovers the address, can be copied or indexed like other public web content, and may be downloaded by visitors. Do not publish passwords, API keys, private records, or other content you do not want to make public. HVAIA Live does not support private/password-protected sites, server code, databases, or secret-bearing runtime configuration in this version.

The publisher stores the current public site files and bounded site/release metadata under an opaque owner identifier, including the subdomain, current release id and manifest digest, artifact byte/file totals, status, and lease timestamps. When a release is replaced, a visitor response that already leased the prior public file may finish reading those bytes; new requests cannot select that release, and the publisher deletes it when its final in-process response lease closes. Restart reconciliation removes unreferenced stale releases. It keeps hourly per-site request and payload-byte totals for up to 30 days and bounded operational action/outcome/reason records for up to 90 days. It does not durably store visitor IP addresses, requested paths or query strings, referrers, user agents, cookies, authorization values, or request/response bodies for public site access, and its reverse-proxy access logging is disabled. Hostinger and the internet/network providers that carry a visitor’s request can still process ordinary connection metadata under their own terms even though HVAIA does not retain those visitor-level access records. This in-flight-response protection changes no data category, recipient, retention purpose, or transmission path and does not require renewed consent beyond the current Privacy Policy version.

HVAIA’s certificate-renewal service keeps separate staging and production recovery records only in server-side HashiCorp Vault. Each version-1 record contains the ACME environment and directory, the operational account email, account private key and registration, a recovery phase and timestamps, and—only while required—one pending certificate/private-key pair and certificate digest. It contains no HVAIA user/profile identity or email, site content, visitor record, prompt, chat, or relay payload. The records let interrupted DNS cleanup and certificate promotion resume, while an ambiguous issuance blocks another request for 48 hours before one cleanup-gated retry; disposable filesystem work directories are wiped after every attempt. Dedicated admin HTTPS uses HTTP-01 with the same restricted operational recovery class: saved certificate keys and AppRole recovery credentials remain in server/operator Vaults, required runtime copies stay in protected, swap-free RAM, and bounded public challenge proofs are removed after issuance or cleanup. Certificate renewal does not read the approved-email directory or support reports. This is restricted operational security material and adds no user-data recipient or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

Live reuses the signed-in account email verification already completed for Profile and Anywhere Access; it does not request, send, or store a second email address or one-time code. Every authenticated HVAIA user whose relay enrollment carries that server-validated proof can use Live; Live does not apply a separate owner-only or approved-email rollout allowlist. The relay gives Live only the canonical normalized-email SHA-256 digest from the exact verified install/profile binding, never the raw account email or plaintext verification proof. On first use, Live atomically stores an opaque owner claim with activating state and an update timestamp; only that exact principal, digest, and derived-owner binding can resume activation, become active, receive a publisher token, or be revoked. Existing claims migrate to active. Missing verification provenance or a different binding fails before remote publisher mutation. Publisher tokens are short-lived and contain the opaque owner id, owner generation, scopes, issuer, audience, and expiry, but no email, email digest, or site content. Retired temporary Live challenge rows from an earlier version are deleted when the relay starts. If the account proof is missing or invalid, Live sends you to Profile settings rather than starting another mail flow. After deliberate identity removal, automatic requests cannot silently reactivate the owner; choosing Reconnect Live explicitly reuses the same verified account binding without another email. These claim states and exact-provenance checks add only bounded identity state/update metadata under the existing digest-only Live identity boundary; they introduce no new data category, recipient, retention purpose, or transmission path and do not require renewed consent beyond the current Privacy Policy version.

During preparation and upload, the exact approved site archive exists briefly as plaintext in an owner-only, HVAIA-managed tmp/publisher-archives directory on your Desktop. HVAIA normally deletes it immediately after preparation, successful upload, or failure; local-data reset removes the directory, and a later preparation removes matching crash remnants older than 24 hours. HVAIA does not scan or delete older anonymous operating-system temporary files. This narrows temporary storage and retention, adds no recipient or data category, and does not require renewed consent beyond the current Privacy Policy version.

Before remote publication, HVAIA keeps the exact approved artifact as an encrypted pending candidate under the active profile’s local live/recovery data. Its receipt contains no secret or absolute path and is bound to that profile and a digest of the current trusted staged workspace. An unpublished candidate expires after 60 minutes; a changed, missing, expired, cross-profile, or cross-workspace receipt is rejected before remote mutation. When the authenticated publisher receipt confirms the same archive and manifest, HVAIA atomically promotes it to the one current encrypted recovery copy. If the upload result or local finalization is ambiguous, at most one pending candidate for that site remains so a later reconcile can compare it with the publisher receipt or retry the same opaque candidate idempotently; a later approved attempt supersedes it. A different remote release is reported as a conflict and is never overwritten automatically. The encryption key remains only in the profile’s local Vault, and HVAIA keeps no local or cloud release history. Deleting the site removes its current public files, release metadata, and all matching current or pending local recovery records before reporting success. The released address can later be claimed by another user. Removing the publishing identity immediately invalidates existing publisher tokens, suspends every owned site so it stops serving, and retries any incomplete file deletion before allowing that identity to reconnect. Before that remote mutation, Desktop writes one private checkpoint in the same live/recovery directory containing only revoking or remote_revoked state, the approved number of affected sites, a one-way active-profile digest, schema version, and timestamps. It contains no email, subdomain, URL, token, receipt, path, credential, or site content and is not sent to the relay, publisher, model, logs, support data, telemetry, or iPhone. If the relay claim has already been removed when local encrypted-data cleanup is interrupted, the checkpoint lets Desktop show an explicit retry for only that already-approved cleanup; it is deleted after the local recovery records and Vault key are gone. Profile removal and authenticated full local-data reset revoke the Live identity and take public sites offline before profile-owned recovery data or credentials are discarded; if remote cleanup or the local checkpoint cleanup cannot be confirmed, deletion is blocked with retry guidance. A standalone reset that lacks unlocked profile authority also fails closed rather than orphaning public content. Deleting the chat that created a still-published site does not silently unpublish it. This content-free recovery checkpoint uses the existing local Live data category, root, deletion boundary, and recipients and does not require renewed consent beyond Privacy Policy version 2026-08-privacy-v67.

Live also keeps one owner-only local live/site_preferences.json file for the active profile so custom site names and pinned order stay synchronized between Desktop and a paired iPhone. That file contains only schema and presentation versions, each affected subdomain, its optional custom title and pin state, and up to 128 opaque idempotency receipts with request digests and bounded presentation results. It contains no site files, URL, release identifier, email, credential, or publisher token. HVAIA writes it atomically. Deleting a site removes that site’s preference and receipts after the publisher confirms deletion; removing the Live identity, deleting the profile, or resetting local data removes the entire file. These preferences are excluded from model context, logs, support data, telemetry, and public-relay-readable storage. The paired iPhone receives them only inside the existing end-to-end encrypted Live response and may keep them only in its existing pair-scoped file-protected workspace cache. This is profile-owned Live presentation data under the existing local Live root, recipient, retention, and deletion boundary and does not require renewed consent beyond Privacy Policy version 2026-08-privacy-v67.

Live sites use 14-day renewable leases. HVAIA shows warnings as expiry approaches. If a lease expires, public serving is suspended and the publisher may retain the suspended files for up to 30 days for recovery before deleting them; explicit site deletion or identity revocation does not wait for that retention period. A paired iPhone receives Live rows through the dedicated ios.live.list read and rename, pin, and deletion results through ios.workspace.intent.live_action, both over the same end-to-end encrypted live Desktop connection, and may retain its pair-scoped file-protected cache for read-only offline viewing. The public relay cannot read or durably store Live subdomains or any other Live presentation or content metadata. This includes custom titles, pin state, candidate identifiers, receipts, public URLs, release metadata, artifact data, and Live or revocation actions. The iPhone cannot publish or change a Live site while Desktop is offline, and its outer relay request uses an opaque retry identity rather than the subdomain. These public sharing, external hosting, email-delivery, publisher retention, local encrypted recovery, and deletion disclosures require renewed consent at Privacy Policy version 2026-08-privacy-v66. Naming Hostinger Email as the already-disclosed transactional delivery provider, binding the code with HMAC, narrowing reset/revocation ordering, and keeping presentation preferences under the existing local Live boundary clarify and strengthen that boundary and do not require renewed consent beyond the current Privacy Policy version.

Support reports, logs, and diagnostics

The HVAIA owner can manage relay eligibility and received support reports through an owner-only dashboard. The owner manually supplies approved addresses; a separate administration database on the VPS keeps the address, its email digest and administrative metadata so the owner can search it. This directory is server-readable personal data, not end-to-end encrypted storage. Ordinary relay services cannot read the directory, and enrollment records continue to contain only email digests. A saved address remains until the owner selects Forget saved email. Forgetting it removes directory metadata without revoking relay approval or already-issued sessions. Deleting a desktop profile does not remove a global approval or the saved administration directory entry; the deletion receipt discloses this retention. This expanded storage requires fresh acceptance at Privacy Policy version 2026-10-privacy-v93 in the next normal desktop release; existing relay access remains available during the transition.

The dashboard reads the existing bounded production and development support-report stores. It keeps a separate owner note and triage status tied to the exact version of each report; those records are removed after the report expires or disappears. Reports are hidden when their configured retention expires and hourly maintenance removes expired files, including after restart. A powered-off server cannot delete files until it starts again. Report text and claimed sender identity are unverified submissions. The dashboard does not infer an email address or associate reports with saved users. The owner can review and copy a report for investigation; default copies omit conversation snapshots, raw events, log tails and tool arguments or results. Including available diagnostic sections requires a separate choice and preview for each copy. Sending copied material to a coding agent or another service is an owner-controlled disclosure subject to that recipient’s own terms and retention. Dashboard access logs are disabled; operational diagnostics omit addresses, report content, credentials and request bodies. HVAIA stores support diagnostic records locally under support-reports/tickets in the active HVAIA profile, alongside a local ticket ledger. These support-sensitive records are resettable with that profile and are distinct from tracked engineering tickets in a source checkout. To avoid duplicate support diagnostics during a temporary outage, HVAIA may coalesce repeated automatic backend HTTP incidents with the same technical fingerprint for a short bounded interval. This does not coalesce a report you manually submit, and it does not add a new support recipient or relay-visible content path.

If you submit a support report from desktop or from the iPhone chat, Automation, Scheduled, or Studio report sheet, HVAIA can include the issue text you provide, selected runtime diagnostics, reason codes, owner-scoped raw event excerpts, tool activity, and a limited conversation snapshot when available. Profile-scoped reports omit machine-wide process-log tails; unconfigured legacy diagnostics may still include redacted logs. HVAIA ignores client-supplied assistant text in a support snapshot and includes assistant content only from the backend’s committed publication. When that authoritative publication is unavailable, the report is marked partial and omits assistant content. A Desktop Studio report’s Studio-specific structured fields add only its Studio origin and project identifier; it intentionally omits the project title, script draft, take text, generated audio, and any Chat conversation snapshot. General capture metadata, such as when and where the report was captured, is also included. Selected redacted diagnostics can still contain operational or user content needed to understand the failure, so review your issue text and avoid sensitive information unless it is necessary. iPhone report feedback is encrypted for your desktop before relay transit, then the desktop submits it through the same support-report pipeline. HVAIA redacts known secret patterns before saving or sending support reports.

Automatically captured frontend, backend HTTP, and backend stream incidents keep their bounded diagnosis-grade detail only in the local support ticket. Before an automatic report is sent or queued for the support relay, HVAIA replaces user feedback, raw events, stack traces, conversation snapshots, tool arguments and results, log tails, paths, and code-search anchors with a content-free projection. That projection is limited to a fixed incident category; syntax-constrained reason, event, runtime, run-status, tool-name/status/error, and warning codes; and opaque identifiers. Previously queued automatic reports are projected again before retry, and relay intake applies the same boundary before storage. Manually submitted reports retain the user-reviewed redacted diagnostic behavior described above. This narrows relay exposure and adds no new data category, recipient, storage root, retention period, deletion boundary, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v57.

Support reports can be saved locally for retry and, when support delivery is configured, sent to a HVAIA support relay. Relay-side support report storage is capped and time-limited. Local logs are used for troubleshooting and can include operational events, errors, model/runtime diagnostics, committed-publication identifiers and digests, and run-cancellation status for known and duplicate run ids. Model output content—including an answer whose deterministic publication finalization later fails—is retained through the encrypted chat and publication paths described above, not written as assistant-output log text.

When content-free latency observability is enabled, local operational logs may also include opaque run and chat identifiers; finite durations for request setup, Memory context, Memory search, document lookup, runtime construction, connector discovery, pre-provider work, provider first event, first model token, total time to first token, connection, TLS, response headers, and any measurement gap; plus bounded status and count fields. Debug logs may identify a connector only with a session-scoped digest and may include its bounded transport, status, and duration. These timing records never include prompts, messages, Memory or document text, filenames, paths, connector names, endpoints, commands, tool schemas, headers, credentials, request bodies, or response bodies. They remain subject to the existing local operational-log storage, retention, support-report, profile-removal, and device-reset rules and are not added to model context or readable public-relay data. This diagnostic clarification adds no recipient, storage root, retention class, or renewed-consent requirement.

Packaged HVAIA and source/development HVAIA may use separate HVAIA-hosted relay addresses on the same managed server so a released app can remain compatible while development continues. The two relay environments keep separate routing/authentication metadata, enrollment-token digests, bounded redacted support-report folders, databases, and logs; credentials issued by one environment are not accepted by the other. The packaged relay keeps the existing support-report retention limit, while the development relay prunes submitted reports after at most 14 days and applies a smaller storage cap. This split does not make chats, prompts, drafts, tool output, attachments, Automations, Scheduled tasks, Studio data, or paired-device payloads readable to either relay: those payloads remain inside the existing end-to-end encrypted live channel and are not durably queued as ciphertext. The development Google sign-in path may temporarily use the same stable, Vault-backed OAuth broker, but Google tokens remain desktop-owned under the existing connector rules. This clarification adds no new data type or operator, shortens retention for development reports, and does not require renewed consent beyond Privacy Policy version 2026-07-privacy-v49.

Debug iPhone builds may write a local connection-diagnostics file on the iPhone with redacted transport status, request method names, response result-key names, host-health state, content-free chat identifiers, message counts, and state versions so developers can troubleshoot pairing and relay stability. These diagnostics must not include access tokens, refresh tokens, prompts, messages, workspace content, attachments, or decrypted relay payloads.

Updates, downloads, and cloud catalogs

HVAIA can contact HVAIA-hosted update, download, model, skills, apps, and manifest services. Those services and their hosting providers can receive normal request metadata such as IP address, user agent, requested URL, timestamps, and download status.

After you accept the current policy and while Desktop is running, HVAIA checks the signed Cloud App and Skill catalogs at startup and then no more than once every six hours so enabled Notifications can report an update or quarantined installed version without requiring Settings to be open. The check sends no prompt, chat, connector credential, installed-file content, tool result, or notification text; it uses the catalog request and normal network metadata described above, and the resulting notification projection remains content-free under the notification rules in this policy. This automatic catalog-check timing is included in renewed consent at Privacy Policy version 2026-08-privacy-v66.

When you install a cloud skill, HVAIA copies one non-secret owner identifier from the verified signed catalog into that skill’s existing local installation receipt. The identifier is either Main or one bundled named specialist and is used only on your device to limit which model can discover or read the installed skill. It is not shown to Main for delegation, does not automatically activate the skill, and adds no tool permission. A specialist receives only compact skill metadata after Main has independently delegated to it and can choose whether to read the full instructions through the existing model request path. Deleting the installed skill revokes model access immediately because receipts whose installed path no longer exists are ignored; the non-secret local receipt record is overwritten by a later verified install/update or removed with the existing identity deletion and reset flows. This change creates no new storage root, external recipient, user-content transmission, telemetry, retention period, or deletion boundary and therefore does not require renewed consent beyond Privacy Policy version 2026-08-privacy-v57.

Cloud Apps are downloaded into local per-job scratch, checked against signed catalog metadata, and may be started locally for an installation smoke test before HVAIA promotes the installed version. HVAIA keeps a resettable local cache containing only the signed manifest body, detached signature, manifest URL, and fetch time; it re-verifies the signature whenever it reads that cache, and a stale entry may be displayed but cannot authorize installation. Scratch, package-adjacent staging, and receipts contain app runtime files and non-secret package/version/checksum metadata. Non-secret install state may additionally retain opaque job and app identifiers, phase, byte counts, cancellation availability, timestamps, and a bounded user-safe reason or diagnosis so progress, interruption, cancellation, and retry survive interface refreshes or restart. Connector credentials remain in local Vault and are not added to the archive, cache, progress, or receipt. During promotion, a local non-secret recovery marker may temporarily store only the app id, candidate version, archive checksum, schema version, and whether a prior payload existed so HVAIA can restore the working version or finish a committed update after interruption. A failed smoke or receipt commit removes the candidate and preserves the prior installed app. If a signed catalog later revokes the installed version, HVAIA keeps the local package, receipt, and connector configuration for evidence and recovery but quarantines that runtime until you install a non-revoked update. Local operational logs for this flow contain only app/job identity, phase, reason, duration, and byte counts—not paths, URLs, package or manifest content, credentials, chats, or tool results. These reliability and security changes add no new storage root, cloud recipient, retention class, public-relay-readable content, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v64.

HVAIA stores locally derived MCP tool-catalog metadata, including tool names, descriptions, input schemas, and normalized annotations, inside the active local profile. Specialist-derived catalog files use the same profile boundary. Removing or resetting that profile removes only its derived MCP state; explicitly unbound command-line use may keep a separate identity-level derived cache that full local-data reset removes. This narrows local isolation without adding collection, sharing, transmission, a recipient, a retention class, or renewed-consent requirements.

Retention, deletion, and reset

When an action needs a blank chat, HVAIA reuses an existing untouched New chat in the same project or standalone destination when it has no messages, unsent text, attachments, pending project setup, queued prompts, or active work. Otherwise, it creates a blank chat through the existing storage flow. This applies to New Chat, startup, blank-chat requests from connected devices or tools, and the blank view after archiving or deleting the selected chat or project. Reuse preserves the chat’s identity and existing settings; it does not copy deleted content into it or introduce another storage location or recipient. Deleted chats follow the same cleanup rules described below.

A newly opened empty chat may remain only in the current app session until you first save a draft, send a prompt, open its Files or Browser panel, or start Voice. Opening one of those per-chat surfaces can save the otherwise empty chat and its current draft sooner in the same encrypted local chat storage so its Browser or other state has an owned chat to use. It follows the same deletion and reset rules as other chats. This clarification adds no new data category, storage location, recipient, retention period, or consent version beyond the current v87 policy.

Ordinary reset also preserves Vault and content-free saved-login recovery records when a configured directory uses linked paths, including linked targets inside the reset root or equivalent names with different letter case. HVAIA checks their actual locations only to protect them from deletion; it does not traverse links to delete content. If it cannot establish that relationship, the affected entry remains intact and reset reports the failure. This enforces the existing retention promise without adding stored data, sharing, or a consent requirement beyond the current v75 policy. Most durable user data is stored on your device until you delete it, reset local data, disconnect an account, remove a key, or remove related records through the app. Reset flows are intended to remove non-secret local data while preserving Vault and operating-system secret-store material unless the specific reset or disconnect action says otherwise.

Local-data reset chooses targets from lexical absolute paths without resolving links. It checks the literal HVAIA data root before provider recovery, state reads, or child enumeration; if that root is a symlink, dangling symlink, or supported Windows junction, a real reset stops with local_data_reset_root_link_unsafe, while a dry run reports one failed root action. Neither the link nor its destination is modified. For a normal root, HVAIA preserves the literal Vault entry even when it is link-like, never follows child links or junctions, continues independent siblings after a safe child failure, and leaves root cleanup incomplete until every failed child can be retried. The same rules protect resettable locations outside the root. This strengthens the existing reset and secret-preservation guarantees and adds no data category, recipient, storage root, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

The standalone hvaia data reset --confirm command does not remove profiles. If it finds any entry under the active identity’s profile root, it stops before deleting anything and directs you to remove each profile through HVAIA Settings. Settings owns the authenticated cleanup that stops and confirms active Computer Use recordings and destroys the profile’s Vault-backed metadata-history keys and index records before removing encrypted history. An unreadable, linked, replaced, non-directory, or differently owned profile root also stops the standalone reset without deleting anything. --dry-run only inspects and reports this blocker; it does not create or acquire ownership locks.

From Settings > Profile, you can remove only the currently active authenticated profile after re-entering its current password. There is no deletion-confirmation email or deletion code. Before the backend may delete anything, the Desktop pauses that exact profile’s browser-like local storage writers, closes other HVAIA profile windows, removes that profile’s local interface state, and obtains a backend acknowledgement; the backend then fences new work and cancels or drains profile-owned runs, streams, connectors, and other background writers. HVAIA uses fail-closed cleanup for that exact profile’s HVAIA-owned data, including local credentials and profile secrets; encrypted chats, runs, Memory, settings, Automations, Scheduled records, Computer Use history and recordings; and protected paired-device caches. A lost final HTTP response does not cause the interface to guess: it keeps the profile paused and checks a content-free exact-deletion status retained in backend process memory for no more than five minutes. It resumes the profile only after the backend confirms that deletion failed after every exclusive writer fence was released; confirmed deletion reloads into signed-out/setup state.

To survive a reload while that outcome is unresolved, the current main-app tab may keep one content-free deletion-recovery checkpoint in session storage. It contains only a fixed schema version and phase, the exact profile/account/tenant/workspace identifiers, and an opaque deletion-preparation identifier; it never contains the password, email address, relay credential, verification proof, receipt capability, chat, project, or profile content. The checkpoint is used only to keep profile writers paused and reconcile that exact deletion before the app mounts again. It is removed after a safely confirmed terminal outcome or when the tab closes; while the outcome remains unknown it has no independent time limit, because expiring it could reopen a profile while deletion is still running. It is separate from the shorter one-time receipt notice described below.

After a full app or backend restart has removed that process/session checkpoint, the existing content-free durable deletion marker lets the locked profile chooser offer Resume profile deletion only when an intact marker matches a profile in a successfully read local authentication snapshot. Your entered password stays in memory for that action, must unlock the exact selected profile, and is used again only to obtain fresh deletion preflight authority before the same fenced cleanup sequence runs. An unavailable, corrupt, or intermittent authentication read performs no purge and clears no cleanup or deletion marker; HVAIA keeps the profile blocked until authority can be read reliably. This restart recovery adds no password persistence, browser recovery store, external recipient, or user-content purpose, so Privacy Policy version 2026-09-privacy-v85 remains current.

Before local credentials are removed, HVAIA reconciles and revokes any active desktop public-relay enrollment and its install/profile-bound verified-email proof, using the latest exact local authority under the final deletion fence. A relay method that entered protected dispatch before revocation commits may finish, but after commit the revoked credential cannot authenticate a new connection or enter another protected method, including over an already-connected session. It also revokes the profile’s Live publishing identity and takes its published Live sites offline before removing the authentication-profile record. If an existing or possibly existing remote credential’s revocation or other critical cleanup cannot be confirmed, the profile record remains in place, the removal stays visibly incomplete, and you can retry it; HVAIA does not report full deletion. Content-free local integrity-protected authority and revocation records may keep deletion fail-closed across restart without storing the raw email, bearer, verification proof, password, receipt capability, or profile content. If an old revocation record has expired while remote authority may still exist, HVAIA may require you to start and complete the ordinary Profile email-verification flow before retrying; it does not automatically send that message and the verification is recovery authority, not deletion approval. An unverified profile or a profile proven never enrolled for online access can still be deleted without an email receipt. Profile removal does not delete user-selected source or project folders, files in those folders, explicit exports or backups stored outside the HVAIA profile, or data held by third parties. Local storage media, external backup systems, and third-party services may retain copies under their own behavior.

After HVAIA-owned profile deletion succeeds, HVAIA may make exactly one best-effort attempt to send a deletion receipt only when the profile email was already verified and the current Privacy Policy had been accepted. The receipt is evidence after deletion, never an approval step. The raw email address exists only in request memory while it travels from the local backend to the HVAIA public relay and then to the relay’s configured TLS SMTP provider solely to deliver that receipt. It is not sent to a model or paired device, written to a retry queue, or persisted by the relay, and the desktop package contains no SMTP credential. The relay may retain only the normalized email digest, finite delivery status and timestamps, plus a one-use receipt authorization and its status for no more than one hour. A delivery failure, unavailable mail service, or uncertain SMTP outcome does not restore the deleted profile or make deletion fail, and HVAIA does not automatically resend after deletion. The next local interface may keep only the receipt outcome and an expiry in the current tab’s session storage, shows the notice at most once, and removes it on display, tab close, or after no more than ten minutes.

The receipt confirms only deletion of the local HVAIA profile and HVAIA-owned data for this device. It does not claim deletion of user-selected source or project folders, exported files or backups, data kept by third parties, the global approved-email allowlist digest, or the bounded security records described here. For a credential that was still active when revoked, HVAIA may retain its digest only through that credential’s original expiry; an already-expired legacy credential digest is removed within one hour after revocation. A verified-proof digest may remain for no more than 90 days after revocation. The normalized-email digest, receipt authorization, receipt status, and delivery timestamps are removed within one hour. A composite content-free tombstone remains only until the latest applicable one of those deadlines. Existing digest-only email-verification challenge records, including pending or uncertain delivery evidence, remain only for their existing rolling one-hour abuse-prevention window; a challenge bound to the deleted proof is revoked at deletion commit and cannot later mint a proof. The relay prunes these records synchronously before serving after startup and periodically while running. Its exact enrollment-store path and storage volume are excluded from VPS, filesystem, and provider snapshot/backup jobs; an explicitly authorized migration or restore must prune expired records before service begins. These records contain no raw email, plaintext verification proof, bearer token, receipt capability, chat, project, or profile content.

A small set of content-free native credential-safety journals intentionally survives profile removal and ordinary reset when it is still needed to prevent revoked or insufficiently verified saved-login state from becoming eligible again. Those journals contain only opaque owner, profile, or account digests; opaque transaction or generation identifiers; and bounded lifecycle status. They contain no username, destination, password, token, chat, project, or profile content. Surfacing this existing deletion boundary in Settings adds no new collection, storage root, recipient, retention purpose, or data transmission, so Privacy Policy version 2026-09-privacy-v85 remains current.

A confirmed profile-free standalone reset first takes nonblocking, content-free ownership leases for the active source or packaged desktop/runtime and for the exact lifecycle database path. It validates that the persistent lease files and their directories are local, owner-controlled regular paths with stable identities and no symbolic-link, junction, or hard-link ambiguity. An active owner or any unsafe or unverifiable lease stops the reset before deletion. HVAIA holds every lease through provider/profile checks, all deletion, and final registry reconciliation, and it never unlinks those persistent lease files. This fences active Computer Use writers and allows profile-free reset to remove stale, interrupted, or completed recording manifests outside profile roots without racing the native runtime. These reset-safety changes add no data category, recipient, storage root, retention period, or renewed-consent requirement, so Privacy Policy version 2026-09-privacy-v85 remains current.

Deleting chats or scoped data can remove related chat-scoped documents, memory artifacts, and local state. Third-party providers and connected services keep data according to their own policies.

Removing a chat project from HVAIA requires an explicit confirmation in the app. Confirming removes that project’s encrypted HVAIA-owned binding, member chats, drafts, queued prompts, Changes history, and any explicit isolated copies under the same deletion rules described below, while leaving the original selected folder and its contents untouched. This changed binding and deletion boundary is included in renewed consent at Privacy Policy version 2026-09-privacy-v68.

Deleting a chat first checks, without changing data, that HVAIA can delete and verify the chat’s exact local Memory index entries. This cleanup check uses the existing local Qdrant store directly and does not require the embedding provider, so an embedding outage alone does not block deletion. A recognized transient local-store open/read failure receives at most one bounded reopen/reprobe against the same initialized profile store; missing, corrupt, quarantined, closed, or externally owned storage is preserved and the warning names the safe next step. If that check fails, HVAIA leaves the deletion marker and all chat content untouched and asks you to retry. After the check passes, HVAIA records a content-free hashed deletion marker as the first change, then removes its local lifecycle, publication, delivery, raw-event, and evidence records and checkpoints the transactional run store so deleted assistant text is not retained in its write-ahead log. New deletion markers and profile-driven cleanup bind the complete profile, account, tenant, and workspace owner tuple. Older ownerless markers continue only as global blocks against recreating deleted content; HVAIA never uses them to purge a possibly different profile. Missing, corrupt, or mismatched ownership stops before any cross-profile change, keeps cleanup retryable, and reports a safe owner-ambiguity reason. Before reporting deletion complete, HVAIA also removes publication-linked local Memory/orchestration messages, Scheduled summaries and traces, Automation materializations, and Telegram message mappings or pending send intents. When the chat has a local Memory session trace, HVAIA removes that exact trace and its matching local keyword, vector, and vector-manifest entries without reading or reprocessing other chats. Materialization cleanup for chat deletion and profile reset travels only over the authenticated loopback connection between the local backend and local Gateway; it does not send chat content or cleanup identifiers to the public relay. A separate best-effort hosted mirror cleanup may send only the existing content-free tenant, workspace, chat, and idempotency identifiers. If one of those local cleanup destinations is unavailable, deletion remains visibly incomplete and retryable instead of reporting full success. Automatic local support capture retains only the finite failure reason, safe diagnosis, retry flag, outcome certainty, and cleanup phase; it never stores response bodies, raw exceptions, secrets, paths, or chat text. A delivery already in progress must ask the local backend again immediately before it writes the accepted answer into another local feature or an encrypted device envelope; the deletion marker rejects that write, and each destination keeps its own deletion guard so delayed work cannot recreate the chat. Local data reset removes the active identity’s run lifecycle database and related temporary sidecars while preserving secret stores as described above. Its exact path-digested lifetime writer lease remains in identity-scoped operating-system app state so deleting the resettable runs directory can never create a second writer namespace. The established chat-index deletion guarantee still requires no renewed consent beyond Privacy Policy version 2026-08-privacy-v60. The complete-owner binding strengthens profile isolation without adding a data category, storage root, recipient, retention class, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

Removing an authenticated profile also stages deletion of Scheduled definitions only when their complete profile, account, tenant, and workspace ownership matches. HVAIA first asks the local backend to cancel each captured active Scheduled execution, then removes the definition’s instruction snapshots, run history and traces, and standalone occurrence sessions through restart-retryable local cleanup. Missing owned files are treated as already removed, but an unconfirmed cancellation, file error, or legacy row whose owner cannot be established keeps profile removal visibly incomplete instead of deleting another profile’s data. Independently owned target chats, Goals, projects, source folders, and visible delegated chats are not deleted with the Scheduled definition. This narrows and clarifies local Scheduled deletion behavior without adding a data category, recipient, storage root, relay-readable field, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-08-privacy-v63.

Profile cleanup may keep a content-free local retry marker containing only its schema version, profile identifier, and bounded failed-root labels. The marker is an aid, not deletion authority: if writing or clearing only that marker fails, HVAIA still completes successful Live revocation, native activation cleanup, profile-root deletion, and final authentication-profile removal, and emits no user content in its warning. A substantive Live/native failure still blocks before roots are deleted; a root/runtime failure remains pending and keeps the authentication profile for retry. A stale marker is harmless and idempotent after substantive cleanup succeeds. This reliability clarification changes no data category, recipient, retention period, or renewed-consent requirement beyond Privacy Policy version 2026-09-privacy-v71.

Native desktop Rust also reserves each encrypted iPhone mirror, delta, and workspace update in memory and advances its local publication version only after the relay confirms the exact update. A pairing-key change invalidates older confirmations. This guard retains no readable content, keys, or ciphertext.

For iPhone Shared Files, HVAIA rechecks backup exclusion and current file protection before it maps or decrypts any offline cache record. Physical iPhones require exact complete protection; Simulator uses a same-environment capability probe only when that protection attribute is unavailable. A changed, unreadable, or backup-eligible record stays closed. A visible iPhone Main Chat question can receive a Desktop file reader only through a fresh one-use visibility proof bound to that encrypted prompt, client message, chat, active tab, and frozen snapshot. HVAIA keeps that proof only in process memory. If the iPhone viewer hides, backgrounds, or hides and reopens before a queued or retried prompt is sent, the frozen snapshot may remain with that prompt but no new file-reader access is created. The public relay cannot read or store the proof. Side Chat never receives that Main Chat one-use visibility proof; when Share with HVAIA is enabled, it may instead use only the bounded, owner-scoped, revision-checked viewer access disclosed above. This distinction is included in Privacy Policy version 2026-08-privacy-v52.

A recovery record may include one bounded user-safe diagnosis derived by HVAIA; it never includes an external server’s raw error text.

Your choices

You can choose local or hosted providers where HVAIA offers that choice. During provider onboarding you can connect an eligible ChatGPT subscription, choose among only the API-key plan and region combinations HVAIA supports, or skip every provider. You can change provider setup or add or replace keys later in Settings, disconnect connected accounts, submit or decline support reports, and reset local HVAIA data from supported reset flows.

You must accept the current Privacy Policy version to continue using a profile after a policy update that requires renewed consent.