Platforms and requirements

Wrengle is a desktop product. Platform support depends on native packaging, platform permissions, and local model requirements.

Startup access and Limited mode

Wrengle checks supported capture permissions and configured secure items before mounting the normal workspace. On macOS, it asks for microphone and screen/system-audio capture access at startup rather than when you press Record, start dictation, or test a microphone. Configured provider, account, integration, action, plugin, and workflow secrets are also read from the operating-system keychain into a native, process-memory-only session cache. The renderer receives readiness status, never secret values.

The preflight is local. It does not open a capture stream, contact providers, refresh OAuth, verify the optional account, run a workflow or action, start an agent, or grant app/plugin permissions. Those operations retain their normal consent and side-effect boundaries. OAuth/provider consent, plugin capability grants, agent permissions, workflow/action approvals, app-mediated note-write proposals, and user-selected file/folder pickers remain contextual; startup does not blanket-approve them.

If supported capture access is denied or restricted, or the operating system denies/locks a configured secure-item read, Wrengle opens in granular Limited mode. Local vault and note work remains available; only the capabilities that require the unavailable permission or secure item are blocked. A cleanly missing, unconfigured, disconnected, or revoked credential does not make the whole startup Limited; its own account, provider, integration, action, plugin, or workflow surface remains disconnected or unavailable. Use Settings → Privacy & Data → Desktop access to open the relevant operating-system settings, restart after a macOS screen-capture grant when instructed, or explicitly retry. Feature buttons never fall through to a new operating-system permission prompt.

Platform behavior differs:

• macOS: microphone and screen/system-audio permission requests happen during startup. Each configured Keychain item can show a separate dialog. Allow covers one access, Always Allow remembers the current app identity, and Deny leaves dependent features unavailable. Ad-hoc development rebuilds can have a new identity and prompt again.
• Windows: the current unpackaged Windows (Win32) build has no reliable per-app microphone or system-audio request/status API, so startup reports native capture permission as Not required. It does not probe a device, promise to detect the global desktop-app microphone switch, or enter Limited mode merely because that switch is off. Capture features still never open Windows permission UI. If the global switch or selected device prevents capture, the later device-open attempt fails prompt-free with a capability-specific error. Settings → Privacy & Data → Desktop access always offers a Windows microphone Settings link to Privacy & security → Microphone for recovery. System-audio loopback does not require a Wrengle-specific grant.
• Linux: capture remains outside the v1 shipping target and is reported as unsupported without probing devices.

File/folder access for the selected local vault remains contextual because you choose the folder. Network access is used later only when a feature such as a model download, update, provider request, or OAuth flow actually needs it.

Meeting recording also needs a writable vault app-data area for .app/live/. Before recording starts, Wrengle rechecks capture status without requesting it, along with vault state, local model availability, and recovery storage. Unavailable recovery storage or a revoked capture grant blocks recording without showing a system prompt, while low free space is surfaced before you start. Healthy readiness details are kept behind the meeting More menu troubleshooting section.

During-recording report preparation

After Stop is the clean-install default. Report preparation: Auto is an opt-in path that can build one capped six-field report in memory for an Automatic meeting. It depends on completed final-quality transcript chunks, an eligible saved-note target, and enough local background decode capacity. Wrengle skips during-capture report preparation when the device cannot provide the required background capacity. After Stop defers all report-provider work until recording ends.

The separate Prepare final transcript while recording setting is on by default for eligible local transcription. It remains local, uses bounded background CPU, and continues in Manual report mode or with After Stop report preparation. Turning it off moves the complete local final pass to Stop.

Live captions and final-transcript preparation remain local during capture. A bounded Live draft derived immediately from committed captions is also local and makes no provider request; refinement corrects the same caption, and an eligible rolling provider update can supersede it with a Live AI draft. Both are process-memory-only, read-only, and may change. They remain visible through Stop and can be restored after a UI reload while the active desktop process retains the session, but are never written to recovery, another disk file, logs, or telemetry.

Current local report backends wait until after Stop when they cannot prove request-specific cancellation has quiesced before transcription resumes. An eligible cloud route can receive multiple bounded transcript-text requests, so network use, provider billing, logging, and retention can apply during capture. These requests contain no meeting audio. Each request is durably claimed before dispatch; an interruption that leaves completion ambiguous requires a manual retry instead of an automatic replay.

At Stop, a detached tail task gives the worker 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 can settle. If complete final coverage is still missing, a prewarmed provider may then receive at most one full six-field canonical tail when the entire bounded remainder fits.

Before a tail starts, an invalid remainder uses the canonical saved-transcript fallback: complete through 32,000 transcript characters, then five bounded beginning/interior/end windows with a Condensed label for longer meetings. 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. Once a tail starts, Wrengle sends no second automatic request; ambiguous exposure or changed note context requires manual retry.

Auto preparation uses additional throttled CPU and may use the network, so choose After Stop on battery-, thermal-, or CPU-constrained systems. See AI and privacy for the data sent and routing behavior.

Updates and release channel

Published builds use updater metadata from the public downloads repo (latest.json). Releases remain drafts until clean-machine smoke testing passes; publishing the public downloads release enables the website download links and auto-update. Public account access is available and optional. Checkout, licenses, gated downloads, and active pricing remain unavailable even though internal billing helpers exist. Checkout, customer-portal, and Polar webhook routes all return non-cacheable 404s.