AI and privacy

Decide which AI features you are comfortable using, and on what terms. Each mode below states its own boundary: what stays on your machine, what leaves it, and who receives it.

Live document sync is separate

Signing in alone does not upload your vault. Sync is optional and off by default; you turn it on per vault from Settings → Account. When it is on, that vault's notes, charts, whiteboards, whiteboard images, note frontmatter, and folder structure are stored on Wrengle's sync service so your own computers stay the same, encrypted in transit and at rest. Wrengle can technically read them to operate the service. AI consent does not enable sync, and sync consent does not enable an AI request. Attachments outside whiteboards do not sync. Turning sync off keeps your local files and does not delete existing server copies. See Sync across your computers.

Two routes for generative AI

Generative AI runs one of two ways. A clean install starts assistant chat on Wrengle AI Fast behind its first-use disclosure; an upgrade preserves the saved explicit or Auto route. You can change it under Settings → Models → Provider.

Your own key. Prompts and bounded context go straight to the OpenAI or Anthropic provider you named, under your own key and that provider's terms. Wrengle is not in the path.

Wrengle AI. Prompts and replies transit Wrengle and OpenAI over an authenticated connection tied to your account. Bounded input is uploaded to Wrengle, forwarded to OpenAI, and the generated reply returns through Wrengle. Wrengle does not retain that content in the account ledger or application logs. It records what a request cost — the account, feature, tier and model, Wrengle and provider request IDs, reported input, cached-input, cache-write-input, output, and reasoning buckets, credits, price version, status, and time. OpenAI's own service handling, logging, and retention terms apply to the content it receives. Requests are paid for with prepaid credits and stop when the balance runs out; nothing renews on its own and there is no overage plan. Wrengle AI is text-only, runs OpenAI models, and never falls back to a key of your own or a different destination. Wrengle AI and credits publishes the exact tier mappings, rates, and deployment availability.

When OpenAI reports final usage, the dashboard labels its token buckets Provider reported. If that final block never arrives, the request's reserved ceiling becomes an Estimated charge and the dashboard says Token counts unavailable rather than showing zero tokens. The ledger stores neither the prompt nor the reply in either case; both still transit the managed route.

Where the rest of this page names "the OpenAI or Anthropic provider you configured", Wrengle AI is the alternative to it: the same content, the same bounds, reaching the model provider by way of Wrengle instead of directly. Auto routing never selects Wrengle AI. The clean-install Fast selection is a concrete saved route, not an Auto result, and existing saved choices are preserved.

Account identity and cookies

Signing in is optional, and it runs through Clerk. The website and these documentation pages are one wrengle.com origin, so sign-in works the same way everywhere on it and there is no separate documentation session to keep in sync. Clerk sets the authentication cookies it needs and contacts its own authentication services whenever that interface is enabled. Only the publishable key reaches your browser. Clerk secret keys, webhook secrets, and session tokens are never included in the website's public build.

The desktop app signs in through a separate public-client OAuth grant with S256 PKCE and no OAuth Client Secret. Its Clerk refresh token and cached account summary stay in the operating-system keychain; the JWT access token stays only in protected native-process memory and is reacquired after an app restart. Both are owned by Wrengle's native side rather than by the window you look at or by your vault. A JWT is signed, not encrypted, and can contain readable identity, client, and scope claims, so Wrengle treats the complete value as a secret: it is not handed to the renderer, written to logs, or included in telemetry. That bundle also caches the last verified name, email, and verification time so the app can show who you are while offline. It does not keep your avatar, and it may leave out the name or the email to fit a platform limit on item size. Development and release builds use separate, stable account slots.

Desktop sign-out removes that local bundle first, then sends the refresh token directly to Clerk for revocation. A successful revocation prevents future refreshes, but it cannot invalidate a JWT already issued by Clerk. Such a JWT can remain valid until it expires, for up to one day; the signed-out app no longer retains it, but a copy taken beforehand can retain that residual lifetime. If remote revocation cannot be confirmed, Wrengle remains signed out locally and reports the uncertainty.

Your account identity is never attached to privacy-minimized telemetry events. See Accounts and sign-in for sign-out, offline, and deletion behavior.

Local does not mean every mode is local

Call a workflow local only when it actually runs on your machine. A provider-backed mode can send prompt text, note context, generated content, or other request data to the provider you selected.

Automatic provider defaults

Dictation speech, voice analysis, and the built-in assistant can use Auto. Auto considers only connected credentials that Wrengle has successfully read from the operating-system keychain.

• Speech prefers the speech provider you connected or verified most recently, then checks OpenAI → Deepgram → ElevenLabs, and falls back to Local Whisper.
• Voice analysis and Assistant Auto prefer the AI provider you connected or verified most recently, then check OpenAI → Anthropic. With no usable key, they ask for provider setup and send nothing. They use that provider's catalog default model.

The catalog defaults are GPT-5.6 Luna for OpenAI and Claude Sonnet 5 for Anthropic. A model you saved explicitly stays selected, including models grouped as Previous in the picker. Automatic voice analysis, Assistant Auto, and a newly selected OpenAI route use GPT-5.6 Luna rather than GPT-4o mini. That can change provider cost, latency, and output behavior without changing the data boundary. You can see the resolved provider and model before any cloud meeting-report text leaves your machine.

Wrengle does not offer Claude Fable 5 in this release. Anthropic documents a mandatory 30-day retention requirement for that model, and its refusal responses need dedicated handling and disclosure. Fable and Mythos model IDs are blocked before a request goes out, including when one is present in an older saved setting.

Wrengle also does not infer privacy or compatibility from a provider's model-list response. Only reviewed catalog entries are offered as new choices. A different custom ID kept from an older setting is labeled unreviewed compatibility, and it does not inherit the catalog's guarantees. Provider logging, retention, billing, regional access, and account policies continue to apply to every cloud request.

Auto is a routing preference, not a new provider. The assistant panel and Dictation settings show the effective provider and model. Selecting a specific assistant or voice-analysis model stays sticky when your credentials change; selecting Auto again restores cloud-only automatic routing. An explicit cloud selection with an unavailable key reports the credential problem. It does not quietly switch providers or cross to Local, and it does not show an unrelated local-model download gate. Voice analysis has no local generative fallback.

Connected means the saved key was readable from the keychain, not that it has been validated. Startup does not contact the provider to check it, so an invalid, revoked, or quota-limited key can still fail when a request starts.

If Wrengle cannot read a routing-critical saved preference or credential-status snapshot, it does not show you a guessed Local or Off preference. Assistant and voice starts pause with a retryable settings error until both sides of the app load the same saved state.

Cloud voice features defaults on where you have set no preference, so connected, readable speech and AI keys can drive their separate automatic voice routes without a second setup step. Turn it off explicitly and that choice stays off: automatic speech resolves to Local Whisper, while automatic and explicit generative voice analysis are blocked until you restore access. This voice setting does not disable a separately selected or Auto-resolved cloud assistant.

Meeting behavior does not inherit these voice and assistant defaults. Meeting live captions stay local. Cloud meeting final-pass transcription is selected and consented to separately. The meeting report model follows its own Settings → Models selection. The separate Cloud meeting transcription setting also authorizes a cloud-routed Answer from notes request while you are recording, so turning it off blocks future cloud meeting audio and cancels recording-time cloud Answer from notes work.

Keychain credential access

Your provider credentials, account grants, connected-service tokens, configured-action secrets, plugin secrets, and Wrengle's own workflow secure items all live in the operating-system keychain. They are not in vault files, not in app settings, and not in persistent frontend storage. A non-secret catalog records which app-owned items are configured, so startup never probes arbitrary Keychain entries.

External coding-agent account credentials use the CLI's secure storage rather than Wrengle's ordinary provider-key cache. For a supported shared-auth route, Wrengle gives Assistant and Builder the same non-secret, app-scoped secure-store identity. The reviewed CLI reads and refreshes its own credential; Wrengle does not copy the token into an environment variable, ACP message, Builder scratch file, or generated plugin. The current Claude Code 0.70.0 Builder route reuses an existing Assistant or Builder sign-in; the Keychain discovery fix needs no additional login. If you have not signed in since moving to the app-scoped identity, complete one fresh Claude account sign-in from Assistant or Builder. A credential that exists only in your ordinary CLI home or an ambient API-key, ADC, or service-account environment is not imported into Builder. Gemini CLI and Codex are unsupported in Builder and remain Assistant-only.

Before the workspace opens, Wrengle reads every currently configured, allowlisted item through one serialized native lane. That covers chat and speech providers, the active build's optional account bundle, supported OAuth connections, configured actions, current installed-plugin aliases that already have a grant, Calendar policy state, and required workflow secure storage. It excludes removed or revoked plugins, orphaned credentials, and the opposite-environment or legacy account slots.

Successful values stay only in a session cache that Wrengle's native side owns and scrubs from memory when it is released. They are never handed to the part of the app that draws your screen, never written to app settings, and never written to logs or telemetry. Once startup seals that cache, ordinary features use it without reading the operating-system keychain again. That is why a Keychain change you make elsewhere while Wrengle is running shows up at the next launch or explicit reconnect, rather than as a surprise prompt in the middle of a meeting, dictation, workflow, or provider request.

Reading a key at startup is not the same as verifying it. That startup read makes no network request, performs no OAuth refresh and no account verification, starts no Calendar sync, workflow, action, agent, or plugin, and grants no side-effect permission. Those operations begin only after the workspace opens, and they keep their normal consent and approval steps.

A denied, locked, cancelled, or failed secure-item read puts startup in Limited mode, and your local vault and note work continues. A cleanly missing, invalid, unconfigured, disconnected, or revoked credential is handled by its own feature as disconnected or unavailable, and it does not make the whole startup Limited. Settings → Privacy & Data → Desktop access shows recovery actions without automatically repeating the Keychain read.

On macOS, each item Wrengle actually reads can raise its own dialog saying that Wrengle wants to use confidential information stored in com.wrengle.app. The password it asks for is your Mac login password. Allow approves that one access, and because Wrengle does not reread the item later in the session, that is enough for the current launch. Always Allow remembers access for the current app identity. Deny leaves the dependent capability unavailable. Wrengle Dev declares the separate com.wrengle.desktop.dev Tauri identifier, while its raw ad-hoc development executable can still receive a build-specific macOS code identity and prompt again after Always Allow. That app-identity separation does not clone non-account secrets: development and release use the same Wrengle Keychain records for provider keys, integration OAuth tokens, and internal workflow encryption material. A development Save, Replace, Remove, connect, or disconnect action can therefore change shared data. Do not modify production-connected credentials or grant every local process access to work around a prompt.

An explicit Save key, Replace, or Remove action for an AI or transcription provider, taken while Wrengle is focused, can show the item-specific macOS Keychain dialog. That lets you authorize the credential change you just asked for, including replacing an item created by a differently signed development build. Canceling or denying the dialog fails closed: Wrengle does not report a successful change, and it evicts or revokes the affected session authority. Ordinary feature use, background token rotation, and automatic cleanup stay prompt-free. Broker-managed credentials write a non-secret fail-closed tombstone before replacement or deletion, so startup never brings back an old physical value after a failed change.

Checking where your audio and transcripts go

Settings → Privacy & Data carries a panel titled Where your audio and transcripts go. It answers one question for four routes, and it answers it from the route each feature would actually take — not from the preference you last picked, which can resolve somewhere else.

Each row reads either "Stays on this device" or "Sent to" followed by the provider's name. The report row reads "Not determined" until its cloud route has been resolved, and also for a retained retired route; Wrengle never guesses a row in the reassuring direction.

Shortened copies of the same panel sit beside the model pickers on the Meetings and Dictation pages, so the route is visible where you change it. Those copies are read-only — Privacy & Data is the only place the access switches themselves can be changed.

The panel is deliberately scoped to those four routes. AI chat and agents, Ask workspace, integrations, plugin network access, and usage data each have their own settings and their own section on this page. A row reading "Stays on this device" is a statement about that one route, not about the whole app.

Dictation and voice boundaries

Speech recognition and voice analysis are two separate choices under Settings → Dictation, and each one routes on its own.

• Speech. Local Whisper keeps your microphone audio on the device. OpenAI, Deepgram, and ElevenLabs cloud dictation stream microphone audio to the speech provider you chose, for as long as voice input is active.
• Analysis. Voice Control command interpretation and Light edit cleanup use the selected direct OpenAI/Anthropic route or Wrengle AI tier. On Wrengle AI, analysis text and replies transit Wrengle and OpenAI. For Voice Control commands, analysis can send the current transcribed utterance, active note title, up to 40 folder paths, and up to 15 recent note paths. Light edit instead sends the current utterance and up to four recent dictated sentences from the same voice session, all captured within one exact target: the note, assistant draft, Plugin Builder prompt, or chart text field. While one in-progress phrase and its exact target remain active, it may analyze provisional transcript snapshots that can later be superseded or cancelled, but no more often than once every 1.5 seconds; each request can use provider quota or billing, or Wrengle AI credits. Turning live preview off suppresses those during-speech calls; final cleanup still runs. The provider may revise those earlier sentences together with the current snapshot. Accepted corrections to earlier dictated sentences apply atomically as one undoable change, while the current unfinalized phrase remains grey ghost text until finalization. Light edit does not send that target's identity, microphone audio, or separately read or attach arbitrary typed text, the note body, or surrounding chart content; its payload is bounded to those dictated slots.

Verbatim Quick Dictation can stay fully local by using Local Whisper. Voice Control and Light edit require cloud analysis, so Local Whisper with either of those features still sends bounded transcribed text. A cloud speech route sends microphone audio to the speech provider; analysis, when used, separately sends bounded transcribed context to the configured AI provider.

Speech-provider keys are separate from AI-chat keys. Cloud speech and both automatic and explicit cloud analysis need Cloud voice features access in Settings → Privacy & Data, which defaults on when unset, while an explicit Off stays off. The billing, logging, and retention policies of the providers you selected can apply.

Personal vocabulary stays on the device for local speech. Deepgram and ElevenLabs cloud dictation receive capped key-term hints. OpenAI Realtime Whisper does not receive personal vocabulary in this release. Wrengle requests Deepgram's model-improvement opt-out, which can affect what that provider charges you. ElevenLabs uses the logging and retention behavior available to the connected account, and an ordinary bring-your-own-key setup does not claim enterprise Zero Retention Mode. Its current realtime keyterm guide allows up to 50 keyterms of at most 20 characters and lists an additional keyterm charge, and Wrengle sends only entries that fit that provider limit. Provider policies may still apply.

Quick Dictation with Verbatim cleanup bypasses analysis completely, and it needs only the speech route you selected. Voice Control still needs analysis for commands, and Light edit still needs it for cleanup. In a note, assistant draft, Plugin Builder prompt, or chart text field, accepted corrections to up to four recent dictated sentences are applied atomically as their own undoable change. The current unfinalized phrase remains grey ghost text until finalization and is not part of that undo step yet.

Voice performance marks are capped current-session stage and timing values for capture readiness, first transcript, and speech-end-to-final latency. They exclude audio, transcript or utterance text, note paths, note titles, provider hosts, and keys. Provider requests are separate from telemetry. See Dictation and voice control for the full local and cloud requirements matrix, recognition-language choices, and current control-phrase limitations.

Automatic workflow runs follow the same provider boundary. Stop asks the identified backend run to cancel, while Hide closes only its local detail view. Cancellation is checked at safe points, so a provider or model request, a read-only fetch, or a generated-note write that already started may still finish. Use cloud-backed workflow steps only when you are comfortable with that provider receiving the request context the run needs.

Workflow connection privacy

The Action picker reads your local action registry so it can show action names and descriptions instead of raw IDs. Startup may already have loaded an existing Gmail token pair into the native session cache, but opening Workflows or the picker performs no Keychain read and no provider request. Check Gmail reads only the native readiness state. Connect Gmail starts a new, explicit OAuth flow. The frontend keeps only non-secret ready or action-required status in memory and drops it when Gmail is connected or disconnected, and the provider tokens themselves stay in native memory and in the operating-system keychain.

Gmail readiness does not authorize a workflow side effect. Gmail → Create draft is manual and approval-gated: the Action step configures the recipient and the subject, takes its exact body from upstream output, and shows you all three before you approve. Wrengle stores the encrypted prepared intent before it contacts Google. Rejecting, cancelling, or letting the 24-hour approval expire makes no Gmail request at all. Approving creates a draft only, and it never sends mail. Gmail is currently reached through the Dry run path, so upstream AI or Fetch content is simulated — but approving the exact draft you were shown is a real change in your Gmail account.

Wrengle keeps a private app-data workflow.db as the durable record behind those effects. The Workflows builder stays the only place you author them, and for a Gmail action it freezes the exact prepared batch into that record rather than opening a second workflow editor or a general history dashboard. A waiting approval can be reopened after a restart when the same vault is open. Prepared payloads can stay encrypted for seven days.

That encrypted payload is the full snapshot needed to reconstruct your consent. It holds the workflow definition and configuration, the objective, accumulated artifact bodies, structured output paths, manager review and audit state, and the exact Gmail request. Only the Gmail bridge's plaintext metadata, opaque keyed request bindings, and receipts are content-safe, and those can stay for 90 days; they do not contain the recipient, the subject, the body, artifacts, or note paths. Editable recipient and subject values stay in ordinary local workflow settings until you edit or delete the workflow. Legacy preview-authored definitions and revisions can contain plaintext names, descriptions, and action configuration, and they can stay until you run an explicit app-data cleanup or uninstall — the seven-day encrypted-payload rule does not govern them. Provider tokens stay in the operating-system keychain.

Workflow automation data boundaries

For each AI step, the resolved direct OpenAI/Anthropic model or selected Wrengle AI tier receives the workflow Goal, that step's instructions, and its upstream artifacts. On a managed tier that content transits Wrengle and OpenAI. A scheduled run uses the Goal from the automation's pinned live workflow version, not from later draft edits. Legacy retired-provider nodes remain visible as repair-required and cannot execute until you reconfigure them.

Workflow drafts, automation triggers, and pinned live snapshots are stored in local app settings rather than as documents in your vault. Fetch stays read-only and HTTPS-only, with Wrengle's network safety checks. Write note stays limited to allowed vault roots and to the managed output region.

Action, Terminal, and Coding agent steps remain ineligible for unattended automation. That includes Gmail drafts: they need a manual, exact-preview approval, and they cannot run on a schedule.

The scheduler starts only after the startup access check settles. It runs only while Wrengle and the automation's matching vault are open. A credential blocked in Limited mode stops the dependent run before any provider or action work begins. A manual Run is tied to the vault that was open when it started. Wrengle rechecks these bindings at unattended step boundaries, and again as one indivisible step when it writes a generated note, so switching vaults cannot redirect an unattended write.

Within one running app, Wrengle allows only one user-started foreground workflow execution per open vault, across manual Run and automation Run now. Reopening the Workflows view reconnects to either kind and resumes its compact status checks. Manual Run, Run now, and scheduled executions share one fixed 30-minute limit.

Run now shows in-progress and full terminal detail straight away in the workflow view. A scheduled launch instead exposes a capped latest-execution summary covering queued, running, and terminal state. Full runtime snapshots and artifacts are current-session state for an ordinary workflow, and one latest-run summary persists. There is still no general durable execution history and no general automatic retry. Gmail's waiting approval, its seven-day encrypted recovery snapshot and exact requests, and its 90-day content-safe receipt metadata are the one narrow durable exception.

Stopping a run, a timeout, or an app interruption does not undo work already in flight. An interrupted run can finish already-started provider or note work, and its cleanup and overlap lock stays held until that work drains. For a user-started unattended run, compact status releases that lock as soon as cleanup finishes, even while best-effort terminal detail is still loading. Hiding a run, pausing, or deleting does not cancel work Wrengle already claimed.

Current releases write that persisted summary with content-free outcome categories — including timeout and interruption — rather than provider response bodies, prompts, URLs, note paths, or raw filesystem errors. At the next app launch, an unknown error string in a recognized record written by an older release is replaced with a generic category before display, and the sanitized value is rewritten in the local settings file. Unknown or future raw records are left alone. If the app is interrupted before an attempt tied to a due occurrence reaches a terminal state, that occurrence can stay eligible for a capped catch-up, which restarts the workflow and may repeat side effects that completed before the interruption. See Workflows for the complete lifecycle and its limitations.

Preparing a report during a recording

After Stop is the default on a clean install. Report preparation: Auto is an opt-in path that can update one capped six-field report in memory from completed, final-quality transcript chunks while an Automatic meeting is still recording. It is an advisory speed path, not a live-notes feature and not a recovery feature. Wrengle never accepts a route from model output. The state, the source frontier, the revision, the schema, and the route binding all belong to the app, and Wrengle never accepts any of them from model output either.

Separately, committed local captions feed a conservative Live draft straight away with no provider request, and later refinement corrects the same caption's contribution. The default-on local final-transcript preparation also authorizes no report work and no network work, and it continues when report generation is Manual or preparation is After Stop. Both the extractive preview and any validated Live AI draft are capped, read-only, memory-only, and subject to change. They stay available through Stop, and a UI reload can reattach while the active desktop process still holds the meeting session. They clear at a terminal outcome or a desktop restart. Preview content is never written to recovery, to another file on disk, to logs, or to telemetry.

To close the brief reload race after transcript cleanup, the capped final-transcript display state can stay in memory for up to 30 seconds. It is available only to the exact vault session that produced it, and it clears on a vault switch, on expiry, or on a desktop restart. It is not added to logs or telemetry.

The worker sends provider calls one at a time, folds in newer source events, and enforces caps on source, prompt, response, state, fields, and list sizes. Only OpenAI and Anthropic report routes execute. Retained local report routes remain inert until you explicitly choose a cloud provider.

An eligible cloud route can receive completed transcript excerpts and meeting-title prompt context in several requests during capture. Each request can incur provider usage, billing, logging, and retention even if its result is later discarded. No meeting audio is sent through the report path.

Wrengle writes a content-free provider-exposure claim to .app/live/ before each cloud preparation request is sent, tied to the exact route and destination, and records when that request settles. No prepared report content is written there. If an interruption makes completion ambiguous, Wrengle stops automatic provider work and shows Manual retry required instead of quietly repeating the request. An explicit retry re-resolves the current route.

At Stop, a detached tail task gives preparation a bounded tail drain window while transcript persistence proceeds on its own, and report generation waits for the tail decision. A physical Stop closes ordinary rolling requests. A request that started before Stop may still settle. If complete final coverage is still missing, the provider was prewarmed, and the whole remaining span fits one update, the worker may then start at most one full six-field tail.

Wrengle accepts that state only if it covers the complete final transcript and the route, the destination, the note target, the schema, and the revision all still match. A gap, a cap violation, a cancellation, or a mismatch before that tail starts sends Wrengle to the saved-transcript path instead. Once a tail starts, Wrengle sends no second automatic request, and an ambiguous exposure or a later note-context change needs your manual review and retry.

The saved-transcript path covers the complete transcript. A transcript of 32,000 characters or less uses one OpenAI or Anthropic call. A longer transcript uses one call for each contiguous transcript shard followed by hierarchical reduction calls. Deterministic decisions, action items, and open questions are checkpointed and combined across every shard, while narrative fields are reduced hierarchically. User-owned note context is complete through 8,000 characters; above that cap, the user-owned note uses a five-window Condensed representation. After Stop makes no report-provider request during capture.

The short one-call path can request up to 16,384 completion tokens, has a 32,000-character response cap, and can run for up to 60 seconds; collection stops when the strict six-field contract closes. Every shard and reduction call on the long path has its own 60-second deadline, 3,000-output-token cap, and 12,000-response-character cap. Bounded note and title/prompt context can accompany every call, so aggregate runtime, transmitted context, provider logging or retention exposure, usage, and billing scale with the call count. The per-call deadline is not an action-wide limit. Rolling and Stop-tail budgets are unchanged. Every explicit report retry is another potentially billable attempt and can make another sequence of calls; Wrengle does not automatically repeat an ambiguous, timed-out, rate-limited, incomplete, invalid, or failed request. After the 30-second in-memory transcript display and any already attached bounded reconnect lease expire, the complete transcript remains in the saved meeting note.

Context sent to AI

The composer permission preset is two controls presented as one intent. The Wrengle approval layer governs permission requests and terminal proposals that pass through Wrengle. An external agent's session mode is owned by that agent. Wrengle changes both only for exact reviewed package/version and mode-ID mappings; untrusted agent display labels never grant semantic authority.

Auto approve can persist Full Auto as the durable host ceiling after confirmation. Full access additionally selects the reviewed agent's permission-bypass mode after a separate one-time warning. Wrengle reconnects before raising a live session and blocks prompts while the transition is in flight. In Assistant and Inline Assist these controls do not reduce the ambient file, command, process, or network authority of an external subprocess, and Plan only is not an operating-system sandbox. Plugin Builder is the narrow exception described below: it uses a destination-owned scratch work profile and requires a separate process sandbox before launching an external agent.

An AI request may include your selected text, the current note, or other workspace context the command needs. Answer from notes ties both the retrieval and the provider response to the exact open-vault index session captured when the request begins. Closing or switching the vault cancels the step in flight and discards any response from the old session.

While a meeting recording is active, a cloud-routed Answer from notes request additionally requires Cloud meeting transcription, and it can send the capped retrieved note context and your question to the AI provider you selected. Turning that setting off cancels recording-time cloud Answer from notes work.

Plugin Builder has a separate destination boundary

Preview screenshots

Plugin Builder automatically shares screenshots of its visible plugin preview with the selected image-capable model or external coding agent for visual review during the active build and its repairs, without a separate approval prompt. The preview shows a notice about screenshot sharing. Screenshots include any note content, selected text, or saved plugin state displayed there. Sharing is scoped to the active build, workspace, and destination; changing the destination or workspace invalidates the associated sharing authority.

Wrengle captures the plugin area, not the whole desktop. It normalizes the image natively and keeps screenshot bytes out of saved Wrengle conversations, events, and generated plugin assets. Review findings and metadata are saved. The selected provider's retention terms and an external agent's own handling of tool results still apply. The preview must pass its readiness checks and remain visible in the active window before capture. Installation requires runtime checks and a current passing visual review.

Builder routing and permissions

Plugin Builder renders the same composer, Run with catalog, and four permission intents as Assistant, but does not borrow Assistant state. Its route, draft, one pending turn, conversation, permission intent, scratch workspace, and run lifecycle are destination-owned. Changing Builder's route or permission intent neither reroutes nor reconnects the active Assistant conversation.

Newly added or re-added coding agents remain fenced until you explicitly select them from a Run with picker. The acknowledgement is persisted. Selecting one in Builder does not reroute the Assistant panel; the two destinations remain separate.

The supported account identity is the narrow exception to that separation. For the current Claude Code 0.70.0 Builder route, an existing sign-in from Assistant or Builder supplies the app-scoped secure-store identity that both destinations reference. The reviewed runtime preserves native HOME for macOS Keychain discovery, while CLAUDE_CONFIG_DIR, workspace state, XDG directories, and temporary directories remain in Builder scratch. It does not copy the token or Assistant's configuration or session. Gemini CLI and Codex return a typed unsupported result in Builder and remain Assistant-only until their exact adapters can enforce the same credential and tool-isolation policy.

Unsent Builder drafts are cached separately per project for the current app session, including their text, local image File objects, exact note Resources, route, and permission intent. That cache is held in renderer memory only: it is not a saved conversation and is not sent to a provider until you submit the turn. Restarting Wrengle, switching vaults, or deleting the project clears the affected entries. Cached drafts and pending Builder turns share a 100 MiB image budget, in addition to the per-draft attachment limits.

Builder note access has two distinct scopes. Choosing a note from the composer's searchable @ picker creates an exact Resource grant for that path and submitted turn. The authority is bound to the open vault epoch and removed when its visible token or chip is removed. Typing a path, even an exact-looking one, grants nothing. The broader permission card is separate: approving it can allow list, search, and read operations for the rest of that Builder conversation in that vault. Auto approve and Full access may approve other eligible requests without another pause, but they do not create this broad grant or convert arbitrary text into Resource authority. Broad note operations under those intents require a grant previously approved through the host card in the same conversation and vault; otherwise they are refused.

Ask me pauses at protected actions. Auto approve can approve eligible reversible actions. Plan only removes Builder mutation capabilities. Full access may approve agent actions without asking inside the isolated Builder scratch workspace. Under every intent, the vault and managed-plugin roots stay contained, generated output is validated and previewed, and a human must still choose Add to workspace or Update before installed plugin code changes.

An external ACP Builder agent runs with the Builder work profile rather than the Assistant process boundary. Its scratch root and vault Resource root are separate, and Wrengle starts it only when the required process sandbox can be enforced. That sandbox is currently available on macOS; unsupported platforms fail closed before prompt admission and retain the editable draft. The macOS profile denies vault and Wrengle app-data reads in both launch phases. First, a short-lived host-owned npm preparation process uses scratch HOME and may write only Builder scratch and the selected Wrengle-owned adapter cache, with package lifecycle scripts disabled. It exits before Wrengle starts the verified long-lived adapter under a separate profile that denies writes outside scratch, including writes back to that cache. The profiles currently permit ambient reads elsewhere that the launched command could ordinarily perform, so they are not a general secrecy boundary for other user files. The agent may request execute, fetch, or network actions during generation according to its permission intent. Its upstream provider's logging, retention, and billing terms still apply. Generated and installed Builder plugins remain offline and cannot inherit that build-time network access.

Builder excludes ambient ANTHROPIC_API_KEY, Gemini and Google API keys, Application Default Credentials, service-account paths, OPENAI_API_KEY, and other provider credential variables. It also disables ACP filesystem callbacks and the coding agent's native file, shell, and web tools. The model receives only Wrengle's bounded Builder capabilities over authenticated MCP. Wrengle checks the exact pinned adapter version and executable and applies that adapter's reviewed host-enforced MCP-only options before sending the prompt. The upstream adapter does not provide a runtime policy acknowledgement. Missing credentials and an unknown or changed adapter fail closed, retain the editable submission without creating a generated draft, and require an explicit retry after the user fixes the problem. If authentication expires after work begins, Builder preserves the generated draft and visible progress for review. Wrengle never automatically replays either turn.

Builder accepts the same bounded PNG, JPEG, and WebP attachments as the other AI composers. On a compatible route, native admission sanitizes each image before it is sent as a model reference. Builder also stages a content-addressed normalized copy in the managed draft assets so generated code can refer to it without receiving the original renderer file or path. Image bytes are not written into the Builder conversation transcript. An incompatible route or preflight failure retains the complete editable draft. A queued Builder turn owns its File objects locally until admission; replacing or stopping that turn restores or retains the complete draft instead of silently dropping its images or note grants.

Inline Assist uses the existing assistant boundary

Inline Assist does not create a separate model route, conversation, or transcript. When you invoke it for selected note text, it uses the currently selected assistant backend and effective model, appends the turn to the active assistant conversation, and supplies the same current-note and selection context as the assistant panel. Current-note and selected text are each capped at 6,000 characters when needed; the structured note path and bounded block IDs remain part of the request context. Its compact editor prompt does not display or persist a private inline transcript; Open Assistant reveals the same ordinary conversation.

The data boundary therefore follows the backend already selected. OpenAI or Anthropic receives the prompt, current-note context, selected text, and the capped conversation context used by that built-in route. An external ACP agent receives the context supported by its session and can pass it to its own provider. The external process also retains its ambient operating-system file, command, process, and network permissions, which Inline Assist and Wrengle's edit preview do not sandbox.

For built-in OpenAI and Anthropic Inline Assist turns, native note tools disable vault listing and search and restrict reads and writes to exact structured current-note or Resource paths. Selected note text is untrusted model input: a path or instruction inside it does not expand that scope. External-agent subprocesses are different. Their ambient permissions are outside Wrengle's tool boundary, so Wrengle cannot prevent an external agent from acting on a prompt-injection instruction embedded in the selected text. Review untrusted or imported selections before sending them to an external agent.

The scoped Inline Assist exchange remains in the shared visible transcript, but that user/assistant pair is excluded from later built-in model history so an instruction planted in selected text or in the resulting reply cannot activate after ordinary note-read access returns. An external agent owns its opaque continuation and may retain that exchange; Wrengle cannot apply this built-in history exclusion inside the subprocess or its provider.

An edit proposal still passes through Wrengle's existing preview, approval, stale-base, and current-vault checks before any write. Rejecting a preview does not recall data already sent to a cloud provider or external agent. Cancelling the active Inline Assist turn stops later work where possible but cannot recall a request already dispatched.

Assistant image input accepts up to four static PNG, JPEG, or WebP images per turn: no more than 5 MiB each or 20 MiB together. Each side can be at most 8,192 pixels, with no more than 4,194,304 pixels per image or 16,777,216 pixels together. A single decoded native pixel buffer may use no more than 32 MiB. Wrengle processes one normalization at a time with a 64 MiB budget for the decoded source plus a full orientation or color-conversion frame. It fully decodes each accepted image, applies its stored orientation, and re-encodes it before dispatch. Opaque WebP input is normalized to JPEG and transparent WebP input to PNG, so opaque WebP pixels can change slightly. This removes embedded metadata such as EXIF and XMP, color profiles, and text fields, but the pixels themselves and anything visibly shown in them remain part of the image sent to the assistant. The attachment UI shows metadata cards instead of decoding or rendering those raw local pixels in the composer or transcript.

Anthropic applies an 8,000-pixel maximum to either image edge in its normal image-size regime. Wrengle caps each Anthropic request at 20 image blocks to stay in that regime. It preserves current-turn images, omits the oldest historical image bytes first when the cap or request budget requires it, and tells the model that an earlier image was omitted.

Wrengle preflights the initial Anthropic request against that provider's 32 MB body limit, accounting for base64 expansion, JSON escaping, prompt and history text, and provider/tool envelope room. It repeats that check before every later model call in a tool-using turn, including all accumulated tool results. If the current prompt remains too large, the request fails before dispatch. If tool results make a continuation too large, the turn stops before that continuation is sent to Anthropic. Request-only image omission does not immediately remove the original bytes from Wrengle's local live history.

The running desktop process separately allows no more than 64 images, 40 MiB of normalized encoded image data, or 33,554,432 decoded pixels across everything staged, in flight, or retained in live conversation histories. New attachments fail closed when any shared limit is full. Starting a new thread or closing live image conversations releases their retained bytes. Older image turns also leave memory when they fall outside the bounded live history: at most ten completed user/assistant pairs and 24,000 characters, with at most 20 MiB and 16,777,216 pixels of images in one conversation history.

An unsent native staging draft expires five minutes after its latest image is staged. Scheduled cleanup removes it even if the renderer reloads or its clear request fails, and later image operations also sweep expired drafts before claiming more process-wide residency.

Wrengle keeps normalized image bytes in local memory for the live session so compatible assistants can use them in follow-up turns. It saves only a safe format-and-dimensions descriptor and an Image not retained placeholder—no image bytes, filename, path, preview URL, or staging ID. Reopening a saved conversation or restarting Wrengle therefore requires you to attach the image again. Memory-only handling describes Wrengle's intended local storage; it is not a guarantee of secure erasure from operating-system memory, swap, or crash state.

The renderer applies the ordinary file limits before it stages an attachment, but desktop IPC carries that attachment to the native command as base64. The transport must receive and deserialize that string before native encoded-size validation can reject it, so the native limit is not a transport-layer memory cap. Temporary base64 and decoded buffers are minimized and released, but Wrengle cannot guarantee that their contents are securely erased from every copy made by the runtime or operating system.

Sending an image to a compatible OpenAI or Anthropic route gives the normalized bytes to that provider. Sending one to an external ACP agent gives the bytes to that process and any upstream provider it uses; a live or resumable external session may keep its own context. Those systems' logging, retention, and deletion policies remain separate from Wrengle's local storage. Cancelling a turn can stop later work where possible, but it cannot recall bytes already dispatched. A built-in cloud follow-up can send a live retained image again, and one tool-using turn can make multiple provider calls containing it. Each request can independently affect provider exposure, logging, retention, billing, and rate limits.

An image can contain instructions that are not obvious from its file metadata. While a built-in OpenAI or Anthropic conversation retains image context, Wrengle therefore fails closed on model-requested listing and searching, and on reading or editing unrelated notes. The provider can still use the exact note, selection, or resource context you explicitly attached to the prompt. A create-only write proposal can request your approval without first probing whether its path exists; the atomic write fails if it is not actually new. Attach the intended note before sending the image, or start a fresh conversation before allowing the assistant to explore other notes. This restriction does not turn an external agent into a sandbox; its ambient operating-system access and its own context handling still apply.

Built-in OpenAI or Anthropic conversations restore a capped tail of settled user and assistant text and send that capped history to the selected provider with your next request. Retired local-provider conversations remain readable and deletable but cannot be continued or replayed to cloud. Pending permissions, live tool state, and attached resource content are not restored as settled conversation history. Image descriptors return as placeholders, but their bytes do not.

Continuing an external ACP session depends on what that agent supports. Wrengle tries sessionCapabilities.resume first and top-level loadSession second. A successful continuation lets the external agent recover the context it owns. If continuation is unsupported or fails, Wrengle shows you the locally saved transcript with a clear transcript-only notice and starts a fresh agent session. It does not silently send that transcript to the new session.

In Assistant and Inline Assist, an HTTP MCP-capable external agent can call Wrengle's vault-scoped list_notes, read_note, read_note_blocks, search_notes, write_note, edit_blocks, and replace_selection tools. Listing, reads, and searches need no approval. Material creates, edits, and selection replacements pass through Wrengle's preview and approval flow, the editor's own serialization, stale-base conflict checks, and current-vault scoping. Without HTTP MCP, those surfaces stay limited to the scoped ACP filesystem callbacks Wrengle exposes. Plugin Builder uses a separate boundary: it disables ACP filesystem callbacks and exposes only Builder capability tools over authenticated HTTP MCP or a bounded stdio fallback.

For an edit_blocks conversion, the agent sends block IDs, a destination type, and optional heading or checklist state; Wrengle resolves each target's full text locally from one fresh note snapshot instead of requiring the agent to echo that text in the write operation. Note content the agent already read, or selection/current-note context you attached to the conversation, still follows the privacy rules of the selected local or cloud backend. Conversions that are already satisfied are checked locally and cause no preview, approval, or disk write. A real conversion remains approval-gated and uses the whole-note review, so its selected targets are accepted or rejected together.

Deleting a saved conversation removes Wrengle's local record only after the current vault authorizes the request. If local deletion cannot be confirmed, Wrengle reports the failure and keeps or restores the conversation rather than presenting a new thread as success. If a matching external ACP session is live and supports session/close, Wrengle asks for remote cleanup too and warns you when the agent does not acknowledge it. Wrengle cannot delete an inactive remote session, and it cannot override the external agent's provider, logging, or retention controls.

These boundaries cover Wrengle-mediated tools and callbacks only. An external agent program is not an operating-system sandbox. It keeps the ordinary file, command, process, and network permissions of the command you selected, and it can use them without a Wrengle approval prompt, including outside the open vault. Its provider, logging, retention, and billing policies stay separate from Wrengle's local storage model.

Wrengle downloads the approved agent's release-pinned npm distribution over the network into an app-owned cache, separate from your global npm cache. That cache contains executable and package files and may contain npm installation diagnostics; it is not used for Wrengle conversation transcripts or vault content. Choosing Repair and reconnect after a damaged-runtime failure quarantines only the affected cache generation, switches that preset and pinned version to a new empty generation, and starts one reconnect attempt. A live generation is never invalidated in place; the two newest quarantined generations are retained, and older generations are reclaimed only when no OS-backed live-session lease remains held. A later repair removes unlocked markers left by an app or system crash before reclaiming an older generation. The npm bootstrap uses app-owned configuration and fixed public-registry scope routes rather than npm configuration from the selected worktree or home directory. Wrengle verifies the installed package identity, then strips this bootstrap policy and restores the user's login PATH before the long-lived adapter starts; npm commands the agent later launches can use the user's ordinary project and home configuration. Repair does not sign out the agent, erase its ordinary home-directory configuration, delete provider-side history, or recall prompts and files already transmitted. Cache removal is ordinary filesystem deletion, not a secure-erasure guarantee.

Meeting report generation uses the route you configured: an OpenAI or Anthropic provider of your own, or Wrengle AI. Automatic mode starts one final report after the transcript is saved, and Manual mode waits for Generate report. That same action stays available for an idle saved report in Automatic mode, so cancelled or failed scheduling always has an explicit manual recovery path.

Stop records the automatic-report request it accepted before the first note write, so an initial save failure can resume after you retry or recover successfully and Wrengle revalidates the current policy. Provider input is tied to the exact saved note identity and is read through a held, identity-checked path. External deletion, recreation, replacement, or a parent-path swap makes the request or the managed-region write skip.

Provider preparation can be cancelled and is capped at 20 seconds. An edited report region is preserved for your review. Provider credentials come from the sealed native session cache, and an unavailable item stops the request before it starts, without a Keychain read and without an operating-system prompt.

Settings → Meetings → Reports → Cloud meeting report access discloses the exact resolved provider, effective model, and destination for a cloud meeting report route before report input is dispatched there. Selecting a cloud model is your consent to send the complete meeting transcript in bounded contiguous shards, bounded user-owned meeting-note text, and meeting title/prompt context to that provider. A long action can make multiple sequential provider calls for its shards and hierarchical reductions and repeat bounded note/title context. The route is explicit: an OpenAI or Anthropic provider of your own, or Wrengle AI. On Wrengle AI the whole report is reserved against your balance before its first call, so a report you cannot cover is refused with the figure it needed rather than stopping part-written. Model selection lives under Settings → Models. Report requests send text, not meeting audio; do not generate a report if this text must stay on your device. Changing the resolved provider, model, or destination cancels an in-flight request bound to the old route. A request that may have reached a provider is not replayed automatically on the old route or on a new one, and Manual retry required leaves that decision to you. A retry you can see uses the currently resolved route. The disclosure is read-only, and there is no separate authorize or revoke step.

Before a new post-Stop provider is prepared, Wrengle checks the existing report region locally for an edit conflict or malformed metadata. Check note and retry repeats that provider-free check after you review it. While the conflict or the malformed region remains, Wrengle preserves the note and does not make a new provider request.

Meeting report requests contain text, not meeting audio. Cloud final-pass transcription, cloud dictation, and other cloud speech features are separate audio boundaries with their own explicit consent and their own credentials. The meeting cloud-consent setting also covers recording-time cloud Answer from notes text requests, as described above.

Do not use an external agent or a hosted provider for sensitive material unless you are comfortable with that tool, command, or service receiving the context the request needs. For how to add and configure approved external agent presets such as Claude Code, Gemini CLI, and Codex, see AI agents.

Desktop app telemetry

The desktop app has a Share privacy-minimized usage data setting. It defaults on, and you can change it at any time under Settings → Privacy & Data. When it is on and configured, it uses a random identifier that lasts only as long as the app is running, and it can send only coarse event names and content-free metadata: the app version and operating system; whether a vault was opened or initialized; note-creation counts; closed integration and action kinds; coarse recording duration, source, model, save, and finalization outcomes; redacted error kinds; and meeting diagnostics. It never sends action IDs, vault or note paths, integration account details, notes, transcripts, audio, or prompts. Configured desktop releases also send minimized frontend errors to Sentry EU under this setting, including React failures, uncaught webview errors, and unhandled promise rejections, and failed native commands called through the generated desktop bindings, even when the app handles the failure. Reports retain reviewed technical messages and error codes, a closed error type, the static command name, coarse area, operating-system family, environment, and app release. Arbitrary error text stays redacted. Stack traces retain bundled app asset names, line and column numbers, and restricted function identifiers; private source maps can resolve these to application source code in Sentry. Local file paths, command arguments, note content, request details, and account information are excluded. Reports may include up to 20 content-free breadcrumbs such as opening settings or requesting recording start/stop; these are cleared when sharing is disabled. Repeated native command failures are limited to one per command/error category per minute, with at most ten native command reports per minute. This integration does not automatically collect native Rust crashes, background native events, third-party plugin errors outside the generated bindings, or every error message shown in the UI. Every desktop analytics event includes the app version, operating system, and fixed Wrengle source and schema labels so reliability can be compared across releases without identifying a person or retaining an installation identifier. Meeting-report diagnostics can include one closed, coarse failure category, such as key rejected, rate limited, model unavailable, incomplete, invalid, timeout, or oversized. They never include an HTTP status, provider response or detail text, model or endpoint, request/session/attempt identifier, route fingerprint, title, hash, input length, or precise request timing.

Website telemetry is separate. Unless you object, basic cookieless analytics sends page views and leaves from reviewed public marketing, legal, and documentation routes. It sends canonical paths without query strings or fragments, referring origin, and coarse browser, operating-system, and device details. It does not send page content, clicks, form activity, Web Vitals, campaign parameters, heatmaps, or replay, and it leaves no PostHog identity in browser storage. The SDK may briefly access and clear its own consent or legacy keys while establishing that no vendor state remains.

PostHog derives a daily server-side identifier for basic events from the project, hostname, connection IP address, user agent, and a daily-changing salt. The identifier is not stored in the browser and is not intended to recognize a visitor across days. The browser sends no session or window identifier. With Cookieless server hash mode enabled, PostHog assigns the cookieless visitor and Web Analytics session during ingestion.

The separate Enhanced analytics opt-in adds PostHog Web Analytics, Web Vitals, and strictly allowlisted structural interaction metadata only on the same reviewed public marketing, legal, and documentation routes. Authentication, sign-up, callback, account, dashboard, admin, API, error, unknown, and failed routes remain excluded. URLs stay canonical without query strings or fragments, referrers are origin-only, campaign identifiers are removed, nested Web Vitals retain only metric name, value, delta, and rating, and interactions retain only event type, element tag, and bounded sibling positions. Text, attributes, classes, IDs, selectors, link destinations, and custom augmentation are removed. It can still collect page views and leaves, coarse device and viewport details, session and performance measurements, approximate geography, and those structural interaction details. A pseudonymous identifier and standard PostHog session state may be stored only after enhanced opt-in. Person profiles, feature flags, heatmaps, dead-click capture, session replay, and PostHog exception capture remain disabled.

The bundled Web Vitals callbacks measure the hard navigation. Wrengle binds those metrics to the successfully rendered public route that loaded the document, even if they flush after an SPA transition. SPA routes do not claim earlier metrics, and loading an excluded route first makes that document ineligible for Web Vitals even after a later public-route navigation. Metrics generated by a back-forward-cache restore are rejected.

Both lanes emit page lifecycle events only after the router confirms a successful render, disable Beacon delivery, and use credential-omitting fetch. Both also include fixed Wrengle website source and schema labels and whether the event belongs to basic cookieless or enhanced analytics. These labels distinguish the website from other products in the analytics project; they contain no user content or identity.

Both lanes use the managed t.wrengle.com proxy and are processed in a PostHog EU project. Before public traffic is enabled, that project must have Cookieless server hash mode enabled, discard IP data, keep analytics events for no more than 12 months. Website diagnostics is a separate opt-in that sends minimized error events to Sentry EU; enabling analytics does not enable diagnostics, and enabling diagnostics does not enable PostHog. Diagnostics covers browser route failures, uncaught browser errors, and unhandled promise rejections after opt-in. Error messages and stack content are redacted; reports retain a closed error type, coarse area, environment, and release when configured. Server/API errors, session replay, and performance traces are not collected by this integration. Redacted stacks cannot be mapped back to source code in Sentry. Global Privacy Control, an affirmative Do Not Track signal, and Decline all keep every website telemetry lane off regardless of saved choices.

Use Privacy choices in the website footer to object to basic analytics or change either opt-in. Withdrawing an analytics lane blocks new PostHog capture and requests verified deletion of its browser state. If the browser blocks deletion, capture stays off. A later opt-in cannot start until the site can verify cleanup and preserve that fail-closed state; clearing the site’s browser data removes it manually. A saved change between basic and enhanced analytics reloads the page so their identities and SDK observers do not cross the boundary; the first view of that same canonical route is suppressed in either direction so the choice change does not double-count it. Withdrawing diagnostics shuts Sentry down. An event or error already handed to a provider client — including an in-flight or retrying request — can still finish delivery. Previous objections remain off. The current storage schema separates basic objection from enhanced analytics consent. Recognized legacy choices are migrated conservatively, and old PostHog identity keys are removed as part of that transition.

On a first browser visit to the retired app.wrengle.com origin, a no-store cleanup page removes the same origin-scoped identifiers and then redirects to the matching path and query on wrengle.com. It sets only a fixed one-year marker, so repeat visits can use the permanent redirect directly. An http://app.wrengle.com document bookmark first upgrades to HTTPS on that same retired host, because Web Storage belongs to the scheme as well as the host.

Temporary meeting recovery records are files inside your open vault under .app/live/, not telemetry. If that vault folder is included in configured filesystem sync or backup, those temporary files may be copied to that service or to another device while they exist.

They can include paged committed, refined, and final transcript text, selected meeting context, the exact note target, provider exposure state, a report attempt revision, and checkpointed long-report evidence. That evidence can contain derived summaries, decisions, action items, follow-up, discussion, and open questions, while the complete rendered report draft remains memory-only. Replaceable live partial captions remain memory-only. These vault files contain no raw meeting audio.

Raw meeting audio is stored separately as independently authenticated encrypted blocks in private operating-system app data, outside the vault and its Git/sync boundary. Indexes, blocks, reads, and deletion receipts are bound to the exact originating vault and recovery-directory identity, so a copied recovery row cannot read or delete another vault's timeline. Wrengle decrypts only bounded ranges. Successful canonical finalization removes the timeline; a failed or ambiguous finalization can retain it on that device for explicit recovery.

Content-free exposure claims are written before each cloud preparation request and marked complete after the request settles. A separate content-free active-owner lease stores a random owner identifier and timestamps, and it refreshes every 15 seconds through live and detached automatic report work. Orderly completion attempts release after a capped helper drain, without waiting indefinitely for lock contention or a stalled filesystem.

Its monotonic generation and operating-system file lock coordinate cooperating Wrengle processes only when they open the same underlying lock-capable filesystem object in one clock domain. If a prompt release cannot finish, the row becomes recoverable once that filesystem's clock sees the heartbeat as at least two minutes old. Ordinary synced replicas are separate, potentially stale objects, not a distributed lock, and independently clocked or future-skewed replicas fall outside that guarantee.

On Unix, Recovery discovery can re-attest a released lease when a remount changed only the device identifier of the same lock file. It does so under the current file's exclusive lock and advances the generation; it does not rebind the saved note target. Fresh owners, replaced lock files, malformed or unreadable ownership metadata remain fail-closed cases. Independent synced replicas remain outside the locking guarantee and must not be recovered concurrently.

Ordinary Markdown, chart projection, and editor-sidecar reads have a 16 MiB per-file cap, and app-owned meeting-note writes use the same cap and fail closed above it. Wrengle deletes these recovery records after a successful save or report, after recovery, after a discard, or after no-speech cleanup.

Meeting cloud transcription is separate: it sends audio only for the explicit final pass, after you have configured a provider and consented. Cloud dictation streams microphone audio while voice input is active, as described above.

Practical guidance

Auto uses a connected, readable cloud key whenever one is available. For sensitive material, select Local yourself, and for voice, turn off Cloud voice features when that fits the work. Use bring-your-own-key or hosted modes only when you are comfortable with the provider receiving the request data that workflow needs.