What you need

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

The signed app is intentionally smaller than its local speech and search assets. On first launch, Wrengle automatically starts a verified background download of the default Whisper model, its Core ML encoder, and the embedding model used by local search. The current release plan is about 2.9 GB of network data and can temporarily require about 4.1 GB of free disk, plus normal working headroom, while the Core ML archive is installed. The workspace remains usable during the download, shows exact progress and available disk space, and offers an actionable retry after an offline, disk, or integrity failure.

Generative AI does not add a language-model download: it runs in the cloud, either on your configured OpenAI or Anthropic key or on Wrengle AI credits. Older releases may have left app-owned language-model files behind; see Retired local AI models for explicit cleanup. Wrengle never removes them automatically.

Startup access and Limited mode

Before Wrengle mounts the normal workspace, it checks microphone access and the secure items your setup actually uses. System audio is different: on macOS 14.2 or later, startup only reports whether audio-only capture has been verified for this app identity. It does not open a stream or permission prompt. Use Settings → Privacy & Data → Desktop access → Enable and test when you want system audio. That explicit action plays a short, quiet tone and can open the macOS audio-only permission prompt. The test audio is discarded.

Wrengle also reads your configured provider, account, integration, action, plugin, and workflow secrets from the operating-system keychain into a protected area of memory that only the app can see. The app's interface only ever receives a readiness status, never a secret value.

This preflight is local. It opens no capture stream, contacts no provider, refreshes no OAuth, verifies no optional account, runs no workflow or action, starts no agent, and grants no app or plugin permission. Those operations keep their normal consent and side-effect boundaries. OAuth and provider consent, plugin capability grants, agent permissions, workflow and action approvals, app-mediated note-write proposals, and user-selected file or folder pickers all stay contextual. Startup never blanket-approves any of them.

If a supported capture check is denied or restricted, or the operating system denies or locks a configured secure item, Wrengle opens in granular Limited mode. Local vault and note work remains available. Only the capabilities tied to that missing permission or secure item are blocked. A credential that's simply missing, unconfigured, disconnected, or revoked doesn't put the whole startup in Limited mode. That one account, provider, integration, action, plugin, or workflow surface just stays disconnected on its own. Use Settings → Privacy & Data → Desktop access to open the matching operating-system settings, run the explicit system-audio test, restart after a legacy macOS screen-capture grant if you're asked to, or retry directly.

Platform behavior differs:

• macOS 14.2 or later: Wrengle uses Core Audio's narrower audio-only capture by default. In System Settings → Privacy & Security → Screen & System Audio Recording, this is the lower System Audio Recording Only list. The explicit audible test is the only action that requests or verifies this access. A successful test is remembered across launches only for the same capture backend and code-signing identity. Opening System Settings, changing output device during the process, switching backend, or rebuilding an ad-hoc app requires another test. macOS does not expose a reliable read-only status for this permission, so Previously verified is evidence of an earlier successful test, not proof that access has not since been revoked.
• macOS 13.4–14.1: system audio uses the upper Screen & System Audio Recording permission. A new grant can require Restart Wrengle. On newer macOS versions, Use legacy screen-capture permission selects this broader path manually; Wrengle never switches to it automatically after an audio-only failure.
• macOS development identity: the bundled Wrengle Dev flavor uses com.wrengle.desktop.dev and separate app data. A stable Apple Development signature lets macOS recognize it across builds. An ad-hoc rebuild has a new code identity and can require another grant and test. The raw macOS development executable can instead be attributed to the terminal that launched it or identified by a build-specific code hash, so use the bundled capture-development workflow for permission qualification. Update checks are inert and update installation is refused for debug or non-production identities. Never install or grant access to an ad-hoc bundle using the production identifier.
• macOS Keychain: each configured item can show its own dialog during startup: Allow covers one read, Always Allow remembers it for the current app identity, and Deny leaves only the dependent feature unavailable.
• Windows: the current unpackaged Windows build has no reliable way to request or check per-app microphone or system-audio access, so startup reports native capture permission as Not required. It does not probe a device, and it does not assume anything about the desktop-wide microphone switch, so a switch that's off doesn't put Wrengle into Limited mode on its own. Capture features still never open a Windows permission dialog. If the desktop switch or your selected device blocks capture later, that device-open attempt fails without a prompt and shows a capability-specific error instead. Settings → Privacy & Data → Desktop access always includes a Windows microphone Settings link, to Privacy & security → Microphone, for recovery. System-audio loopback needs no Wrengle-specific grant.
• Linux: capture is outside the v1 target and is reported as unsupported without probing devices.

Repair a stale legacy macOS Screen Capture grant

There is a one-time migration edge case after replacing v0.0.12 or an older ad-hoc build with the Developer ID-signed app. macOS can keep a Screen Capture row for the old code identity while System Settings still shows Wrengle's toggle as enabled. In that state a normal Restart Wrengle starts a fresh process, but it cannot rewrite the stale operating-system permission row. A full Mac reboot is not normally required.

This recovery applies only when macOS 13.4–14.1 requires the legacy backend or you explicitly selected it on a newer system. For default audio-only capture on macOS 14.2 or later, use the lower list and run Enable and test instead.

Quit Wrengle, open System Settings → Privacy & Security → Screen & System Audio Recording, and use the Wrengle entry in the upper Screen & System Audio Recording list. Select that upper Wrengle entry and use the − button to remove it. If macOS does not offer that removal control, reset only the released app's Screen Capture row in Terminal:

tccutil reset ScreenCapture com.wrengle.desktop

Then reopen the current signed Wrengle, add or enable it in the same System Settings pane, and use Restart Wrengle once if the app asks. This reset does not target Wrengle Dev, whose bundle identifier ends in .dev.

The vault folder you pick stays contextual, because you're the one who chose it. Network access is only used later, when a feature such as a model download, an update check, a provider request, or an OAuth flow actually needs it.

Recording a meeting also needs a writable vault app-data area, at .app/live/. Before recording starts, Wrengle rechecks capture status, without requesting it again, along with your vault, Local Whisper model availability, and recovery storage space. Unavailable recovery storage or a revoked capture grant blocks recording without a system prompt, and low free space is flagged before you start. Healthy readiness details sit behind the meeting More menu's troubleshooting section, out of your way until you need them.

Encrypted meeting audio uses about 0.92 GB for eight hours of one mixed channel or 1.85 GB for eight hours of separate microphone and system channels, before filesystem allocation rounding. Wrengle also protects a 512 MiB free-space reserve, checks headroom before capture, and probes the volume during recording so it can stop safely before exhausting the disk. These figures describe storage planning, not an advertised eight-hour support guarantee.

Preparing a report while you record

After Stop is the default on a clean install: Wrengle waits until you stop recording before it starts building a report. Report preparation: Auto is something you turn on. For an Automatic meeting, it lets Wrengle build a report in memory while you're still recording. That needs the transcript so far to be complete and accurate, a note it can write to, and enough spare capacity on your machine to do the work. Wrengle skips this step rather than compete for that capacity when there isn't enough to spare. Choosing After Stop instead means no report-provider work happens until recording ends.

A separate setting, Prepare final transcript while recording, is on by default wherever local transcription is available. It keeps that final pass local, uses only a background share of CPU, and runs whether report preparation is Manual or After Stop. Turn it off and the complete local final pass waits until Stop instead.

Live captions and the final-transcript pass both stay local while you record. Wrengle also builds a Live draft straight from your committed captions. It's local too, makes no provider request, and a later refinement corrects the same caption. If you've turned on a cloud report route, an update from that provider can replace it with a Live AI draft. Both drafts are read-only, can keep changing while you record, and live only in memory rather than on disk. They stay visible right through Stop, and a UI reload brings back the latest one while the active desktop process retains that session. The previews are never written to recovery, another disk file, logs, or telemetry.

A retained local report route never runs; choose direct OpenAI/Anthropic or an enabled Wrengle AI tier to start fresh report generation. With Auto turned on and a cloud route selected, Wrengle can send several transcript-text requests to that provider while you're still recording. These requests never include audio, but network use and that provider's own billing, logging, and retention can all apply during capture, not just afterward. Every request is recorded before it's sent. If an interruption leaves it unclear whether one finished, Wrengle asks you to retry by hand rather than guess and send it again automatically.

Pressing Stop ends that regular stream of requests, though one already underway can still finish. Saving the transcript itself is independent and keeps going regardless. If the report is still incomplete once the transcript is saved, and a provider is already warmed up and ready, Wrengle can send one closing request with everything that's left, as long as that remainder fits in a single request.

When a closing request isn't possible, Wrengle instead builds the report straight from the saved transcript. Long transcripts are divided into contiguous shards covering every source character; completed evidence is checkpointed, exact list fields are merged across every shard, and narrative fields are reduced hierarchically. Your own note context is complete through 8,000 characters and uses a condensed five-window representation above that cutoff. Wrengle sends at most one closing request. If it's unclear whether that request landed, or your note context changed afterward, you retry by hand rather than Wrengle silently trying again.

Auto costs extra CPU, throttled but still extra, and may reach the network while you record. Choose After Stop if you're on battery, running warm, or short on CPU headroom. AI and privacy has the complete routing and data detail.

Updates and release channel

v0.0.12 and older are legacy unsigned betas. Beginning with v0.0.13, published builds check Wrengle's public downloads repository for signed update metadata. v0.0.13 starts the latest-v2.json channel with a new updater trust root. Clients on v0.0.12 or older must install v0.0.13 manually once; automatic updates resume on v2 afterward.

v0.0.18 and later require Apple Silicon and macOS 13.4. They continue to use latest-v2.json, which contains only the darwin-aarch64 updater target. v0.0.17 is the final universal Intel-compatible and macOS 13.0–13.3-compatible release; those systems receive no later releases or security fixes.

A candidate stays a draft while its exact source commit, artifact hashes, Developer ID signature, Apple notarization, updater signature, architecture, and deployment target are checked. Optional hardware smoke testing does not block publication. Publishing is what makes the candidate available to downloads and auto-update.

Optional Beta accounts are available through email or Google. Downloads and local use remain account-free. There are no licenses, no gated downloads, and no subscription plans. The one thing an account can buy is prepaid Wrengle AI credits, which are spent only by AI requests you make and change nothing else about what you can access. An account includes no free or recurring AI credit; the hosted tier mappings, rates, and availability are documented under Wrengle AI and credits.