AI Assistant and Diagnostics

Device owners can open Model call metrics from Usage to inspect call errors, tool parameter checks and Token usage. Statistics may be incomplete in exceptional situations and are for reference. The page does not store conversation content or recalculate earlier calls.

Get started

1. Sign in, open an online device you own and turn on AI Assistant enabled for that device.
2. Open AI Assistant and create or restore a conversation.
3. Select the context it may read and enter your request.
4. Review the target and scope when permission is requested, then check the actual result.

See Long-term Memory for personalization, memory and history search. This page covers chat, device actions and diagnostics; see MCP for the read-only MCP tools.

Sending messages and inserting newlines

In the Web and desktop AI Assistant, Enter sends a message and Shift+Enter inserts a new line by default. Open Send shortcut below the input to choose Shift+Enter or Ctrl/⌘+Enter to send instead; unmodified Enter then inserts a new line. This preference is saved in the current browser and shared by main conversations, child adjustments and the terminal AI Assistant. It is not an account setting synchronized across devices. Confirming an IME composition does not send a message, and shortcuts respect the same availability conditions as the send button.

On macOS, the hints and menu show ↩, ⇧↩ and ⌘↩. Windows and Linux show Enter, Shift+Enter and Ctrl+Enter. Labels follow the system running your browser or desktop client, independently of the remote device.

Subagents

Completed read-only calls no longer count as running background dependencies. A failed read also ends that invocation, and the child must report its actual result. The first child read uses its own narrowed original context; no additional approval is needed to initialize it. Capabilities that require approval still follow their existing rules. Historical waits recover through normal finite continuation without redispatching the original call.

Model controls and schedule cancellation take the target short ID and business arguments. The server binds the versions actually observed in that request; an adjustment requires another query. Permission item identities and generic scopes, preview adapters and artifact content proofs remain server metadata. The approval model returns its verdict, reason and evidence references without echoing internal candidate identity. File operations can receive exact approval from the owner or valid delegated approval AI; owner-only requirements such as an interactive terminal carrier still apply.

Main and child tab titles pulse while approval remains pending. Reading a tab or marking it read does not clear approval attention; resolving approval does. Reduced-motion settings use a static highlight. Child attachments, context, working directories, permission history, background tasks and task details use the main conversation’s menu and panel presentation. Chat, images and pending consent actions stay in the transcript. Switching tabs closes the prior panels without retargeting consent. The context meter separately shows the bytes and shares of total budget reserved for system instructions, tool definitions and other request content. It then breaks conversation usage into conversation/events, tool calls/results, protocol replay (including reasoning), and summaries/projections. Reserved space is already deducted from the conversation budget, and display copies of reasoning are not counted twice. Cumulative tokens sum multiple calls rather than measuring current occupancy.

Main and child conversations retain separate input drafts across tab switches. A failed child adjustment keeps its draft; the server accepting the adjustment clears it. Opening a new main conversation clears prior child drafts.

When a child awaits approval, Web, iOS and Android show a task icon, the pending count and a link to that child's approval above the input field, when switching between main and child conversations. The notice clears when no child awaits approval. Each main conversation defaults to two unfinished children; tasks awaiting approval or background work count toward that limit. The server settings can change this limit.

The Subagent limits settings page controls unfinished tasks per main conversation (default 2, range 1-32). A group belongs to one input, goal or scheduled occurrence. The device owner edits these central settings under Settings / Subagent limits. Saving applies to the next creation attempt, including in existing groups. Lowering limits keeps existing tasks running and available for viewing, approval and stopping. Web, iOS and Android share this server policy. Counts do not increase model concurrency quotas, token budgets, call budgets or permissions.

Completed child results remain visible in the attention list outside the current conversation. Child approval entries open the parent conversation; viewing the child conversation clears UI attention independently of model delivery.

The main assistant can delegate finite tasks with explicit acceptance criteria and independent context, permission requests and results. Children reuse normal execution, content checks, permissions and compaction, without inheriting parent grants or directory approval. They cannot spawn more children, set goals, schedule continuations or create independent scheduled tasks.

When a child finishes, its status remains available in the subtask list and accompanies the main Assistant’s next model call. The main Assistant can finish its current work before reading the child report. After an explicit wait, it resumes the original request with the same permissions, budget and task identity. Ordinary completion notifications do not start a separate turn while approval is pending or after the main task has ended or stopped.

The main assistant and children share one conversation view with bottom tabs showing task names, states and unread indicators. Approval links select the relevant child tab. Switching keeps tasks running and preserves the main draft. Child conversations show messages, reasoning, tool calls and screenshots directly; the bottom input explicitly adjusts or stops the selected task. New main-chat messages leave existing tasks running. Stop requires confirmation when children remain unfinished, selecting Also stop subagents by default. Dismissal submits nothing. Main-only stop leaves existing finite tasks running and their completion cannot restart stopped main planning. A source-goal pause also pauses its own children while retaining recorded decisions and native receipts; resume rechecks authority, budget and the original deadline.

Screenshots, stored tool-output attachments and selected context in child conversations belong to the original child session. Web conversations show screenshot thumbnails by default; select one to view the full image. Earlier screenshots without a loaded message remain available on demand. Browse, search or delete stored attachments through their own paged viewer. Switching children closes the prior material viewers. New main input preserves the original child's records, approval selector and command generation.

When a child’s background command finishes, the system retains its original receipt and automatically resumes result interpretation and final reporting within the original authority and expiry limits. The receipt alone does not complete the child task. Waiting, recovery and duplicate notifications retain the original command identity and never execute it again.

Promoting an ordinary request to a goal or opening a new goal does not adopt existing ordinary-source children or grant them the new goal's authority or budget. New goal input retains its original children. Explicit pause affects only that goal's children; resume retains the original budget and deadline.

A scheduled occurrence uses the published task text and keeps its task and run identity. Automatic triggering does not count as a new owner approval; each operation still follows the current published contract and permission checks.

The scheduled parent, its children, context compression, report repair and content safety checks share the occurrence's finite quota. A child creates no independent schedule or extra occurrence charge. While waiting for children, the occurrence displays Waiting for subagents and releases the parent's planning lease. Children retain their original task, authorization, start time and deadline; a renewed claim resets no budget. Unsent model calls release their allocation. Sent calls with unknown usage retain it until authentic usage settles once. Cancelling the occurrence closes its children's execution source and requests cancellation of the original matching background commands. Historical results and authentic device receipts remain available.

If the scheduled parent answers while a child is still running, the original occurrence remains waiting. Child result notifications are claimed by that same occurrence and allow only status queries, report reads or waiting for existing children. They cannot initiate device operations or create or adjust children; another dependency wait retains this restriction. Temporary model unavailability preserves the same notification for bounded retry without resetting usage or the original deadline. Only a genuine model response marks notification delivery, independently of reading the full report and interpreting its result.

Stopping only the main assistant leaves sub-assistants on their original finite task until completion or the original deadline. Child results do not restart the stopped main assistant. After cancellation or expiry, an original command that is still running keeps the occurrence active while its real result is reconciled. An explicitly unknown execution outcome is recorded as outcome unknown and pauses later automatic runs. Late receipts update original execution facts without retrying commands or replacing the original outcome.

Independent AI reviews for a child also consume its original task budget. Pausing its source goal, stopping or adjusting the task, or disabling AI approval in the original conversation while a call is queued prevents an unsent review from starting. Actual receipts from already-sent calls remain recorded and cannot resume a task. Unsent calls release reservations; sent calls with unknown usage keep their allocation. When complete provider usage arrives later, accounting replaces that review's held upper bound exactly once without adding another review, changing its decision or resuming work. Until then, minimal accounting links remain available independently of conversation-content retention.

Main-context compaction retains durable task references and unconsumed result notifications. Child contexts can compact too. Final state is based on a deliverable report and actual dependencies/receipts, not stream closure or Idle. Cancellation expresses intent, not proof of native rollback. A replaced original worker or missing old execution record cannot redirect cancellation to a new worker or cause command replay.

In portable mode, once the built-in desktop session is ready, Add directory works without selecting a separate desktop session. Service mode keeps directory browsing bound to the selected desktop session.

The extension offers Allow current site and Allow all HTTP and HTTPS websites. The latter requests optional access only after a click and Chrome approval. It excludes local files, and browser internal pages, and does not replace AI action authorization. Manage or revoke site access in Chrome extension settings.

When the browser needs pairing or is disconnected, a compact notice above the conversation opens a separate setup guide. It covers extension installation, local pairing, site permissions, and checking readiness, with remote desktop access and troubleshooting. Pairing codes remain in the controlled device local interface and must not be pasted into AI chat. Desktop context can be selected manually with Add context, or requested by the assistant for the current question: desktop session inspection, semantic UI inspection, or current-screen capture. A new conversation with no attached context can request these reads. Approving the permission card automatically continues the original question; rejecting it performs no read. Authorization is bound to the device and current input, with expiry and usage limits; a new request is required when it expires or is exhausted. Screenshots require an image-capable model. Read approval does not authorize mouse or keyboard input, and cannot bypass an offline device, missing OS permissions, or locally disabled capabilities.

Conversation directories have no fixed expiry. You can reject pending requests or remove approved entries; native directory identity and operation authorization are still checked on use.

When file metadata from a conversation directory is truncated, the assistant can look up a known immediate file by its exact name or continue with a device-issued cursor for an unknown name. Paging is limited to one approved directory and the same filters and bounds; each page rechecks directory and file identity. It is best effort: if the directory changes between pages, names may repeat or be omitted. A cursor expires after a short time and cannot be used as a path or to expand the approved scope. A scan that reaches the device limit fails rather than proving that a missing file does not exist.

In an existing conversation, select Schedule this conversation to open Scheduled tasks, then enter the instruction and one-time execution time and confirm. The server atomically creates and enables the timer; no draft or second activation step is needed. The device and conversation stay bound to the original conversation. Times are entered in the selected display time zone and stored as UTC. If the original requirement revision has changed, creation or activation is rejected; return to the conversation to schedule it again. Use the Conversation continuations tab to manage tasks and view results through run history. Completed tasks retain rename, delete and history actions, but cannot be rescheduled. To continue again, create a new scheduled task from the original conversation.

An enabled conversation timer survives ordinary follow-up chat, including “confirmed”; only an explicit pause or cancellation stops scheduling. When due, it waits for the conversation to become idle and executes the approved task text in the latest conversation context. Dispatch pins the current input revision, so new input during execution still fences the older turn. Permissions are rechecked without extending expiry or scope.

Automatic web-message sending is a trial feature. Before enabling it, complete a guided run with the intended account and actual page, then inspect its outcome. The extension must uniquely identify the Slack workspace and member.

To publish an independent task:

1. Open Task contract and inspect its saved version, run limits, account, recipients and permission scope.
2. If no contract exists, select Generate review contract from completed guided run. Evidence must be complete, and attachments need file-creation receipts from that same run. The generated contract awaits review; an existing contract stays unchanged.
3. When the contract matches the current task version, select Check guided run for publication, confirm the permission scope, fixed destinations and budgets, then select Approve and publish. Scheduling starts after the server verifies the evidence.
4. Check each outcome in run history. Publication enables the schedule; a verified draft establishes only draft preparation. Successful sending requires an actual send result.

Gmail uses the verifiable signed-in account from the guided run; Slack uses a verifiable workspace and member. Correct missing or ambiguous page/account identity before recording again. Authorization has no automatic expiry by default; use Revoke task authorization to revoke it.

On the controlled device, sign in as owner and open Local AI Policy → Local web message permissions. Read the current policy, explicitly choose the Computer Use master, browser extension, draft preparation and message sending switches, then save. Enabling sending does not enable the other switches or approve a message or automation. Saving requires the device worker to acknowledge the same policy revision; capability listings then refresh with the device heartbeat. A conflict or uncertain application requires a new read, without automatic retries. Manager and remote pages cannot change these local switches. Disabling them blocks later undispatched operations; it does not recall messages already sent.

The Gmail extension send adapter compares the visible Google account at page snapshot time with the account immediately before activation. A missing, ambiguous or changed account returns DefinitelyNotSent without clicking. An account change after activation leaves OutcomeUnknown; a notice from another account cannot prove delivery. The account identifier also travels with the page reference into the draft snapshot and review contract. A new independent run must verify the same account; check the actual send result after each run.

Tool results, user messages and AI replies are conversation history and are not removed from model context merely because time passes or an execution authorization expires. Window trimming or summary compaction occurs only when the context capacity threshold is reached; the original transcript remains stored. Historical results describe what happened at the time, not the current device state, and do not authorize another execution. New actions still validate authorization deadlines, target identity and required current state. Changes to model destination or source authorization can still restrict disclosure of affected content.

Windows PowerPoint and Word file batches require a single .pptx or .docx output name of at most 255 UTF-8 bytes; non-ASCII characters may occupy multiple bytes. Paths, reserved device names, and stream names are rejected. Copies are saved in the selected and authorized output directory without overwriting an existing name. Other file artifacts retain their own name limits. This file-batch feature is available for trial use. Test a copy and inspect its content and formatting; available operations depend on capabilities reported by the current device.

Word batch processing reads stored text from one selected DOCX and can create a copy with approved plain text replacing its body. Original body formatting, tables and images in the copy are replaced; section settings and other package parts are preserved. The source is unchanged. Fields are not evaluated, and tracked changes or imported body content are rejected. This uses file processing without opening Word or a Live session. Enable local observation and Office permissions and select an output directory before requesting a copy; the copy still requires action approval.

Verified Windows PPTX and macOS iWork batch copies use the same file result card, showing the file name, size, and SHA-256. The result remains visible after refreshing the conversation. Unknown or unverified receipts are not presented as verified new files. The card records execution; it does not authorize another read or modification.

When you explicitly name a previously verified PPTX or iWork batch copy in a new message, the Assistant can reuse its recorded file reference while it remains valid. Expired references require selecting the file again. This does not repeat creation or grant permission for another operation.

When a new request names a historical artifact, the assistant restores its file reference only while it remains valid with enough time for model-request preparation. An expired reference does not delete the historical result or regenerate the file automatically. Select the file again on the controlled device and continue under the current permissions.

The current Windows batch-file path requires local NTFS storage and rejects UNC network paths and reparse points. A drive root can be identity-checked as a directory, never as an input file. Actual reads and writes remain subject to the approved scope and Windows access permissions; the assistant does not elevate automatically.

For a manually selected Windows local directory, adding only the \\?\ prefix to the otherwise identical resolved path no longer requires an extra confirmation. Other resolution changes still require review. This confirms only the directory selection, not permission to read, export, or modify files. Task contracts for generated text files also accept this device-resolved local drive form; the stored directory remains bound to the target device and requires a valid selection for each run. When a fresh device resolution matches the directory already approved in the task contract, a difference consisting only of this prefix does not require another directory approval. File operation permissions are still checked separately.

AI Assistant conversations

The bottom conversation tabs in Web, iOS and Android appear only when subtasks exist. Without subtasks, no standalone Main conversation tab appears before, during or after approval.

The conversation header opens session history and a new conversation through Conversations. The + menu at the bottom left of the composer holds context selection, goal tasks, conversation resources, management and details. Main and subagent conversations both use this entry point. Context selection and task details have icons. Continue working uses distinct off/on toggle icons; select it to change the state. The active AI approval indicator appears to the right of +, in the same status area as selected context; select it to open approval settings. Selected context, Continue working and AI approval all have icons. Narrow screens or panels show only these icons, with tooltips and accessible names retaining the full labels and context count. The message area keeps tool activity and screenshots near the related exchange. The input stays at the bottom, with +, selected context, context usage and Send/Stop on one row below it. Pending permission and AI-proposed directory decisions appear in the conversation; closing a menu does not decide them. On a narrow screen these controls remain reachable without a permanent side panel.

During continued work, model segments and background tasks have separate lifecycles. After approval, the goal may plan independent work while other tasks run normally. When native background results are needed, the assistant uses control_goal with decision: "wait". The server persists the exact tasks from this goal and resumes when any member finishes; the page need not stay open. Child dependencies still use wait_subagents. Failed or cancelled tasks retain their actual results and do not imply goal success.

Reaching a normal segment step limit hands planning back to the scheduler. Overall goal budgets, repeated-call protection and owner controls still apply. Temporary model outages enter a model wait with backoff; interrupted actions or unknown outcomes require reconciliation. Late receipts remain available after pause, stop, cancellation or new input, without restarting the old plan.

While the main turn is running, the input row shows Stop. It remains visible but disabled until the current conversation state is available. Stopping shows a pending control; Send returns after stopping completes or the turn ends. Existing child tasks can still have a Stop control while the main input is idle.

Open + below the input and select Continue working when sending a request to start a bounded, durable goal. On desktop, Web, iOS and Android, the goal panel above the conversation defaults to a single row with a goal preview and current status. Select it to expand the full text, progress and controls; the expanded area has a height limit and scrolls. Switching to a subagent keeps the main goal visible; controls belong to the main conversation. Details show usage and deadline. When waiting for you, reply to the displayed question; paused goals have resume or retry controls. Pause and cancellation are separate owner actions. After disconnection, the card labels its state as last known. The platform controls goal budget switches and values; owners cannot increase the budget of one goal. Running goals use changes at their next budget check. The AI can also propose a goal from a normal conversation, but the proposal does not run until you or the enabled approval AI approve its exact text. Completion is reported by the AI. If work remains, select Goal is still incomplete in the completed goal details, edit the new request and send it, or ask the AI to propose a new goal. The new goal references the earlier completion summary and evidence while the old goal remains completed with its original usage; the server verifies that both goals belong to the same conversation and device. A new message during an active goal stops its planning without silently changing the approved goal text. If the goal needs a different scope, the AI asks for clarification, then proposes the complete revised text for approval by you or the enabled approval AI. Approval keeps the same goal ID and spent budget. Device actions remain subject to their own permissions.

AI automatic approval also reviews proposed goal creation and revisions, including proposals linked to a completed goal. Web/Tauri shows a waiting state while review runs; turning off automatic approval restores manual controls. Approval authorizes only that goal text within current server limits, and later device operations require their own permissions. Decisions and faults are written back to the conversation; eligible administrators can inspect their own review details. Approval statistics include the goal-proposal source. A late review cannot override new input, a stopped delegation or a committed manual decision. A goal proposal may remain valid after its originating task reaches its execution deadline or call budget. Automatic approval then ends with an explicit reason; send a new message to propose the goal again. It does not wait indefinitely or require a database reset. Reviews use the complete approved goal saved by the server, which may restate the original user wording; directories and later operations still require separate approval.

The default model token total for a long-running goal is 10,000,000. Main and child calls, compaction and report corrections share the original goal's usage; pausing and resuming do not reset it. The owner can configure the server-wide total in Settings → Long-running goal budget.

The sidebar AI Assistant entry opens an overview with AI Assistant attention and Scheduled tasks cards; existing task links still open. Attention collects goals, permissions, and conversations requiring your action. While Tauri is running, system notifications continue even with its window hidden. Notifications contain a status and the attention route, never goal text. A browser-only session has no background push subscription, so it cannot notify you after the tab closes; the goal form asks you to return to the attention list yourself.

Automatic approval is a separate, initially off switch for this conversation. It requires a configured and enabled independent approval model. While on, that model judges each request using the same authority the device owner would have for manual approval; it has no extra scope and the switch has no expiry. It may approve or deny with a reason. A risky, unclear or human-dependent request is denied and the execution AI can ask you or choose another approach. A reviewer outage produces an explicit unexecuted denial. In Manager, approval-model calls are charged to the current user; Content Safety remains platform-paid. Turning the switch off invalidates unused AI-approved grants. Starting a goal never turns this switch on.

Web/Tauri uses a switch for the server-confirmed AI approval state. Saving shows progress and prevents duplicate changes; failures reload the snapshot. If a child changes or finishes after observation, a follow-up receives a refresh-or-read-result hint rather than a storage-failure message.

The main conversation and its existing and future subagents share one automatic-approval switch and review-usage ledger; you do not enable each child separately. Each child still requests its own permissions and receives grants bound only to that child. Reviews use the original owner instruction saved at creation and the child’s evidence; a delegated task description is not owner authorization. Turning off the main switch also prevents unsent child reviews from starting. Children originating from scheduled tasks do not inherit this switch, and paused, cancelled or finished tasks cannot use it to resume execution.

With automatic approval enabled, ordinary permission requests in Web and desktop conversations show a compact review status instead of manual confirmation cards. Interactive terminal commands and requests needing revalidation retain their owner controls; turning automatic approval off restores manual review. The latest reviewer fault remains visible in the conversation with a link to approval records. Reviewer calls use the approval model’s configured runtime output-token limit, with no additional fixed 2048-token cap. Truncated, empty or malformed replies never approve an operation.

If a reconnect changes the execution environment or policy bound to a pending command, the platform records a system refusal and returns it to the assistant for reconsideration. Approval details retain the original model verdict and actual usage.

For OSS, configure it on the Signal Server. OSS records review counts and token usage only; it has no price configuration or monetary accounting:

1. Open Settings → AI Approval Model (/system/approval-model). This entry is available in Default and Signaling modes. A DeskServer-only host uses its central Signal Server's configuration.
2. Enter the protocol, model, base URL and separate API key, or select Reuse AI gateway configuration to the right of Save when the AI gateway is already fully configured. Reuse copies the gateway's saved connection, key and request options into the approval configuration and saves immediately. Existing approval settings require confirmation before overwriting; cancelling preserves saved settings and unsaved inputs. The saved approval enablement remains unchanged. Both configurations stay independent: later gateway edits do not change the approval model. A blank key field keeps the approval model's own saved key; the clear-key switch removes it on save.
3. Enable the approval model and Save. Test approval model is optional and is also available while the saved model is disabled. Tests call the provider with fixed review cases and incur model usage; they do not execute device actions or automatically enable conversation approval. Missing, failed or outdated tests do not block use of a configured, enabled model. Connection or request changes make previous test observations outdated; changing only the enable switch preserves them.
4. Return to the AI Assistant conversation and open + → AI approval and turn on the AI approval switch. You can enable approval before entering anything in a new conversation. Opening the approval panel initializes the empty conversation; once loading completes, you can use the switch. Initialization sends no chat message and makes no model call. Saving the server configuration does not turn on conversation approval. The conversation panel explains why the switch is unavailable if the model is disabled or its configuration is incomplete. Actual model-call failures or invalid approval responses produce explicit error receipts and do not authorize the requested action.

Approval settings report save and test results through toast notifications. Model tests and actual approval calls share Runtime output tokens. If a test exhausts that limit, the notification shows the saved value and asks you to increase it, save and test again. Changing the limit invalidates previous validation. A truncated response never counts as a passed approval test. The page does not automatically raise limits or retry provider calls.

The approval panel checks the server's conversation record even when the browser already has a conversation ID. It initializes an empty conversation only after confirming that the record is absent; read failures never clear existing context. Loading or initialization failures appear inside the panel with a Retry button.

Use + → Conversation directories → Add directory to browse and select a directory on the controlled device without typing a path. An AI-proposed directory instead appears as a decision card in the conversation, showing its full path and purpose with separate Approve and Deny actions. Windows drive roots and Linux/macOS / are selectable; the virtual drive-list root is not. Browsing stays on the assistant's selected remote user session and uses signaling only, without a WebRTC file-transfer channel. The device filters directories before pagination, so files never consume directory-page slots. A directory is added only after server confirmation; a changed canonical path requires confirmation.

File Manager no longer has AI buttons or file/directory context attachment operations. Conversation directories do not approve every file operation. Document batch operations bind their source through file discovery and authorized read results in those directories. Terminal/window context and image/tool-result attachments retain their separate purposes.

The AI Assistant product switch is enabled by default in new device configurations and when the setting is absent. An explicitly saved disabled value is preserved. This does not grant operation permissions: collection policies, Computer Use limits and per-operation authorization still apply.

Internal server messages used to resume a conversation are omitted from restored chats, conversation titles and message counts. They remain in the stored execution context and are not treated as new user input or additional permission.

Native macOS text-file operations do not require semantic observation or a foreground application. The Computer Use master switch, conversation directory scope and per-operation authorization still apply.

Web, iOS and Android update/delete confirmation cards show the file name, full SHA-256 and source call ID from the device receipt. Updates also show the exact matching and replacement text, or the complete replacement; deletion is explicitly recoverable. Each approval permits one exact operation. Missing verifiable review details block approval; the AI's stated reason does not replace those details.

File operations retain the device Computer Use master switch, with no separate file-creation toggle or device-wide directory allowlist. Open Directories in the current AI Assistant conversation and add a directory on the controlled device, or approve a directory proposed by the AI. Directories must exist and use canonical absolute paths; a changed resolved path needs another review and confirmation. Consent belongs only to this conversation, survives refresh, can be revoked, and is not inherited by a new conversation. Directory references have no fixed expiry; their identity is checked on every use. A replaced or unavailable directory must be selected again. Directory consent does not approve all file operations: read egress, creation, updates and deletion each retain their operation-level authorization. In an interactive conversation, the directory tool waits for explicit approval or rejection and then automatically continues the original requirement; no “Continue” message is needed. No model call or directory-content read occurs while waiting. Stop interrupts the wait; closing the directory panel does not submit a decision. After directory approval, the AI still requests any required operation permissions. Creation never overwrites an existing file, supports empty UTF-8 text, and has a 64 KiB write limit.

Document conversion and layout preview

AI Assistant can convert PDF to Markdown or plain text, and Markdown, UTF-8 text, or a .typ file to PDF. Conversion uses fixed Rust libraries and a bundled CJK font. Typst compilation and rendering run in a separate, resource-limited child process under the controlled user, bounded by CPU time, memory and output size; exceeding a limit fails the conversion without affecting the worker. Conversion does not start Office, a browser or a shell, and it does not download templates, fonts or other network resources. .typ source is compiled directly, without access to imported files or packages; Markdown and text still use the built-in template. The source must be an authenticated file result from the current conversation. Output requires an approved conversation directory and a separate one-shot conversion approval, always creates a new file and never overwrites an existing file.

Markdown and text files can also be previewed independently with the same Typst template used for PDF generation. A preview does not create or authorize a PDF. Its first page appears in a conversation card; additional pages are loaded only when the owner changes pages. Preview images are UI-only and are not sent to the model. Each preview is bound to the owner, device, conversation and current worker, expires after 30 minutes, and at most two are retained per conversation. Reloading after the live preview state is gone or restarting the worker requires a new preview.

PDF input and generated output are limited to 32 MiB. Markdown/text/Typst input is limited to 4 MiB. PDF input is limited to 500 pages with at most 200 selected pages per conversion; generated documents are limited to 500 pages. Each rendered preview page is limited to 400,000 bytes. Encrypted PDFs and image-only PDFs requiring OCR are rejected. Preview and conversion are available only in an interactive owner conversation and cannot be recorded in or published as a scheduled task. The worker reports the current interactive user's Home directory as path guidance so the assistant can propose a sensible directory; that value is not a directory selection or permission. The macOS text tools include update_text_file and delete_text_file; capability listings retain the original keys alongside localized descriptions. Updates replace all text or one unique matching fragment. They bind the complete file version and SHA-256 from a verified read, creation or update receipt in the current conversation. Every update/delete requires exact confirmation and a one-use grant. Directory metadata lists immediate children only; reading a child's contents and sending them to a model need separate authorization. Truncated reads cannot justify a full overwrite. Links, out-of-scope targets and version conflicts are rejected.

When a verified creation/update receipt and the content needed for an edit are already available, the assistant can request the exact update using that receipt’s file_version_id, with its full digest restored internally, without another directory listing or file read. The device still checks for concurrent changes. Document/spreadsheet source selection uses artifact_result with file_result_call_id, or directory_entry with that ID and the exact entry_name. Metadata and content reads require their respective permissions.

Document and spreadsheet reads use a typed source (or sources for multiple files): directory_entry names a child from a recorded inspect_files result, while artifact_result names a verified creation/read/update result. Older recorded calls remain readable. The server resolves each selector against this conversation and rechecks the approved directory and file identity; the model cannot provide a path or device token.

Browser tools accept the observed page_id and, where needed, element_id values. The server restores the full verified page and element references before checking permission, profile, origin, page incarnation and revisions. IDs are not reusable authority: stale or ambiguous observations require a fresh snapshot. Browser navigation derives the displayed approval origin from the exact URL. browser_wait_for fixes state=present; formula workbook creation fixes locale=en-US-a1. The approval card still contains the complete resolved target.

Model-visible JSON results may include a short result_summary with the output type, tool-call status and original result status. It does not replace the typed payload or prove a business goal was reached. Draft handoffs expose handoff_result_id; the server restores the original preparation and complete receipt for an exact send request. Sending still uses its separate business_effect outcome.

Updates and deletions retain a private recovery directory beside the target: approved-before.txt is an independent approved-before copy; deletion also moves the original file to original there. There is no permanent-delete fallback. Web file receipts are collapsed by default and show name, bytes, digest and recovery location when expanded; unrecognized formats remain raw. A post-commit concurrency conflict is reported as unknown, with recovery evidence retained and no automatic rollback or retry. Inspect the target and recovery copies before acting; do not overwrite a concurrently created file. Unknown-result recovery receipts remain available when reopening the conversation.

In the Web UI, “Command result (from device)” is collapsed by default; select its title to expand it. Standard receipts show the exit code, execution time, and stdout/stderr; terminal mode retains combined output. Empty output, truncation, and redactions are labeled. The original receipt can be expanded separately. Non-JSON or unrecognized formats are shown unchanged, without altering the saved result or AI interpretation.

Older conversation history does not expire with time. Model destination and source authorization are still checked before disclosure. New terminal errors are saved with the conversation, so refreshing or reopening displays the same specific reason; a new turn clears the previous error. Errors not saved before upgrading cannot be reconstructed.

System settings → Context management (/system/context-management) switches between checkpoint summaries and window trimming. Summaries are on by default. Changes apply on the next turn and survive restarts. Compaction makes an additional call to the current model and may incur charges; failures are explicit, without silent fallback to trimming.

Isolated background command interpretation does not reset the regular conversation's context meter baseline; new results and replies still count. Actual summary compaction and history-window trimming produce distinct short system notices in the conversation area, also restored with the session. These notices do not mean the original chat was deleted. A baseline overwritten by an older version's isolated interpretation refreshes on the next regular model preparation.

AI natural-language replies use the interface language supplied when sending a message. Permission resumes and background follow-ups inherit the saved conversation language. This preference does not change tools, commands, JSON fields, or permissions. Existing conversations without a saved preference record it on the next normal message.

On continuation, AI retrieves history on demand. Elapsed time does not make historical content unavailable; disclosure must still be authorized for the current model. Historical commands are not automatically replayed.

The ring at the left of the Send row shows the share of available conversation budget in use. Click it, or focus it and press Enter/Space, to open details. The panel first shows the total context budget and the bytes reserved for system instructions, tool definitions and other content, each with its share of total budget. It then shows the conversation budget after these reservations, conversation usage and its categories, remaining space, and the estimated draft increase. Tool definitions describe tools and their parameters for the AI; they are separate from tool calls and results in the conversation.

Reservations use the latest request preparation and are not added to conversation usage again. Replies and tool results increase conversation usage; compaction/trimming updates it from retained content. Different tools or attached content can change reservations on the next call. These are content-size estimates, not the model’s token limit or exact request size, and remaining bytes are not an exact character allowance. Unmeasured values display “—”, not zero. An existing conversation updates its request details after the next normal AI call.

Only pending requests or requests needing revalidation appear in the main area. Resolved requests are hidden by default; use the Permission request history icon to review their status and details in a scrollable panel. Approval does not imply successful execution.

On the bottom row of the composer, alongside Send, the left side contains the context ring, Task details icon, then Permission request history icon. Hover to see their names and select an icon to open its panel. The top-right Task details text button is no longer shown.

Compaction/trimming notices stay at their recorded message boundary and display the server-recorded time; later messages do not move them. Unlocated older records appear in collapsed history, with missing times marked as unrecorded rather than replaced by refresh time.

A child's background command interpretation has no tools. Invocation markup emitted as prose is withheld and corrected at most once; a repeated failure produces an explicit error. The original command result remains available, and commands in prose are never executed.

The standalone assistant fills the available page area without an outer title or subtitle. Its back button sits to the left of the conversation heading and returns to the device page.

The conversation header contains Conversation history and New conversation. There is no separate connection status row. The icon before the conversation title is green when signaling is connected, amber while connecting, and gray when the assistant is disabled. Hover for its status explanation; screen readers can also read it. Hover over the conversation title to see the selected target name. History lists the 100 most recent conversations for the current device; select one to restore and continue it. You can browse the list during a task or request, but switch only after it finishes. Empty conversations use only the input placeholder, without a duplicate explanatory paragraph.

In addition to manual control, LCXL Remote Desk lets AI models read and analyze device state and, when the authenticated owner explicitly approves a command, act on the diagnosis.

Under a shared access code

When you connect by an access code rather than as the owner, the session is capability-scoped. It never receives owner free-form command admission; non-owner and shared-access execution remains template-constrained or disabled.

How It Works

AI is orchestrated by the central signaling server (the "central brain"). The device is a thin edge that supplies read-only evidence on request; owner-confirmed commands return through a separate, sealed execution path. When a user asks a question during a session (e.g. "Why is this system slow?"), the central server drives a strict pipeline:

1. The central brain requests read-only evidence from the edge (system info, processes, ports, logs, screenshots).
2. The edge collects and redacts the evidence locally — redaction fails closed, and raw screenshot bytes are stripped before anything leaves the host.
3. The central brain calls the model (only after the edge's redaction succeeds).
4. The central brain runs a multi-turn tool loop and streams the answer back to the browser.
5. If the model requests exec_command, the loop parks. The browser shows the complete shell, command, working directory, timeout, and server-authoritative risk; only an explicit approval resumes dispatch.

The diagnosis panel has explicit resize handles: drag its left edge to change the width, its bottom edge to change the height, or its lower-left corner to change both. Drag the title bar to move the panel anywhere within the remote desktop view. While the view is at the bottom, streaming output follows the latest text automatically. Scrolling up pauses that behavior and shows a down-arrow button that returns to the latest content without losing the reader's place unexpectedly.

Launch applications and run commands

For applications and long-running programs, the assistant uses launch_application. It requires a separate approval from exec_command: command execution collects output and reclaims its managed process tree when it ends; application launch does not collect stdout and does not close the application when the task finishes or is cancelled.

list_applications supplies reference information about installed applications. Its queries accepts multiple fuzzy search terms; localized and English names can be searched together. Search terms are required by default. Only explicit allow_unfiltered=true permits unfiltered, paginated discovery. Catalog paths, arguments, and working directories are suggestions; the independently supplied and approved launch request determines what runs.

Before approving, review the target, complete arguments, working directory, and administrator option. Each launch approval is single use; changing arguments or privileges requires new approval. A URL or document alone does not select its associated application: specify an executable and pass the URL or document as an argument. Observing windows, controlling browsers, and sending content still require their own permissions.

Windows supports explicit executable paths and packaged application IDs. Ordinary user privileges are the default; the launcher fails when elevation is required instead of invoking UAC. Explicit administrator launch applies only to executables and requires an already available elevated token for the same user. Administrator group membership alone does not guarantee that the current host can obtain it. A third-party application can still request elevation after it starts. macOS uses application bundles; Linux uses executables and an available systemd user session. Administrator launch is unsupported on macOS/Linux. The working directory is optional and is unsupported for macOS bundles and Windows packaged applications.

An accepted launch does not prove that a window or page is ready. If the outcome is unknown, observe the application or process before attempting another launch. If a browser still needs extension setup, open the conversation's setup notice and follow the dedicated setup page.

AI Assistant Exact Command Grants

AI Assistant uses its itemized permission card for owner command approval, without a second legacy diagnostic dialog. In confirmation mode, an owner may request non-blocklisted commands outside the template catalog, including du, df -h, pipelines and multiline scripts. Read-only/suggestion-only modes, non-owners and shared access do not gain execution authority.

Review the complete original command, shell, working directory, target device/session, effective timeout and stdout/stderr limits. An omitted working directory uses the execution process default, not necessarily the home directory. Off-template commands are Critical and potentially mutating: the blocklist is not a shell sandbox, the shell interprets the approved script, and elevation is not automatic. A grant permits one execution of the frozen plan. Changed input, plan, target session or policy requires fresh approval. Unknown outcomes keep the original task and are never automatically resent. Missing or invalid command review data cannot be approved.

A command that needs terminal interaction is requested in interactive mode. Its approval card marks it as an interactive terminal command and whether it needs elevation; approving opens a terminal bound to that pending approval on the current page and sends the approval with that terminal. The owner can type (including an elevation password), resize or stop it, and closing the terminal stops the command. The combined PTY output returns to the model. Only the owner can approve an interactive command, manually, on a page that supports terminals; automatic approval, scheduled tasks and background goals never approve or run one, and requests are refused when the device disables PTY or interactive elevation.

Ordinary noninteractive commands do not require a PTY or foreground application. Offline targets, system permission errors, timeouts and cancellation are reported as observed.

When a background command finishes, Web AI Assistant separately displays the original result saved by the device, including timeout failures; this is not an AI-generated answer. For a child's command, the result-interpretation deadline is frozen at dispatch: the approved maximum runtime plus five minutes for delivery and interpretation, capped by the session scope's expiry. Running longer than five minutes within that window does not require a second approval to interpret the result. This changes neither the approval-wait deadline nor the command's execution timeout.

When the main assistant's background command finishes, the assistant continues your existing requirement automatically, with the conversation history and its tools. Remaining work uses grants that are still valid; when none covers the next step, the assistant requests permission through the normal flow. If nothing remains, it briefly reports the result. Command output is treated as data, but a continuation can run while you are away, so revoke grants you no longer want used. Each requirement allows at most three automatic continuations; beyond that, the result stays available and your next message continues the work. A newer requirement, a running goal or an offline device stops or postpones the continuation while retaining the original result. A child's interpretation stays limited to its task and this result, and cannot launch another command. Upgrades neither retroactively authorize completed old tasks nor rerun commands.

On the controlled device, System settings → AI policy → Maximum runtime per command accepts 10–7200 seconds and defaults to 600 seconds. Execution is also bounded by the duration requested on that command's confirmation card. Moving to the background does not reset the clock, and increasing the device ceiling does not extend an already approved command.

Key Properties

• Thin Edge — the device never runs model inference or holds provider credentials; it only collects and redacts evidence when the central brain asks.
• Read-Only Data Collection — system info, processes, ports, logs, and optional screenshots, gated locally by the edge collection policy. A screenshot is offered only to a model declared image-capable; the original image is kept only while the active turn needs it, then replaced by bounded text metadata instead of being retained in conversation history.
• Model Agnostic — compatible with both OpenAI-compatible and Anthropic endpoints, configured centrally.
• Suggest-Only Defaults — the model proposes fixes; execution requires explicit user confirmation, capped by each device's local execution ceiling.
• Owner-Confirmed Actions — in Confirm Each Action / Session Approved mode, the authenticated owner may approve an off-template PowerShell, pwsh, bash, or sh command. It is always shown as Critical and only the effective blocklist is claimed to have been checked.
• Target-Verified Shells — the Desk Server runs a bounded, side-effect-free probe for the executor-supported interpreters when it connects. The model's exec_command.shell schema lists only the verified intersection and marks the first entry as preferred. If a model still requests another shell, it receives unsupported_exec_shell with the current available list and may retry without opening an approval.
• No Autonomous Approval — the model may request a command, but it cannot approve its own request. Fleet, automation, MCP, shared-access, and non-owner paths remain template-only or non-executable.
• Bounded, Continuable Turns — the central loop stops after too many calls to the same tool type. Completed output and tool results remain visible and persisted, so the user can send a follow-up such as “continue” in the same conversation.
• Durable Background Commands — an approved command that is still running after 8 seconds becomes a background task instead of blocking the diagnosis turn. The dispatch receipt returns the task ID to the model as a structured field, while the diagnosis panel shows a localized “Moved to background” state with the same ID so the user, model, and later completion event can correlate it precisely. The command keeps running until it completes, the operator cancels it from the diagnosis panel, or it reaches the device-local command runtime limit. That limit is configured under the Desk Server's Local AI Policy, defaults to 600 seconds, and accepts 10–7200 seconds; it is independent of the 8-second foreground threshold. Saving a new limit automatically refreshes the host's central signaling registrations, while the host immediately enforces the saved value as its authoritative ceiling. Portable/open-source Signal stores the task and its completion in SQLite, exposes it through wait_for_task, replays pending completion delivery after a Signal restart, and asks the host's execution ledger when a live result was missed. Once the durable result arrives, Signal continues the main assistant's requirement in a bounded follow-up turn without waiting for another user message; that turn uses existing grants and the normal permission flow. The Manager path provides the same completion-follow-up behavior through its distributed work ledger when the administrator enables automation.
• Readable Answers — assistant prose is rendered as GitHub-flavored Markdown, including headings, lists, code, and tables. Raw HTML is ignored and model-supplied image URLs are not loaded.
• Recoverable Conversation View — both Manager and Portable/open-source Signal expose the same persisted conversation snapshot. If a terminal live event is missed, the panel recovers the settled answer and tool results instead of remaining stuck on “Awaiting approval”.
• Inspectable Tool Calls — select any item in the tool timeline to expand the model-produced JSON input and the redacted, bounded output returned to the model. The details remain available in settled turns and restored conversation history.
• Shared Core — the transport-neutral diagnostic logic lives in the desk-diagnose-core crate, reused by the central brain so behavior never drifts.

Context selection and recovery

Selecting a terminal, window, file or document saves that object selection; reading it still requires permission. Wait for an active turn to finish before changing its selections, and refresh the conversation to check current state.

After a disconnect, restore the conversation and inspect its tool records. Permission confirmation covers only the listed scope. Reconnection, retries and application changes preserve that scope; select an expired object again.

A new question supersedes older work that has not started. Dispatched device actions may still finish, so inspect the original action receipt. A cancellation request only requests a stop; check device state when the outcome is unknown.

Background commands and actions retain their original results. You can inspect receipts if automatic interpretation is unavailable. Tool records distinguish success, failure, not-started and unknown outcomes.

Linux capability boundary

On Linux, the Assistant advertises each capability independently. System information, process and network inspection, container inspection, terminal-output reads, and owner-confirmed bash/sh execution use the same thin-edge and confirmation boundaries as Windows and macOS. On a booted systemd host, it also provides systemd service status and bounded journald JSON queries; those two capabilities remain visibly unavailable when systemctl/journalctl or the systemd runtime is absent, and journal visibility is limited by the Desk Server process permissions.

Explicitly selected Linux files and directories can be inspected without sending native paths to the model. Directory traversal and reads are handle-relative, reject symbolic links, revalidate object identity around bounded reads, and never recurse implicitly. Confirmed artifact creation is restricted to an exact device allowlisted directory and publishes a private 0600 staging file with Linux no-replace rename semantics, so an existing target is never overwritten.

Linux desktop integration requires a logged-in, active, unlocked local GNOME Wayland session running as an ordinary user. Linux desktop actions are a trial feature. Verify observation, actions and release in the target environment before use; KDE, X11 fallback, the login screen and unattended graphical sessions are outside the current support scope. Device connectivity alone does not mean desktop actions are available. File and terminal capabilities have their own permissions and readiness checks.

Portable mode attempts automatic Portal restoration only once per host startup. Recycling the media worker does not retry it. If authorization must be established again after recycling, use the local controls on the host.

Screen observation requires an existing local Portal authorization for the selected output, plus the Assistant's screen permission. Remote Assistant requests do not open the system authorization dialog or restore a Portal session. A screenshot marked latest_observed includes its receipt age at return and does not guarantee the current screen state. Screen-coordinate input also uses best effort: the latest observed frame may be used within 30 seconds of its original receipt, with a separate one-shot exact whole-output grant and an active local input control period. The device checks age using its monotonic clock before each submission. Reusing a cached frame does not renew its age; expiry requires a new observation and approval. The screen may change during that interval, and LatestObserved is never relabeled Fresh.

Browser actions require the Chrome extension paired on the controlled device. Pairing uses the local host page and a one-time proof generated by the same OS user running the host; signing in to Manager remotely does not establish this local proof. Browser readiness is independent of Portal screen authorization.

Linux desktop writes require an active locally authorized best-effort input control period, in addition to target checks, action permissions and the original frame age limit. Control attempts to block only the keyboards and pointers present when it starts; it does not provide complete isolation or cover newly attached devices. Missing device permissions produce an explicit failure without adding the user to the input group or elevating the desktop process. If an application needs accessibility enabled, the device owner must explicitly configure it locally after reviewing its effects.

Device acquisition failures report acquired and failed counts, permission-denied counts, and the first other device error, such as held keys or a busy device. If no acquired keyboard supports the escape shortcut, acquired devices are released and the control period does not start.

Portable Tauri mode provides an “AI Input Control” tray window. Select a duration and confirm temporary blocking before starting; accepting partial coverage is optional. The window shows actual device counts and a stop button. Closing it or losing the host connection cleans up the control connection. Only the worker's Ended acknowledgement is shown as confirmed release; connection errors are not treated as release confirmation. ServiceDaemon mode requires a registered native session shell and an endpoint published by its corresponding ordinary-user worker. An unregistered session or an invalidated worker is unavailable. Before trial use in service mode, verify that the current desktop can open the entry and reliably release control.

A local command can also establish an input control period. Find Local AI best-effort input control endpoint in the current session worker log, then run the command in a local terminal as the same ordinary desktop user (use the actual current worker path):

lcxl-remote-desk-server ai-input-control /run/user/1000/lcxl-ai-input/<worker-id>.sock --seconds 60

Read the explanation, type START, then release all keys during the three-second delay before blocking is attempted. Partial failure is rejected by default; add --allow-partial only if you explicitly accept partial coverage. The command reports actual acquired, failed and skipped counts. Press Ctrl+Alt+L to release input. Expiry (at most 300 seconds), device failure, command disconnection, desktop identity loss or worker exit also ends control. Keep the command connected. After the first desktop action binds a turn, the application checks its state with that central server and releases input control when the turn ends, is cancelled, is superseded, or loses its execution lease. Unavailable queries or network connections do not extend the local deadline; local stop remains available. The period binds to the first admitted desktop action’s upstream, user and complete turn identity. Another turn requires starting a new local control period and cannot reuse the previous one. An accepted cancellation of the currently bound desktop action also releases control. Ordinary action completion does not end the whole period, and cancellation of another or older action does not close a new period. It does not hide the screen. Browser and file actions do not depend on this control period.

This is local IPC within the same OS account. Terminal confirmation is not proof of physical presence and does not isolate programs already running as that user. The entry grants no additional AI action permissions, changes no device permissions and cannot retract input already submitted. On the target GNOME desktop, check the blocking counts, stop button and exit shortcut before using it for a real task.

A Portal input reply does not prove that input has been processed or that the screen has changed. With only that reply and no effect evidence, the Assistant retains an unknown outcome, requires a fresh observation, and does not automatically repeat the action.

DeskServer-only mode has no local brain

A headless desk-server is a pure thin edge: it has no embedded signaling server, so it must be attached to a remote central server (signaling server or manager) to use AI features. The portable default mode embeds the signaling server in the same process, so it remains self-contained.

When reading a selected Office, Numbers, Pages or Keynote document, the assistant uses the original document selected for that input. Switching foreground applications while approval is pending keeps that selection. Select the document again after it closes, expires or is withdrawn.

Open-source Signal also revalidates the original input, current grant and readiness around each non-browser read. Grant limits narrow the typed request sent to the host and bound the complete returned payload, including error text and image metadata; oversized content is replaced by a fixed error and is never labeled for model use. A result label is bound to the exact validated bytes and expires no later than the original grant or selected data. If input or authority changes while a read is in flight, the received Provider outcome remains durably recorded but its content is withheld; a known response is not converted into an automatic-retry OutcomeUnknown state.

Tool results and file recovery

The assistant continues using objects and results returned by its tools. Expand a tool record to check its actual input, output and errors. Follow the page prompt if a file or application must be selected again. Sending, editing and deletion require the applicable permission; check the actual state before acting on an unknown outcome.

Web fetching and host authorization

AI can choose public HTTP or HTTPS URLs for your task, including links from search results or earlier messages. The URL does not need to appear in your current message. The first permission card authorizes the complete hostname, such as example.com.

Within that conversation and the approved expiry, other paths, query parameters, HTTP/HTTPS schemes and ports on the same host can be accessed repeatedly without consuming uses. Other subdomains, such as docs.example.com, require separate authorization. Hostname case, internationalized names and trailing dots are normalized. Revoked or expired grants require fresh authorization.

The fetcher reads bounded public text and checks connection addresses and redirects. Redirects within the approved host are allowed; redirects to another host return an error. Local/private addresses, URL credentials and other schemes are unavailable. Returned content is treated as external source material.

Configuration

The model provider (provider, base URL, model, API key, output format, granted execution mode, per-turn reasoning-round limit, per-turn same-tool call limit, and command approval timeout) is configured on the central signaling server. The reasoning-round limit defaults to 40, accepts 1–80, counts model responses rather than individual tool calls, and cannot be lower than the same-tool limit. The same-tool limit defaults to 20, accepts 1–50, and counts calls to one tool type even when its arguments differ. Both are independent of the Desk Server's simultaneous-command-process limit. API keys are strictly server-side secrets — they are never returned to the browser, never written to logs, and never included in any public settings DTO.

The command approval timeout controls how long a newly suggested AI command waits for owner confirmation. It defaults to 120 seconds and accepts 30–1800 seconds. The signaling server freezes the value when it creates the approval, so changing the setting affects only later suggestions. The confirmation card shows this approval window separately from the device-enforced command runtime limit, which starts only after approval. This setting does not change the host ConfirmExec pending lifetime or the device's separate remote-access approval (Gate B) timeout.

A Test connection button next to Save probes the provider fields currently shown in the form, including unsaved edits, without persisting them. A text-only provider receives a tiny one-word chat probe; when Supports image input is enabled, the same button sends the repository-owned visual probe and succeeds only when the model reads its marker. The result reports the validated text / image_input capabilities. A blank API-key field reuses the stored secret; a newly entered key is used only for the probe until Save is selected. The API key stays server-side throughout.

The wire protocol is explicit and fail-closed: select open_ai_chat_completions or anthropic_messages; an empty, unknown, or reserved value is shown as unsupported and cannot be saved or tested. Standard, DeepSeek, Anthropic adaptive/manual, and Custom presets only populate explicit request options. The runtime never guesses behavior from a model or vendor name.

New OSS configurations and presets default to a 65536-token runtime output limit. Standard uses {}, DeepSeek explicitly disables thinking, and Anthropic adaptive uses display: omitted. Connection tests use the same runtime output limit; there is no separate probe output budget. The manual preset is editable. Its thinking budget must be smaller than the effective output limit from the model runtime and terminal completion policy; the server validates this on save and use. Existing explicit output settings keep their saved values.

After a successful save, the model settings page uses the returned configuration revisions for subsequent saves. If another page or process changes the configuration, saving reports a revision conflict: refresh the page, review the latest settings, and save again. Failed saves show the backend reason and retain unsaved inputs.

The form also requires a history context byte budget (max_context_bytes) between 4 KiB and 16 MiB. System prompts, tool definitions and request framing reserve part of this value; the remainder bounds serialized history, including tool calls/results and required replay state. Server-only metadata and inline image data-URL/Base64 payloads do not consume the text budget. Images have a separate limit of 400,000 decoded bytes each, with at most four images per model request. Image-like strings embedded in ordinary text or tool arguments still count as text. This byte budget is not the provider's token context window. Neither the application nor the small connection probe can discover the true limit of an arbitrary compatible endpoint, so enter a conservative value from the upstream model documentation and actual request composition. Probe observations are revision-bound and become visibly stale after configuration changes.

Reasoning/thinking is private protocol state rather than answer text. Readable reasoning in committed assistant messages appears in a collapsed Thinking section; opaque replay data is not shown. When exact tool continuation requires it, the signal server may persist an opaque replay envelope (such as DeepSeek reasoning_content or ordered Anthropic thinking/redacted-thinking signatures and tool blocks). The opaque replay data is excluded from transcript responses, content-safety input, and logs, but can add to provider token usage.

Long conversations remain fully persisted and visible. After the configured high watermark is crossed, only a group-safe trailing window is sent to the model and that turn shows an inline notice explaining that older history was not sent. Nothing was deleted from the visible record. If the newest indivisible message/tool group alone exceeds the budget, the request fails with AI_CONTEXT_ITEM_TOO_LARGE; raise the configured budget or shorten the new input and retry.

Each device additionally keeps two local controls in its own settings: an execution ceiling (the highest mode the AI may use on that device, which caps any central grant) and an evidence collection policy (allow_logs / allow_screen, the device's final say over what evidence may leave it).

The evidence collection policy allows screenshots by default (allow_screen = true) and disables logs by default (allow_logs = false). Explicitly saved opt-outs are preserved. Allowing screenshots does not grant a conversation permission; actual collection still requires the applicable authorization.

On Linux, the same local AI policy page also controls one-shot PTY execution for approved commands that need standard input. It is a machine-wide setting and is enabled by default; turning it off blocks new PTY dispatches but does not terminate a command that is already running. Interactive elevation is a separate, default-off subordinate setting. It remains disabled in the UI until the ServiceDaemon root-containment path is available. PTY input is relayed as ordinary bytes: the remote program controls terminal echo, and LCXL does not identify, retain, or add a separate password field for that input.

Security

Device-read failures marked unsafe for the model become a generic tool failure before further model calls or conversation persistence. Internal error details are not included in that message.

The full set of invariants — server-side authority, fail-closed redaction, server-only keys, and metadata-only audit — is documented in the AI Security Model.

In an automated task’s run details, you can review the requested directory, purpose, consent state, then approve, reject or remove an approved directory. Directory consent identifies a file scope; it does not grant read, write or send permissions. Actual operations remain subject to the task contract. The conversation refreshes after a decision; a recorded decision does not mean execution succeeded. Removing a directory that the task is waiting for ends that wait. Directory references do not expire by time, but approval waits remain bounded by the task run deadline. Removing consent does not undo operations that already occurred.

Use “Resume future runs” on a paused task to recheck its original authorization, contract, current device and model conditions. Resuming neither extends authorization nor catches up paused occurrences. “Run once now” creates a fresh occurrence for an active independent task without changing its calendar. “Cancel this run” in history targets only that occurrence; a cancellation request does not mean a dispatched operation has been undone.

Paused conversation continuations can also be resumed. The original requirement revision must remain unchanged, execution outcomes must be resolved, and the one-shot time must still be in the future; reschedule an elapsed time first. Resuming adds no conversation permissions, and execution rechecks current authorization.

You can also choose a device and an existing conversation from task management to create a one-time continuation. The list contains conversations available to the current owner; saving and enabling recheck the original requirement revision. Independent automations can start from a manually created draft or an AI proposal. Both require a guided run and explicit authorization.

The task list shows consecutive failures and the pause threshold. You can change the threshold while no run is active (default: 3). Raising it does not resume a paused task. Ordinary failures below the threshold allow the next scheduled occurrence; unknown outcomes or invalid authorization require resolution and explicit resumption.

Editing task instructions invalidates the previous authorization; independent tasks require another guided run and publication review. Editing timing alone does not expand permissions. Contract review shows authorization revisions and approval, expiry and revocation times, plus changes in budgets, permissions, steps, exception handling and instructions. Expand the previous contract to inspect its contents. Revoke task authorization pauses future scheduling and retains history; dispatched actions may still complete.

The OSS owner can configure server-wide independent task limits in Settings → Scheduled task budgets. Initial ceilings are 24 occurrences per UTC day, 64 tool calls, 100,000 model tokens and 900 seconds per run. Changes use a persisted revision check. Lower ceilings can block existing contracts; higher ceilings do not expand task permissions or resume paused tasks. Reload after a save conflict or uncertain response.

When rescheduling, the editor displays the existing rule in the selected time zone. Saving unchanged values preserves the UTC rule; changing the display zone projects the original rule again. After changing the timing, preview up to five future occurrences and confirm before saving. The server checks the conversion input and version again; changed results require renewed confirmation. Interval anchors are also converted by the server, then run at fixed elapsed intervals. Future times shown for paused tasks are a rule preview, not an indication that the task is enabled.

While a background command is running

A conversation can track multiple background tasks, each with its own task ID for waiting, cancellation, and completion receipts. The controlled host atomically admits new commands up to its configured concurrency limit. At capacity it explicitly rejects the command without queuing or automatic retry. Synchronous queries remain available. Per-command authorization, exclusive desktop/browser writer leases, and inspection guidance for inconclusive outcomes still apply.

Background results are delivered automatically; polling and keeping the current AI turn open are unnecessary. In an interactive conversation, when no independent work remains, the assistant should briefly report that the task is pending and end the turn. Ending the response neither cancels the background task nor means that it has completed; the assistant continues any remaining work when the result arrives.

The composer toolbar always includes Background tasks, with a count of running tasks (including cancellation in progress). Open the side panel to view commands and background tools in the current conversation. Unfinished tasks appear first, followed by up to 50 recent command records. Expand a command to read its saved result; long results are truncated for display only. Cancel task targets that task alone, and its final status comes from the device or Provider receipt. Command cancellation requires a connected device; saved records remain viewable offline.

When a model returns readable reasoning, committed assistant messages include a Thinking section that is collapsed by default. Expand it to read the reasoning separately from the answer; it remains available after reload and in conversation history. Long reasoning is bounded for display. No section is shown when readable reasoning is absent, and signatures, encrypted content, and internal protocol replay fields are never displayed.

Completed tool results and assistant replies remain part of the conversation when a later message has no new context selection or a tool grant is exhausted. New reads and actions still require authorization. History is summarized or trimmed when the context budget requires it; restoring an interrupted conversation preserves unknown action outcomes as unknown.

On macOS, List applications returns regular desktop app names and lifecycle-bound selection references. Select an app to read its windows and controls even while it is in the background. Listing does not inspect every app’s UI or activate an app. AI can use the same selection flow after read approval; actions require separate confirmation. Foreground changes preserve the selected application identity, but process restarts require a fresh selection; local policy changes still fence access. Apps may expose incomplete Accessibility data; an empty observation does not prove an app is closed.

Windows uses the same List applications and selection controls. The catalog groups visible top-level windows by process in the current interactive session and displays executable names. Selecting an application reads its windows and controls through UIA; selecting a window limits observation to that window. Enumeration and read limits mark incomplete results. Application references follow the process lifetime; closed windows cannot be accessed through old window references. Windows independent window screenshots use WGC and return a PNG of the selected window. Minimized, closed, changed, or password-bearing windows, and windows whose protection checks cannot finish, are rejected without falling back to a whole-screen capture. Screenshot authorization still applies. Background input has its own capability checks; application selection does not imply that background input is available.

Windows controls that expose UIA semantic scrolling show Scroll content in their observed actions. Semantic scrolling targets that control without activating its window: each axis accepts 0 (none), ±1 (small), or ±2 (large), with positive values moving right/down. At least one axis must be nonzero. Unsupported axes are rejected; there is no mouse-wheel fallback. Semantic and background scrolling require separate tool approvals; background scrolling retains its pixel units. Inspect the result after execution. macOS controls without semantic scroll support do not advertise this action.

Native UI requests have a bounded wait. Batches stop at the first error and distinguish definitely not started, partially dispatched, and unknown outcomes. Receipts count completed native dispatches; this does not verify application state. The collapsed tool card shows whether execution never started, earlier steps were dispatched, or the outcome is unknown. Requests that expire before starting are removed from the queue and reported as definitely not started. A timeout after execution starts does not prove cancellation or absence of effects: inspect the current UI and run result before choosing another operation, and do not replay the original operation automatically. New native UI requests are temporarily rejected while the original call is still running. Cancellation, an expired writer lease, or a local policy change prevents further UI mutations that have not yet been dispatched.

For ordinary desktop UI actions (invoke, select, focus, toggle, and set value), success confirms completion of the native Accessibility/UIA API call only. The host does not compare UI trees or read back attributes to judge the intended effect. The AI must inspect the UI separately after an action, decide its next step from that observation, and obtain the required authorization. Unknown execution outcomes such as timeouts or disconnections must never be blindly retried.

UI tools return model receipts containing object IDs and kinds; snapshot metadata and reference expiry remain on the server. Null fields and empty action lists are omitted. Controller observation panels and device wire payloads keep their full structure. For truncated results, the assistant should increase the bounded depth/node budget or inspect an exact window. Exhausted or naturally expired approved read permissions can be requested again, with a new owner decision; denied or revoked authority is not restored automatically.

UI inspection supports three scope values: content (default) reads ordinary UI, menus reads only menus for a follow-up search, and all reads both. For the macOS application menu bar, use an application root or the default foreground application; a window root only reads menus within that window. Scope selection does not replace read authorization or action confirmation.

Application, UI, process and service searches use top-level queries (up to 16 terms, each at most 128 UTF-8 bytes): case-insensitive substring matching with OR semantics, no regex or spelling correction. Services match names and display names before truncation; unmatched searches return an empty list. The old UI query object, exact name/native-ID/role selectors and service name are removed. Known controls can use top-level element_id or root_id with element_only=true. Unfiltered listings require explicit allow_unfiltered=true.

Both screenshot modes remain available: read_current_screen without window_id captures one whole display. inspect_desktop_session lists current display identifiers, names, dimensions and positions. Use the only display automatically without asking the user to select it; with multiple displays the AI first chooses a target, then requests screenshot permission and executes with the same display argument. Omitting display at execution only works when exactly one screen is attached. Multiple screens require an explicit choice; saved remote-desktop settings are not used as a fallback. A disconnected target fails instead of switching screens. Passing a window ID from owner_selectable_windows as window_id uses independent window capture on Windows/macOS, including when another window covers it, without activating it or requiring a selected display. Window and display targets cannot be combined. An invalid window fails explicitly and never falls back to full-display capture. Minimized windows without a fresh frame fail explicitly; restoring them still requires action authorization. Window selection never bypasses capture permission. When an image becomes text-only history, the system validates the original receipt and derives a new content binding with the same sensitivity, model authorization boundaries, and source lineage, so the next turn does not fail on stale size or digest metadata.

Model history auditing processes complete records within the content byte budget, without failing solely at 64 messages or 256 response sources. Every record still has its digest and model destination checked; source metadata has a separate byte limit. Capacity, integrity, and permission failures are reported separately. Loading tools preserves the current loaded set by default; the assistant can explicitly replace it when count or description budgets require it. Loading does not grant permission. describe_tools merges the current definitions by default; use replace: true to replace them when the existing description-byte budget is exceeded. Failed loads preserve the set, and goal continuations for the same user input retain loaded definitions.

Desktop UI action permission batches include desktop session and UI reads on the current device by default, excluding screenshots, so the assistant can check the result afterward. Included reads use the action request duration and allow up to 16 calls each. They are separately displayed and selected by default; the owner may shorten, narrow, or deny them. Existing narrower read requests are preserved. Native UI actions require an approved application scope and action set, bounded by expiry and remaining uses; exact target/action approval is no longer supported. Reads and actions can be revoked separately; every call still checks conversation authority, application ownership, and local capability.

Each model request provides tools covered by current conversation grants and refreshes their remaining uses and expiry. Approval makes the tool available without another load; exhausted, expired or revoked grants remove it unless another valid grant still covers it. Missing parameter details can be requested on demand, and application-scope approval does not require loading each action first. There is no fixed eight-tool slot limit. Only definition byte budgets trim optional tools, prioritizing the current approval continuation. Permission requests, task status, history and background task management retain their independent entries. Loading details grants no permission, executes nothing and never removes historical results or screenshots.

Conversation screenshots and context

AI Assistant screenshots are stored as separate conversation attachments. Reloading, reconnecting, and context compression do not delete them. The conversation lets you view full images, load more images, or delete an individual image. The stored image is the reviewed screenshot supplied to the model for that tool call; a new capture never substitutes for a historical image. Pixels discarded by earlier versions cannot be recovered.

Images enter model context only when needed. Text history retains the original tool-call reference; compression does not clean up attachments. The assistant can use read_conversation_attachment to retrieve an image using the attachment_id in its historical result. Retrieval checks the current model destination and applies image safety review again. Switching models does not automatically authorize exporting old images, and historical images neither restore expired UI references nor count as fresh screen observations.

OSS / Tauri stores image files in assistant-attachments/ under the local data directory, with metadata in SQLite. Manager stores metadata and binary images in shared PostgreSQL tables, accessible across instances. Conversation JSON contains no image pixels. Images retain the model input limit of 400,000 bytes each; a conversation has a 100 MiB attachment quota. Images, JSON and text share this quota; space is reclaimed from the least recently accessed attachments, retaining tombstones.

Attachments follow the conversation lifetime. Deleting an image or its conversation immediately prevents subsequent image reads; background cleanup removes files or binary data. Individual deletion tombstones remain until the conversation is deleted so replay cannot restore deleted images. Compression and permission expiry do not delete attachments. Existing conversation retention settings still apply.

To reduce context use, the assistant should prefer known element references or fuzzy queries across native identifiers, roles and names after its initial UI read. Permission proposals identify a tool name; the server derives its Provider and effect. Inactive grants are grouped by tool and state, while active exact action arguments remain available for verification. Permission expiry does not prematurely trim historical tool results.

When AI requests a conversation timer, only a pending review request is saved, not a task draft. The current turn waits for the owner decision while an inline approval card in the conversation shows the task and execution time with explicit Approve and enable / Reject actions, matching permission-request styling. No further model call runs during this wait. The server returns approval or rejection to the same turn before AI continues. Stop ends the wait without automatically approving the request. Approval creates the scheduled task. The card has no dismiss action: only an explicit approval or rejection submits a decision. Multiple requests can remain visible together. The card displays the result after server acknowledgement; a failed request remains visible for review and retry. Pending and rejected requests are excluded from task lists. No chat confirmation is needed. An enabled conversation timer survives ordinary follow-up chat, including “confirmed”; only an explicit pause or cancellation stops scheduling. When due, it waits for the conversation to become idle and executes the approved task text in the latest conversation context. Dispatch pins the current input revision, so new input during execution still fences the older turn. Permissions are rechecked without extending expiry or scope.

Relative requests such as “in five minutes” count from successful server activation after confirmation. The pending review retains and displays the delay without calculating an absolute execution time; activation stores an absolute UTC instant, displayed in the selected timezone. The activation receipt is preserved in the original conversation without creating new user input or granting tool permissions. Independent automations still require rehearsal, permission review and publication.

The assistant can query current-conversation tasks with list_scheduled_tasks, including server state, creation source, execution time and cancellation eligibility. It can cancel AI-created tasks with cancel_scheduled_task without another permission request or approval dialog. Manually created tasks are read-only to AI and must be cancelled by the user in task management; requesting permission cannot bypass this boundary. Origin is recorded by the server at creation; approving an AI proposal does not make it manual. Cancellation stops future scheduling and requests cancellation of any started occurrence, without undoing external effects.

After a service restart or interrupted execution, an expired execution lease no longer keeps the conversation marked as running. Refreshing the server snapshot clears a pending stop and allows a new conversation while retaining history. Background commands retain their independent lifecycle and are not cancelled by this recovery.

You can create or switch conversations while another runs in the background. The conversation list shows a spinner for active conversations and sorts running conversations first, then by most recent activity within each group. Deletion requires confirmation, with an additional warning for a running conversation. It removes history and images, stops further AI processing and cancels associated conversation timers. Background commands receive best-effort cancellation; stopping is not guaranteed and completed actions are not undone.

The composer stays at the bottom of the assistant page or remote desktop assistant panel. Messages scroll independently and follow new content by default. Scrolling up pauses following; use “Jump to latest message” or scroll to the bottom to resume. Switching conversations opens the latest messages.

“Scheduled tasks” to the right of session directories opens timers for the current conversation, including completed tasks. Only pending approval cards remain in the conversation area. Tap the context usage ring for details; composer buttons and the conversation list, resume timer, and new conversation header buttons hide their labels when space is limited.

On macOS, semantic UI actions relocate and validate the original process and element after approval. Human clicks, key presses, drags and scrolling preempt execution, while simply moving the pointer does not. Approval clicks do not erase semantic target identities. Coordinate snapshots and worker restarts retain their invalidation rules. When a native action fails or its effects are uncertain, the assistant receives its error and inspects the current application state. Other authorized writes remain available and no owner acknowledgement or record closure is required. Keep the original receipt and avoid blind duplicate execution.

Unresolved operation cards show the operation category, receipt uncertainty, and checking steps. Request and execution identifiers remain in collapsed troubleshooting details. The card states when no specific error reason is available.

Failed or unresolved actions show the original request reason associated with the grant actually reserved for that execution. The link uses server work and grant-use records, never timing or approximate input matching. A reason explains the intended operation, not its error cause, and grants no new authority.

Stable UI element identities

Each UI element's element_id equals its object_ref.token and identifies one native element within the controlled worker. Repeated reads, different searches, text/value updates, and grant expiry or renewal do not allocate a new ID. macOS compares retained AXUIElement objects; Windows uses process-lifetime RuntimeIds and retained UIA elements. Tree positions, labels, and coordinates are not element identity. Destroyed/recreated elements and restarted applications receive new identities; worker or desktop-session replacement invalidates the old IDs.

Desktop references follow native object lifetimes, with no fixed expiry. Re-reading an unchanged application or control preserves its ID and reuses its stored mapping. Objects destroyed or recreated, applications restarted, and worker/session replacement invalidate references; current native ownership and authorization are still checked before execution. Permission duration and uses follow the owner’s approval and are never shortened by a reference deadline. The bounded store reclaims invalid UI mappings when needed and rejects new allocations if capacity remains exhausted, preserving existing live IDs.

Conversation grants and native value types

Grants apply to the current conversation and approved scope. Ordinary follow-up messages such as “continue” do not themselves invalidate grants. New user input starts a new tool-detail focus; continuations within the same input retain the loaded set. Expiry, usage limits, revocation and exact action inputs still apply. When permission is missing, the assistant submits the approval card directly, batching operations whose inputs are already known instead of asking for another confirmation in chat.

On macOS, set_value preserves the native value type: text uses strings, numbers require finite decimals, and dates accept RFC3339 with an explicit offset, YYYY-MM-DD (preserving local time), or HH:MM[:SS] (preserving the local date). Reads expose dates with their time zone offset. Invalid formats and unsupported types return actionable errors before any write.

Application-scoped permission and control search

For multiple native UI steps, the assistant can request application-scoped permission in the current conversation. The review card shows the application name obtained from device observations and the permitted click, select, focus, toggle or fill actions. Owners can narrow actions, duration and uses. Every operation still checks conversation authority, the control’s actual application and process identity. Other applications, raw mouse/keyboard input and screenshots are outside this action permission; desktop reads appear as separate review items. Application restart requires fresh observation and approval; reference age does not shorten permission. Native UI actions exclusively use application-scoped approval.

Ordinary messages, permission continuations and conversation schedule resumes restore tools from effective database grants. A new message does not discard existing permission. An invalid permission batch creates no review card, including for otherwise valid items; the assistant receives the invalid item, required input structure and prerequisite-read guidance.

Native UI permission requests use application_scope exclusively; exact_input is rejected. Every execution requires the approved application_id, an observed element_id and action. Loading tool details does not create an approval request. The assistant may report a submitted card only after request_permissions returns a successful request_id with pending_user_decision.

The capability index and loaded details identify whether each permission request needs an application scope, complete exact tool input, or permits optional exact input. The assistant may omit suggested duration and use count; the server then proposes 300 seconds, the maximum use count for read-only device tools, three uses for screen capture, and one use for other tools. The owner can narrow the request, and the server still checks the actual scope and one-shot requirements before creating a review card.

When automatic approval has granted an application scope, plain button presses (invoke only) in that application run under the scope without another AI review. This reduces false denials, but a mistaken press inside the approved application is not stopped by a per-batch review. Other UI actions and background input are still reviewed per batch. After a tool is denied twice for one request, the assistant stops submitting it for review and asks you how to proceed or uses a different method; your next message resets the count.

Desktop UI tools expose IDs to the model: reads take optional root_id, semantic actions take application_id, element_id and action, application permission requests take application_scope.application_id, and window screenshots take window_id (omitting it captures a whole display, with automatic selection only when exactly one is attached). The model supplies neither snapshot IDs nor reference expiry. The server resolves full references from observations in the current conversation and continues to validate native lifetime, object kind, application ownership and authorization. A partial read never replaces references for other controls. Invalidated references explicitly require another read; unknown IDs neither trigger unfiltered searches nor request new permission automatically. Historical observations remain intact, and native object lifetime and permission validity are checked separately. Windows fallback input also uses application_id while retaining exact-input approval.

Tool calls appear in conversation order as collapsed records. Expand a record to inspect the tool name, input, and returned output (including errors). Live records update when results arrive, and saved records remain available when reopening the conversation or loading earlier messages. A saved result without a durable call-success marker is labeled "Result received" rather than implying an unverified operation or confirmed success. Explicit errors, missing results, and action outcomes that are genuinely unknown remain distinct. Only data retained by the server can be displayed.

A completed UI action batch means its steps were dispatched; the application state remains unverified until separately observed. An exact-send result separates a validated receipt (receipt_status=verified) from the business effect (business_effect=sent, not_sent, or unknown). Only sent confirms that sending was observed. A definitely-not-sent receipt is shown as a returned result rather than a successful send; an unknown outcome must not be blindly retried.

On Web, Android, and iOS, two or more thinking sections or tool calls between two non-empty assistant replies form a Work process group, collapsed by default. On Web, a group containing screenshots opens by default and screenshot cards show thumbnails; sibling tool calls and thinking sections remain collapsed and can be opened individually. Screenshots loaded asynchronously open their group, while subsequent updates preserve a manual collapse. A single item stays visible without an outer group. User messages break the group, and activity before the first or after the last assistant reply stays directly visible.

For new screenshots, Observation recorded shows when the server received that screenshot result, in the browser's local time zone. It does not establish the source's exact render time or current freshness. Historical screenshots without a valid timestamp show Time not recorded; refreshing does not fill in a time. Device-reported frame status and receipt age appear separately.

Device capability readiness reports remain valid for 60 seconds and refresh every 25 seconds. Diagnostic logs identify delayed/slow collection, reporting channel closure, invalid or expired reports, and missing fresh readiness at execution, without recording UI contents or tool payloads.

UI search guidance combines localized labels with English names, native identifiers and control types (at most 16 alternatives per batch), including date/time/input on a Chinese UI. A search miss does not establish that a feature is unsupported. When an entry button supports activation and the application grant permits it, the assistant should open it and inspect the resulting controls itself. It must verify the actual edited control and outcome, rather than treating a quick-entry field or existing event as proof of completion. Desktop references follow native object lifetimes; grant duration and uses are checked separately. Each model request includes current UTC time; device-local dates and timezones still require current device/application evidence or explicit user instructions, never inference from language or the server timezone.

macOS background mouse and keyboard (experimental)

Prefer semantic UI actions. When semantic UI cannot express the operation or observations and results show it is impractical or unreliable, combine background input with a current screenshot of the target application window. Obtain that screenshot with read_current_screen and window_id, refreshing it when needed. Do not default to background input when a suitable semantic UI action can accomplish the task.

send_background_input supports click, double click, scroll, Unicode text input or named key with modifiers to an observed application window. It accepts application/window IDs. Click/double-click accept either a control ID or original window screenshot pixel coordinates; scroll requires screenshot pixel coordinates (top-left origin; x < image width, y < image height). The server resolves PID, geometry and reference metadata. Mouse clicks currently use the primary button; dragging is not supported.

The permission card approves an application and action scope in the current conversation, with editable duration, use count and actions. Approved operations reuse that grant and include desktop/UI observation; screenshots require separate permission. Background input and semantic UI actions use separate tool grants. Existing device application access rules still apply.

Delivery does not activate the application, move the real cursor or fall back to foreground input. Keyboard input requires the requested window to be the application's keyboard input window. Minimized or ambiguous windows are rejected. Coordinate input needs a window screenshot and must refresh it after a resize; control-based input uses current control bounds. Human input in other foreground applications does not preempt background delivery. Stopping the conversation cancels subsequent events, but cannot retract events already sent.

A receipt confirms event dispatch, not application state. The AI should read the UI or screenshot afterward. Failures explain the cause and, after partial dispatch, the number of events sent; they do not require an owner outcome acknowledgement or block subsequent authorized actions. Mouse delivery probes a private macOS API at runtime; unavailable mouse support does not disable keyboard input. TextEdit was tested on macOS 15.6.1. Background Command+A did not work in that environment; other applications and OS versions may behave differently.

Batch UI and background input (trial)

The AI currently sees only execute_ui_actions (semantic UI) and send_background_input (background mouse/keyboard). Single-action entry points are hidden. Use steps with 1–20 entries, even for one action. Each batch targets one application; background batches also bind one window. The two action families are not mixed in a batch.

Existing application approval must cover every action kind. One batch consumes one grant use. A sealed batch holds one writer lease, executes sequentially and stops at the first error, without rollback or automatic retries. Existing 30-second dispatch deadlines and authorization/cancellation constraints still apply.

There is no fixed inter-step delay beyond native input event timing. Split asynchronous dependencies such as opening windows or changing layouts into separate batches with a UI/window screenshot read between them. Prefer semantic UI; use background input with a window screenshot only when semantic actions are impractical.

Success returns the completed count. An execution failure returns only the failing step number, its error and whether that step may have taken effect. Earlier steps completed native dispatch; later steps did not run. Whole-batch preflight failure explicitly reports that no steps ran. Original arguments remain in the folded tool record. Native dispatch does not verify the intended application state: the AI must read back. Errors need no user acknowledgement and do not block new authorized calls.

For macOS application tasks, first search running applications by localized and English names, then inspect controls using the returned application ID. If a complete application search finds no match, launch the app through an authorized mechanism and query again; do not repeatedly increase control search depth or equate a non-running app with an uninstalled app. An observed foreground reference already identifying the target app can be used directly. Application discovery still requires search conditions; request an unfiltered list explicitly only when necessary.

Application entries expose application_state: foreground, background, or hidden (which takes precedence). The field is omitted when unavailable. Application entries omit matched_queries; control searches retain match indices. This state does not indicate window minimization, occlusion, or visibility across desktop spaces.

Collapsed tool records show status icons: a green check for success, a cross for failure, and a spinner while running. A stopped conversation with no tool result shows a neutral unknown icon rather than an assumed outcome. Icons include accessible labels and hover descriptions.

Screenshot safety checks on macOS scan reachable Accessibility children independently of model UI response limits. The scan reads control subroles and child relationships without collecting text or adding a UI tree to model context. Protected controls block capture; an unreadable tree or a 10-second scan timeout reports an incomplete safety check instead of claiming a protected control was found.

For a macOS application screenshot, the assistant first searches the running application catalog, then queries the returned application ID with queries=["窗口", "window"] to discover windows, and passes the returned window ID to the screenshot tool. Application catalogs do not query windows: model results omit empty window lists and explicitly explain the next lookup.

Failed macOS screenshot safety scans log a scan ID, PID, scan scope, node position, role/subrole, AX status and timing. Failure-only probes report whether the attribute is advertised and the child-count API result. Logs exclude control titles, values and calendar text; diagnostic probes do not bypass protection or retry capture.

Window screenshots check the selected application and window rather than the unrelated foreground application. Full-display screenshots retain foreground checks. An AXChildren error -25200 on the host application menu bar or a native window title-bar button is logged and that branch is skipped; other controls remain scanned and other read failures still block capture.

Exact window screenshot approvals bind the observed window ID consistently before and after server reference resolution. Server-added reference metadata does not invalidate approval; another window, a different display selector, or full-display capture does not match that exact approval. Native object validity and current authorization remain checked at execution.

macOS screenshot scanning checks sensitive input controls rather than requiring optional subroles on ordinary groups or buttons. Hidden subtrees, minimized windows, and sensitive inputs with zero visible area or outside window/scroll clipping are ignored. Partially visible inputs remain checked, and missing visibility metadata does not imply invisibility. Background-window capture does not treat coverage by another application as hidden content.

After receiving a screenshot, the assistant may perform authorized targeting in the next model step without taking another screenshot. Screenshot and targeting in the same assistant batch remain blocked, and these rejections count toward the repeat limit. Window geometry remains available from stored screenshot receipts even after the image placeholder is appended.

UI search results include location.status. On macOS, controls with available geometry include visible bounds (x, y, width, height, in original window screenshot pixels, top-left origin) and their owning window reference. The coordinates use the same window space as background input. Hidden, outside-visible-area and unavailable locations are explicit; other adapters currently report unavailable. Match names, roles and location together. If a scroll area is ambiguous, use a current application screenshot to choose the intended region. After input, read back before claiming success; unchanged content calls for reconsidering the target, not repeatedly increasing scroll distance.

Screenshots appear inline immediately after their associated tool record and before the subsequent assistant reply. Earlier images whose messages are not loaded or have been compacted appear at the start of the transcript; loading earlier messages restores their inline placement. Image viewing, deletion and pagination remain available.

Background scrolling uses horizontal_pixels and vertical_pixels: these are pixel distances, not wheel ticks or lines. For example, vertical_pixels: -300 scrolls down 300 pixels, while -6 moves only six pixels. Message input remains in the composer until the server confirms acceptance. After 15 seconds without confirmation, use “Check and retry”; it checks stored messages first and resends the original message ID if still unconfirmed. Sending, acceptance and timeout diagnostics log identifiers only, never message text.

Background scroll requires an explicit position: {x,y} in the current original window screenshot; element_id is rejected for scroll (click/double-click still support it). Choose a point inside the intended content, avoiding sidebars, toolbars and dividers. A successful batch optionally includes last_scroll with the last dispatched pixel position and distances, without returning successful step history. This receipt does not verify content movement. Read UI or a screenshot afterward; unchanged content requires reconsidering the target before increasing distance, and repeated failure must be reported accurately.

Execution receipts omit the constant application_state_verified field. status describes native dispatch only; the assistant checks the intended outcome by reading UI or screenshots.

Desktop session/UI capability selections follow the desktop incarnation, independently of the readiness heartbeat deadline; reads still check current readiness and authorization. These selections travel as capability IDs, never as file/window attachment IDs. Expired explicit object selections require reselection or explicit removal. An intake rejection keeps the input and error visible across history refreshes and allows a corrected new send. Only an unconfirmed send reuses its original message ID and payload; its history lookup has a ten-second timeout.

AI tool inputs omit fixed schema_version fields, including nested communication drafts and browser references. The server supplies the declared protocol version on both permission and execution paths; exact command contents, shell, timeout and approval matching remain enforced. Load the target tool definition before requesting permission. Malformed exact inputs report the field path and constraint, required fields and a structural example; correct the format without requesting the user to invent it. Gmail draft attachments are optional, matching the typed protocol.

Manual semantic UI previews under observation and troubleshooting, including delayed previews, application listing and application selection, explicitly request bounded enumeration without requiring user-entered search terms. AI tools still require search conditions or an explicit opt-in to unfiltered results.

Under observation and troubleshooting, Desktop status shows the operating system and foreground application. Semantic UI previews list application or control names, types, values and supported actions, with a notice for truncated results. Raw results for both previews are available in collapsed Technical details. Viewing results does not authorize actions.

AI inspects controls before choosing background clicks and prefers supported semantic actions. Self-only UI reads cannot be combined with search queries; invalid calls return corrected examples. Truncated searches prompt a deeper or narrower read rather than a claim of unsupported UI. Batch receipts confirm dispatch; AI checks the actual result and continues corrections within approved scope.

Text updates and deletions still check authorization, target identity and the complete content version before execution, and save a backup first; backup failure prevents the mutation. A successful filesystem commit is not followed by a file readback. Later external writes or reference-registration failures do not reclassify the completed action as failed. Query the file again if a later operation needs a missing reference; do not repeat the successful update.

Backups made before text updates and deletions live in the controlled device’s private recovery store, linked to their conversation and operation. They no longer remain as long-lived hidden directories beside the original file and are not automatically added to AI context. The File backups entry in a file operation record lists that conversation’s backups and exports recovery packages. Device backup management lists records the current user may access.

The list shows the number of loaded backup records and indicates when more pages are available. This is not a device-wide total; access scope and pagination still apply.

Only the device owner may manage backups, and the device must be online. Retention, capacity and usage apply to the whole device. Insufficient capacity blocks new file changes without silently deleting unexpired backups. Shortening retention requires confirmation and recalculates expiry from each backup’s original creation time. Dates use the viewer’s time zone.

Conversation deletion also warns about removing its backups. Cleanup remains queued and retries while the device is offline or cleanup is incomplete; backup management shows its progress. Screenshots and file backups are managed separately. A recovery package contains the original text and saved metadata; exporting it does not overwrite the current file.

Each recovery package has two fixed filenames: before.txt contains the previous UTF-8 text and metadata.json contains descriptive metadata. Automatic restoration in place is not available in this phase.

Information	Saved and exported scope
Original text	Complete text before this operation; the current native tool limit is 64 KiB
Original path and filename	Manifest data only; never used to choose extraction destinations
Mode, user/group IDs and ACL	Numeric values and ACL text; export does not apply them to the current file or extracted files
Creation, access and modification times	Observed seconds and nanoseconds before the operation; extraction does not promise to restore these times
Extended attributes and resource fork	Binary values encoded as hexadecimal in the manifest, included in metadata capacity accounting; not exported as extra executable files

Serialized metadata is limited to 256 KiB. Failure to read or save required metadata, or exceeding size or capacity limits, blocks the file change. The exported text copy does not recreate the original inode, permissions or all filesystem behavior.

Backups with an unknown operation result remain exportable and count toward capacity; ordinary expiry does not delete them. Choose Discard backup in the Web, iOS or Android backup list and confirm to remove that saved version. This does not change the current file or the recorded result. Unsettled operations cannot be discarded, and temporary files whose identity cannot be verified are retained with cleanup shown as pending.

Unexpected device time changes pause backup cleanup. Correct the device system time and refresh backup management. If cleanup remains paused, choose Confirm device time and verify the time reported in the dialog before resuming automatic cleanup. Expired backups may then be cleaned; original timestamps and operation results remain unchanged. Refresh before confirming if the displayed time is over a minute old or the device time changes again.

Conversation attachments and model changes

The assistant preserves completed tool calls and results. Ordinary tool history does not expire with time. Operation references and execution grants retain their own deadlines: a historical result is not a new action authorization. A compatible model on the same gateway can continue the conversation. Incompatible images or insufficient context capacity produce an explicit error instead of silently removing history. Explicit context compression produces a summary.

Bodies over 4 KiB are stored as conversation attachments. The model receives references and reading instructions, without partial previews. JSON must remain valid and fit within 32 KiB; larger results fail explicitly and require supported source filters or ranges. Never repeat an already executed action merely to obtain a smaller result. Text attachments retain up to 400,000 bytes at a UTF-8 boundary, with original size and truncation metadata. Command stdout and stderr are separate text bodies; PTY output is combined.

Attachment buttons in the conversation header and beside tool results offer filtering, pagination, explicit viewing, downloading, deletion and batch deletion. Listing metadata does not read bodies. Viewing and downloading update last access. Images, JSON and text share a 100 MiB conversation quota. When space is needed, the least recently accessed attachments are evicted; historical references retain the reason content is missing.

The model reads with read_conversation_attachment. Text supports line ranges and literal OR keyword searches with context lines. JSON supports sequential pages without keyword search. Page bodies are limited to 32 KiB and the model's remaining context budget. A read body becomes a short receipt only after successful model consumption and normal turn completion; errors, cancellation and approval waits do not release it early. Only the latest image retains active pixels; historical images are read from attachments as needed.

Troubleshooting incomplete responses

An output-token-limit error means the provider explicitly reported length or max_tokens. Check the output budget in model settings and gateway limits; the model's advertised maximum is not the request budget. Malformed responses or abnormal completion statuses are reported separately and their tool calls are never executed. Server model-call logs include the completion reason, actual request output limit and token usage. Missing reasons appear as missing, unknown values as unrecognized; response bodies and credentials are not logged.

Screen IDs returned by desktop inspection are opaque references. When selecting a display explicitly, copy its ID unchanged into the exact screenshot permission and execution; a single attached display may be selected automatically. Native OS display names are resolved on the device. A denied request is a refusal, not a delayed approval. A mismatched exact input must be corrected to the current approved arguments; stale window references require fresh inspection and authorization for the replacement target.

On Windows, a one-shot display screenshot retries the same authorized display once using GDI when DXGI reports a removed GPU device. Permission errors do not trigger this fallback; window capture and saved desktop-streaming settings are unaffected.

Screenshot safety uses a separate native accessibility scan rather than the bounded UI results sent to the model. On Windows, both display and window capture inspect protection and visibility metadata, including WebView descendants, without reading text or values. Visible password controls block capture; traversal or property failures report an incomplete safety check and remain blocked, rather than claiming protected content was detected.

Launch diagnostics and service queries

Application receipts distinguish authorization, target resolution, environment preparation, helper startup and native application creation. They preserve the OS error domain, code and readable message when available. On Windows, ordinary launches that require elevation fail directly; administrator launches require an already usable elevated user token. The tool never requests UAC or uses SYSTEM. Native OS refusal is not an owner-approval denial. A disconnected submission or unconfirmed result remains unknown: inspect actual state before attempting another launch.

Failed commands retain captured, redacted output: separate stdout/stderr or combined PTY output. Receipts report whether execution started, a nullable exit code, signal information and stage-specific diagnostics. Missing exit evidence is never fabricated as exit zero. Nonzero exit, timeout, cancellation, output-read failure and process-tree cleanup failure remain distinct. Large output continues to use conversation attachments; attachment storage failure does not rerun the command.

read_service_status combines name keywords with platform-native filters: Windows start_types (such as auto, manual, disabled); Linux unit_file_states (such as enabled, static, masked) and scope=system/user/all; macOS launch_policies (such as run_at_load, keep_alive, scheduled). Values within an array are OR alternatives; names and type filters combine with AND. Omitting types selects all types. With no search conditions, explicitly set allow_unfiltered=true. Linux disabled does not prohibit starting a unit; macOS policies marked disk describe configuration, not verified effective runtime policy.

Pagination counts matching results, defaulting to 50 entries and allowing up to 200, with a 32 KiB JSON page limit. Continue with unchanged filters and next_cursor; normal empty pages never have a continuation cursor. complete=false and errors report incomplete queries or unavailable inspected metadata, not absence. Changed candidates or scope invalidate the cursor and require restarting the query. Pages are live observations, not an atomic snapshot. Queries never change service configuration.

Output token settings

Ordinary input and its subagents have no additional cumulative token ceiling; usage is still recorded. Planning uses the pinned model's runtime output limit. Call counts, deadlines, permissions and context size bounds still apply. Goals keep their explicit finite budget or disabled-token-budget setting; scheduled runs use their frozen finite contract. A source group's allowance is frozen at creation, while goals continue applying the current policy at their existing checkpoints.

Settings / Context management exposes summary maximum output tokens (default 16384). Settings / Terminal completion exposes completion maximum output tokens (default 512). Each call uses the smaller of its positive purpose limit and the model runtime limit. Edits affect subsequent bindings or new requests. Window mode retains the summary value without generating summaries. These settings live in config.toml and survive a runtime database rebuild.

If the model truncates a summary, the conversation reports that the context summary output was truncated. Original history is retained and no incomplete checkpoint is committed. Increase summary maximum output tokens in Context management and check the AI model runtime output limit before continuing; reasoning may also consume output tokens. Other compression failures keep the general compression error, and model calls are not automatically retried.

AI approval can use historical attachment references and text pages already read. References do not automatically expand the original attachment. Released pages provide only their read receipts, and historical evidence does not restore expired control references or grant new action permissions.

Thinking replay, clearing and short references

Select an explicit reasoning contract in model settings. Standard OpenAI Chat Completions omits reasoning_content; DeepSeek retains complete thinking from retained turns, including final answers, and supports explicit low/high/max effort. Unknown compatible gateways use conservative replay, without model-name inference. Anthropic Messages retains original signed thinking, redacted-thinking, text and tool blocks unchanged.

Anthropic native thinking clearing is optional and disabled by default. Keep a positive number of recent thinking turns or all thinking. Requests send clear_thinking_20251015 through context_management with the beta header. Visual controls and advanced JSON edit the same options; cache settings and numeric budgets are preserved. Presets preserve your runtime output limit.

Enable prefix binding only when required by the provider. Actual system, tools and message prefixes are checked. Invalid completed thinking is omitted only in the sending view; original history stays intact. A protected tool chain that requires a changed prefix stops explicitly. Dynamic tools and runtime prompts cannot guarantee this binding. Known conflicts stop before a paid summary call.

The context ring shows the local request byte budget, rather than a provider-window percentage. Details separately show the latest main-assistant call's actual input tokens (including applicable cache reads/writes once), output reasoning tokens, wire bytes and native clearing receipt. Missing or untrusted counters remain unknown. Previous observations show their time/stale state and do not block new messages. Cleared tokens are never subtracted again from input usage or billing.

Desktop/UI and browser results use stable session-local IDs: s1 session, a1 application, w1 window, e1 element, o1 output, p1 page and b1 browser element. Models copy observed IDs. Complete native identity, snapshot, lifetime and browser origin remain checked by the server and worker. Unknown, wrong-kind or changed references reject actions and request a fresh observation. Main and child sessions have independent maps, removed with the session; IDs are never reused. Permission reuse, approval and attachment model views use the same aliases, while execution and audit keep full objects.

Native mobile assistant controls and approval

iOS and Android group main and child conversation actions under + beside the composer. Context, continuous work and automatic approval can appear together; narrow layouts and large text use icons with full accessibility labels. + → AI automatic approval uses a native switch shared by the root conversation. Empty conversations initialize first, without a successful-model-test prerequisite. Failed changes reload server state and offer retry if that state cannot be read.

Ordinary permission, directory and goal requests show AI review progress. Interactive commands and requests requiring revalidation retain owner controls. Permission history shows each item's decision source, outcome and reason. Administrators can use + → AI approval details to inspect their own actual input, returned readable reasoning and reply, parsed decision, recording state and timeline. Main entries include their own children; child entries show only that child. Missing, expired or cleaned recordings are stated explicitly, and administrators cannot inspect another user's records.

Context details separate the complete request budget and reserved costs, prepared request/context bytes, signed protocol adjustment, local estimation state and recent provider token observations. Missing observations remain unknown. The protocol adjustment is already included in prepared usage and is not added twice; the local history percentage is not a provider-window percentage.

AI approval details

Global administrators can inspect their own Assistant conversations at + → Permission history → Approval details. The view shows the actual readable provider input, returned reasoning and answer, parsed decision and processing stages. + → AI automatic approval → View this conversation’s AI approval records also includes failures before a model call and concrete-action reviews. Main conversations include their own subagents by default; a subagent opens its own records. Administrators cannot read other users’ individual approval results. Organization roles and device sharing do not grant access.

Model approval, committed grants and operation outcomes are separate facts. No execution ledger means no claim of execution success. Missing reasoning, interrupted output, disabled recording, storage failure, truncation, expiry and budget cleanup have distinct notices. Missing input is never reconstructed from the current conversation. Only provider-returned readable reasoning is displayed; signatures and encrypted blocks are excluded. Content loads in chunks and detail caches are cleared on close, account changes or authorization loss.

Recording failures do not change decisions, grants or execution, retry models or enlarge model context. An unexpected JSON reply to a streaming request can be inspected for diagnosis; it does not bypass the original stream and decision checks. API keys, headers, reasoning signatures, encrypted replay and image bodies are excluded.

Approval model settings include recording controls: enabled, 7 days, 256 MiB instance budget and 16 MiB per record by default. Global settings are written to [approval_trace] in the active config.toml; SQLite holds runtime records. Rebuilding runtime storage does not erase these settings. Desk-server-only installations use the actual approval center for details and statistics.

Tool identities and references

Identifiers in tool records locate specific objects. Keep the returned value and read or select the object again when its reference expires. A reference grants no action permission; subsequent actions require current authorization.

Automatic directory approval and tool results

With conversation AI approval enabled, request_directory proposals also go through the approval model. Main and child conversations share the root switch. Conversation directories show waiting for AI review, the decision source and reason. Administrators can inspect input, model responses and processing in their own conversation at + → Permission history → AI reviews. A denial or reviewer fault ends that proposal and returns the reason to the executing assistant. Manual directory selection remains owner consent; scheduled tasks retain their task contracts. Approval confirms only the exact directory identity; file reads, writes, deletion and model export require separate authorization.

Permission requests for new artifacts require their business inputs in exact_input: a text file needs file_name and content_utf8; an explicit empty string creates an empty file, while missing content is an error. A unique approved conversation directory needs no directory ID. Multiple unbound directories require a choice, which the server fixes before review. Workbook previews, formulas, report titles and message contents remain explicit business choices; hashes, object references and fixed metadata are supplied by the server. Complete missing prerequisites before requesting artifact permission.

File reads use contextual_exact_input: provide the necessary file, worksheet/cell or merge choices. A recorded source uses file_result_call_id and, when necessary, entry_name; its type is restored by the server. A complete, unpaged directory result with exactly one readable file needs no repeated filename. File reads may omit source selectors only when the current accepted user input already selected the required file or file set; available attachments and recent history are not implicit choices. Document conversion still requires a verified result source. Excel cell inspection defaults to 32 KiB of output and can request a smaller bound. Approval and execution use the same frozen directory, file selection and defaults; adding another directory does not redirect an approved operation.

For full-display screenshots, display is optional: execution automatically selects the only currently attached display. Multiple displays require inspection and selection; saved remote-desktop settings are not a choice. A scope permission request does not need concrete screenshot arguments. The approval model still evaluates the owner task and capture risk.

Application UI previews use ui_in_application with observed target and application IDs. A preview never executes an action. Model-facing file_result_call_id is the result selector returned by a tool; copy it unchanged. The server resolves the internal call identity and verifies original results, directory identity and expiry. Pagination and attachment externalization do not turn page text into file evidence. Parameter errors return correctable tool results; changed or expired error results still fail validation.

Per-item automatic decisions and context capacity

Automatic review handles the same permission request as owner review. A batch may contain approvals, model denials and system blocks. It commits once after every item finishes, and only approved items receive grants. Each item shows its source, outcome and reason. Provider, connection, timeout, output, configuration and budget failures are distinct from model risk judgments and do not cancel other approved items. Stop, new input, delegation revocation and an already committed owner decision take precedence over late reviews.

Completed command receipts with verifiable content remain historical evidence after their execution references expire; this never authorizes repeating the command. Expired UI, file or attachment references remain invalid for current actions, and current-target errors are returned before a permission request is submitted. Unrelated old grant expiry or revocation does not invalidate a new request. Later approval-model configuration changes do not revoke completed grants; their own scope, lifetime, usage and revocation still apply.

Legal 16 KiB owner input stays complete. Auxiliary history is selected within the configured approval context capacity, with omission counts included in review input. Current instructions and exact operations are never truncated. Required input above capacity is rejected before submission with advice to split actions or raise approval context capacity. Model tests are diagnostic; complete configuration allows actual reviews without a mandatory passed probe.

Compression and permission recovery

The history budget target after compression defaults to 50% and accepts 1–99. It is a local history byte-budget goal, not the provider token window. The system does not retain unnecessary old history to fill it or discard required results to lower it. Long tasks can compress again after new history is produced. The meter distinguishes the latest prepared request bytes, protocol encoding adjustment and estimates for subsequently added content.

Compression rebuilds only the model working window. Original conversations, approval records and reference mappings remain intact. Pending approval stays paused. Even when recovery needs compression, approved exact arguments and objects come from current durable authorization, without duplicate requests, refreshed expiry or replayed completed operations. Partial approvals, denials, revocations and expiry keep their real meaning. Unread results, running execution and unknown outcomes remain protected.

Correcting malformed approval output

When the reviewer finishes normally but returns malformed JSON, the server explains the format error and resends the same frozen candidate. The default is 1 additional attempt. The only output fields are verdict, reason_code, reason, and evidence_event_ids; malformed replies and reasoning are not replayed. A valid denial is final. Invalid evidence, truncation, timeouts, disconnections and unknown outcomes do not trigger format correction. Exhausting correction attempts produces a review fault.

Administrators configure Settings → Approval AI → Approval AI runtime settings. The active config.toml stores the policy in [approval_runtime], for example format_retry_count = 1. Rebuilding SQLite preserves this configuration. The value counts additional attempts; 0 disables correction. Changes apply to new reviews. Correction does not extend the original deadlines, and each send must pass the existing authorization and budget checks.

Approval details group input, reasoning, raw answers, usage and stages by attempt, keeping each answer separate. Only actual readable provider reasoning is shown. Model metrics count each physical call; approval rates count the final result once per request. Each call reserves and records token usage independently. OSS has no prices or accounting. Missing usage is conservatively settled with durable per-call reconciliation links.

Goal time limits and crash recovery

Cumulative active time and goal lifetime are unlimited by default and can be enabled independently on the goal budget page. Active time adds physical model, summary and review call durations; concurrent calls may contribute separately. Goal lifetime starts at creation and includes waiting and downtime. Disabling either limit preserves recorded usage and all other budgets, permissions and device-unavailability limits. A valid goal is no longer blocked after restart by an old delegation group’s two-hour deadline; each subagent retains its fixed deadline. A paused, blocked or user-waiting goal with no actual work shows Send in the composer; goal controls still allow resuming or cancelling it.