AI and privacy

Wrengle supports privacy-aware AI workflows by making mode, provider, context, and agent boundaries explicit.

Account identity and cookies

Wrengle uses Clerk for optional account identity. The website, including these documentation pages, is a single 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 essential authentication cookies and contacts its authentication services when that UI is enabled. Only the publishable key reaches the browser; Clerk secret keys, webhook secrets, and session tokens are never included in the website's public build.

The desktop uses a separate OAuth grant. Its access and refresh credentials stay in the operating-system keychain and are owned by the Rust process, not the renderer or vault. That bundle also caches the last verified name, email, and verification time for offline display; it does not persist the avatar and may omit name or email to fit a platform item-size limit. Development and release builds use separate stable account slots. Account identity is not 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

Only workflows that actually run on your machine should be described as local. Provider-backed modes can send prompt text, note context, generated content, or other request data to the selected provider.

Automatic provider defaults

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

• Speech prefers the most recently connected or successfully verified speech provider, then checks OpenAI → Deepgram → ElevenLabs before falling back to Local Whisper.
• Voice analysis and the assistant prefer the most recently connected or successfully verified AI provider, then check OpenAI → Anthropic before falling back to a selectable Wrengle Local model. A cloud route uses that provider's catalog default model.

The catalog defaults are GPT-5.6 Luna for OpenAI and Claude Sonnet 5 for Anthropic. An explicit saved model remains selected, including models grouped as Previous in the picker. Auto and blank Wrengle default OpenAI selections now resolve to GPT-5.6 Luna rather than GPT-4o mini, which can change provider cost, latency, and output behavior without changing the data boundary. The resolved provider and model remain visible before cloud meeting-report text is dispatched.

Wrengle does not offer Claude Fable 5 in this release because Anthropic documents a mandatory 30-day retention requirement for that model and its refusal responses need dedicated handling and disclosure. Fable and Mythos IDs are blocked at dispatch, including when present in an older saved setting. Wrengle also does not infer privacy or compatibility from a provider model-list response: only reviewed catalog entries are offered as new choices. A different custom ID retained from an older setting is labeled unreviewed compatibility and 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 effective provider and model are shown in Settings or the assistant panel. Selecting Local or a specific provider remains sticky when credentials change, and Reset returns that surface to Auto. An explicit cloud selection with an unavailable key reports the credential problem rather than silently crossing to Local or showing an unrelated local-model download gate.

Connected means the saved key was readable from the keychain; startup does not contact the provider to validate it. An invalid, revoked, or quota-limited key can therefore still fail when a request starts.

If Wrengle cannot read a routing-critical saved preference or credential-status snapshot, it does not display a guessed Local or Off preference. Assistant and voice starts pause with a retryable settings error until the renderer and native privacy route can load the same saved state.

Cloud voice features defaults on where no prior preference exists, so a connected, readable key can power automatic voice routing without a second setup step. If you explicitly turn it off, that choice remains off and automatic speech and analysis resolve locally; an explicit cloud voice route remains unavailable until access is restored. 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 remain local, cloud meeting final-pass transcription remains separately selected and consented, and the meeting report model continues to follow its own Settings → Models selection. The separate Cloud meeting transcription setting also authorizes a cloud-routed Answer from notes request while recording; turning it off blocks future cloud meeting audio and cancels recording-time cloud Answer from notes work.

Keychain credential access

Wrengle stores provider credentials, account grants, connected-service tokens, configured-action secrets, plugin secrets, and internal workflow secure items in the operating-system keychain, not in vault files, app settings, or persistent frontend storage. A non-secret catalog records which app-owned items are configured so startup does not probe arbitrary Keychain entries.

Before opening the workspace, Wrengle reads every currently configured, allowlisted item through one serialized native lane. This includes 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 remain only in a zeroizing, Rust-owned process-session cache. They are never returned to the React renderer, persisted in app settings, or written to logs or telemetry. Once startup seals the cache, ordinary features use it without reading the operating-system keychain again. That is why an external Keychain change made while Wrengle is running is observed at the next launch or explicit reconnect, not by a surprise prompt during a meeting, dictation, workflow, or provider request.

Startup access is not provider verification. The preflight makes no network request, performs no OAuth refresh or 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 retain their normal consent and approval boundaries. A denied, locked, cancelled, or failed secure-item read puts startup in Limited mode while 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; 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 actual item read can show its own dialog saying that Wrengle wants to use confidential information stored in com.wrengle.app. The password requested is your Mac login password. Allow approves that single access; because Wrengle does not reread the item later in the session, it is enough for the current launch. Always Allow remembers access for the current app identity. Deny leaves the dependent capability unavailable. A development rebuild can have a different ad-hoc identity and prompt again even after Always Allow; do not grant every local process access to work around it.

An explicit Save key, Replace, or Remove action for an AI or transcription provider, made while Wrengle is focused, can show the item-specific macOS Keychain dialog. This lets you authorize the credential change you just requested, 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 evicts or revokes affected session authority. Ordinary feature use, background token rotation, and automatic cleanup remain prompt-free. Broker-managed credentials persist a non-secret fail-closed tombstone before replacement or deletion, so startup never resurrects an old physical value after a failed mutation.

Dictation and voice boundaries

Dictation speech recognition and voice analysis are separate choices under Settings → Dictation:

• Local Whisper keeps microphone audio on the device. OpenAI, Deepgram, and ElevenLabs cloud dictation stream microphone audio to the selected speech provider while voice input is active.
• Local analysis keeps command interpretation and Light edit cleanup context on the device. Cloud analysis sends transcribed utterance text plus the active note title, up to 40 folder paths, up to 15 recent note paths, and—for cleanup—the previous dictated sentence. It does not send microphone audio or note bodies to the analysis provider.
• Speech-provider keys are separate from AI-chat keys. Both cloud voice choices require Cloud voice features access in Settings → Privacy & Data. It defaults on when unset, while an explicit Off remains sticky. The selected providers' billing, logging, and retention policies can apply.
• Personal vocabulary stays on the device for local speech. Deepgram and ElevenLabs cloud dictation receive bounded 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 provider pricing. ElevenLabs uses the logging and retention behavior available to the connected account; ordinary BYOK 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; Wrengle sends only entries that fit that provider limit. Provider policies may still apply.
• Quick Dictation with Verbatim cleanup bypasses analysis completely. It needs only the selected speech path. Voice Control still needs analysis for commands, and Light edit needs it for cleanup.

Voice performance marks are bounded current-session stage/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/cloud requirements matrix, recognition-language choices, and current control-phrase limitations.

Automatic workflow runs follow the same provider boundary. Stop requests cancellation of the identified backend run, while Hide closes only its local detail view. Cancellation is checked at safe boundaries, so an already-started provider/model request, read-only fetch, or generated-note write may still finish. Use cloud-backed workflow steps only when you are comfortable with that provider receiving the request context needed for the run.

Workflow connection privacy

The Action picker reads the local action registry so it can display action names and descriptions instead of raw IDs. Startup may already have loaded an existing Gmail token pair into the Rust session cache, but opening Workflows or the picker performs no Keychain read or 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/action-required status in memory and invalidates it when Gmail is connected or disconnected; provider tokens remain in native memory and 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 recipient and subject, takes its exact body from upstream output, and shows all three before approval. Wrengle persists the encrypted prepared intent before contacting Google. Rejecting, cancelling, or allowing the 24-hour approval to expire makes no Gmail request. Approval creates a draft only; it never sends mail. Gmail is currently reached through the Dry run path: upstream AI or Fetch content is simulated, but approving the exact displayed draft is a real Gmail mutation.

Wrengle keeps a private app-data workflow.db as a durable effect foundation. The existing Workflows builder remains the only authoring surface; for a Gmail action it freezes the exact prepared batch into that foundation rather than exposing a second workflow editor or general history dashboard. A waiting approval can be reopened after restart when the same vault is open. Prepared payloads can remain encrypted for seven days. The encrypted recovery payload is the complete runtime snapshot needed to reconstruct consent: workflow definition and configuration, objective, accumulated artifact bodies, structured output paths, manager review and audit state, and the exact Gmail request. Only the new Gmail bridge's plaintext metadata, opaque keyed request bindings, and receipts are content-safe and can remain for 90 days; those records do not contain recipient, subject, body, artifacts, or note paths. Editable recipient and subject values remain in normal 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 can remain until explicit app-data cleanup or uninstall; they are not governed by the seven-day encrypted-payload rule. Provider tokens stay in the operating-system keychain.

Workflow automation data boundaries

For each AI step, a cloud-backed model receives the workflow Goal, that step's instructions, and its upstream artifacts. A local model keeps those prompt inputs on-device. Scheduled runs use the Goal from the automation's pinned live workflow version, not later draft edits.

Workflow drafts, automation triggers, and pinned live snapshots are stored in local app settings rather than as vault documents. Fetch remains read-only and HTTPS-only with Wrengle's network safety checks. Write note remains constrained to allowed vault roots and the managed output region. Action, Terminal, and Coding agent steps remain ineligible for unattended automation. That includes Gmail drafts: they require a manual exact-preview approval and cannot run on a schedule.

The scheduler starts only after startup access preflight settles and works only while Wrengle and the automation's matching vault are open. A credential blocked in Limited mode prevents the dependent run before provider or action work begins. A manual Run is bound to the vault open when it starts. Wrengle checks these bindings again at unattended step boundaries and atomically when writing a generated note, so switching vaults cannot redirect an unattended write.

Within one app process, only one user-started foreground workflow execution per current vault is admitted across manual Run and automation Run now; reopening the Workflows view reconnects to either kind and resumes compact status checks. Manual Run, Run now, and scheduled executions share a fixed 30-minute limit.

Run now immediately exposes in-progress and full terminal detail in the current workflow UI; a scheduled launch's bounded latest-execution summary exposes queued, running, and terminal state. Full runtime snapshots and artifacts are current-session state for ordinary workflows, while one latest-run summary persists; there is still no general durable execution history or general automatic retry. Gmail's waiting approval, seven-day encrypted full recovery snapshot and exact requests, and 90-day content-safe receipt metadata are a narrow durable exception. A stopped, timed-out, or interrupted unattended run can finish already-started provider or note work, and its cleanup/overlap lock remains held until that work drains. For a user-started unattended run, compact status releases the lock as soon as cleanup is complete, even if best-effort terminal detail is still loading. Hiding run detail, pausing, or deleting does not cancel work the app has 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 preserved. An app interruption before an attempt tied to a due occurrence reaches terminal state can leave that occurrence eligible for bounded catch-up; that restarts the workflow and may repeat side effects completed before the interruption. See Workflows and automations for the complete lifecycle and limitations.

Preparing a report during a recording

After Stop is the clean-install default. 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 performance path, not a live-notes or recovery feature. The state, source frontier, revision, schema, and route binding are application-owned and are never accepted from model output.

Separately, committed local captions feed a conservative Live draft immediately with no provider request, and later refinement corrects the same caption's contribution. The default-on local final-transcript preparation also does not authorize report or network work and continues when report generation is Manual or preparation is After Stop. Both the extractive preview and any validated Live AI draft are bounded, read-only, process-memory-only, and may change. They remain available through Stop and a UI reload while the active desktop process retains the meeting session, but are cleared at a terminal outcome or desktop restart. Preview content is never written to recovery, another disk file, logs, or telemetry.

To close the brief reload race after transcript cleanup, the bounded canonical final transcript display state can remain in process memory for up to 30 seconds. It is available only to the exact open-vault epoch and clears on vault switch, expiry, or desktop restart; it is not added to logs or telemetry.

The worker serializes provider calls, coalesces newer source events, and enforces caps on source, prompt, response, state, fields, and list sizes. Current local report backends wait until after Stop when they cannot prove that cancelled generation has quiesced before local transcription resumes. Eligible cloud preparation can send completed transcript excerpts and meeting-title prompt context in several requests. 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 dispatching each cloud preparation request, bound to the exact route and destination, and records when it 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 silently repeating the request. An explicit retry re-resolves the current route.

At Stop, a detached tail task gives preparation a bounded drain window while transcript persistence proceeds independently; report generation waits for the tail decision. Physical Stop closes ordinary rolling dispatch. A request admitted before Stop may settle; if complete final coverage is still missing, the provider was prewarmed, and the entire bounded remainder fits one update, the worker may then start at most one full six-field canonical tail.

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

The saved-transcript path uses the complete input through 32,000 transcript characters; above the cap it retains five bounded windows across the beginning, interior, and end and labels the context Condensed. User-owned note context is complete through 8,000 characters and uses the same five-window strategy above that cap. The context is Condensed whenever either cap applies. After Stop makes no report-provider request during capture.

Context sent to AI

AI requests may include selected text, the current note, or other workspace context needed for the command. Answer from notes binds retrieval and the provider response to the exact open-vault index session captured when the request begins; closing or switching the vault cancels the in-flight step and discards a response from the old session.

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

Built-in conversations restore a bounded suffix of settled user-and-assistant text. Wrengle Local keeps that restored context on the device. A restored OpenAI or Anthropic conversation sends the bounded history to the selected provider with the next request. Pending permissions, live tool state, and attached resource content are not restored as settled conversation history.

External ACP continuation is capability-qualified. 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 displays the locally saved transcript with an explicit transcript-only notice and starts a fresh agent session; it does not silently send that transcript to the new session.

An 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. Creates, edits, and selection replacements always pass through Wrengle's preview and approval flow, editor-canonical serialization, stale-base conflict checks, and current-vault scoping. Agents without HTTP MCP support remain limited to the scoped ACP filesystem callbacks Wrengle exposes.

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 instead of presenting a new thread as success. If a matching external ACP session is currently live and supports session/close, Wrengle requests remote cleanup too and warns when the agent does not acknowledge it. Wrengle cannot delete an inactive remote session or override the external agent's provider, logging, or retention controls.

These boundaries apply only to Wrengle-mediated tools and callbacks. External agent subprocesses are not OS sandboxes and retain the ambient file, command, process, and network permissions of the selected command. They can use those permissions without a Wrengle approval prompt, including outside the open vault. Their provider, logging, retention, and billing policies remain separate from Wrengle's local storage model.

Meeting report generation uses the configured AI provider. Local providers keep transcript text and meeting-note context on your machine. Automatic mode starts one final report after the transcript is saved; Manual mode waits for Generate report. The same action remains available for an idle saved report in Automatic mode, so cancelled or failed scheduling always has an explicit manual recovery path.

Stop records an admitted automatic-report request before the first note write, so an initial save failure can resume after a successful user retry/recovery and current-policy revalidation. 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 managed-region write skip.

Provider preparation is cancellation-aware and bounded to 8.5 seconds for an explicit Ollama route or 20 seconds for other routes. Ollama model discovery uses one direct, no-proxy request capped at three seconds and 1 MiB. An edited report region is preserved for review. Provider credentials come from the sealed native session cache; an unavailable item prevents dispatch without starting a Keychain read or showing 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 bounded transcript excerpts or text, bounded user-owned meeting-note text, and meeting title/prompt context to that provider; model selection is under Settings → Models, and switching to a local model keeps report generation on device. Report requests send text, not meeting audio. 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 either the old or a new route; Manual retry required leaves that decision to the user. A visible retry uses the current resolved route. The disclosure is read-only; there is no separate authorize or revoke step.

Before a new post-Stop provider is prepared, Wrengle locally checks the existing report region for an edit conflict or malformed metadata. Check note and retry repeats that provider-free check after review. While the conflict or 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 remain separate audio boundaries with their own explicit consent and 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 hosted provider for sensitive material unless you are comfortable with that tool, command, or service receiving the context required for the request.

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 can be changed at any time in Settings → Privacy & Data. When enabled and configured, it uses a random identifier that lasts only for the running app process and can send only coarse event names and content-free metadata such as version, OS, action IDs, redacted error kinds, and meeting diagnostics; it is not a note, transcript, audio, or prompt upload path.

Website telemetry is separate and remains off until explicit opt-in. When accepted, the PostHog EU event payload contains only allowlisted manual fields and a random, browser-memory-only pseudonymous identifier that is sent with accepted events. PostHog also receives request-delivery metadata, and the production project must discard IP data; autocapture, session replay, feature flags, and person profiles are disabled. Sentry EU receives minimized error events. Use Privacy choices in the website footer to reject or withdraw consent; withdrawal clears or closes the optional clients for future collection. The website removes recognized PostHog cookie and Web Storage identifiers left by older builds before applying the current choice. 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 the 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 another device while they exist.

They can include completed transcript text, selected meeting context, the exact note target, provider exposure state, and report attempt revision. They contain neither raw meeting audio nor the memory-only prepared report. Replaceable live partial captions remain memory-only; recovery persists committed, refined, and final transcript text.

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

Its monotonic generation and OS file lock fence cooperating Wrengle processes only when they open the same underlying lock-capable filesystem object in one clock domain. If prompt release cannot finish, the row becomes recoverable when that filesystem's clock observes the heartbeat as at least two minutes old. Ordinary synced replicas are separate, potentially stale objects, not a distributed lock; independently clocked or future-skewed replicas are outside the fencing guarantee. Ordinary Markdown, chart projection, and editor-sidecar reads have a 16 MiB per-file cap; app-owned meeting-note writes use the same cap and fail closed above it. Wrengle deletes them after successful save/report, recovery, discard, or no-speech cleanup. Meeting cloud transcription is separate: it sends audio only for the explicit final pass after provider configuration and consent. Cloud dictation streams microphone audio while voice input is active, as described above.

Practical guidance

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