Everything Oris does, in one place.

Oris settings live in the Oris app, not in the Obsidian plugin. Open the app after the setup walkthrough and its home window is the settings manager.

The Obsidian plugin is a thin recording trigger. It starts and stops recordings and reserves the spot in your note where the transcript lands. Everything else, meaning provider, API keys, transcription model and retention, is configured in the app.

Layout

The home window is organized into tabs:

• General — setup status, walkthrough controls, updates, build info
• Transcription — transcription model, language
• Summarization — provider selection, credentials, fallback order, connection tests
• Recordings — recent recordings and full history, audio retention, auto-stop on silence
• Voice — Quick Note: the master switch, destination, activation mode, hotkey, AI cleanup, and the quick-notes viewer

General tab

• Your Oris — a stats card summarizing how you have used Oris so far. See Your Oris (usage stats).
• Setup status — a compact health summary of each setup step: destination, plugin install, permissions, model warmup, notifications. It loads quietly on every app open, and no animation runs unless you explicitly request a re-check.
• Destination — where your meeting notes land: an Obsidian vault, a Markdown folder, or Apple Notes. A file destination reports its kind and its path. When something is wrong, such as a vault or folder that moved or a store Oris can’t read, the row says exactly what, so you find out before a recording does. See Destinations.
• Apple Notes automation — present only when your destination is Apple Notes. It reads allowed, not set up yet, turned off, or not checked, and its button is the fix for that state: Grant access raises the one macOS prompt when the permission has never been asked for (a caption explains the ask first, and the row updates itself with the answer), and Open System Settings opens the Automation pane when it has been turned off, with the re-check running on its own when you come back to Oris. A quiet Check again link re-reads the answer without asking anything. Not checked is where the row usually rests until you ask: reading the answer means launching Notes, and opening a settings tab is not a reason to open Notes, so Oris reads it by itself only when Notes happens to be running already; with Notes closed the row waits for its Check button. See Apple Notes.
• Re-check permissions — runs the test capture in place, the same ~8-second capture the walkthrough uses, without requiring a full walkthrough re-run. Use this after adjusting audio routing or system-audio settings to confirm both tracks are live.
• Notifications — shows whether Oris is allowed to post notification banners for notes-ready, auto-stop and summary-failed. Banners are posted by the recorder, so if you denied the notification prompt, or later revoked it in System Settings, banners silently stop and this row flags it. It has its own Re-check button and, when notifications are off, an Open System Settings → Notifications link so you can re-enable Oris.
• Feature tour — opens the in-app tour of what Oris can do. See Feature tour.
• Send feedback — opens the feedback sheet. See Send feedback.
• Re-run walkthrough — resets walkthrough progress so you can step through the guided setup again. Settings, models, and permission grants are untouched.
• Updates — an Automatically check for updates toggle, on by default, so Oris checks daily in the background and prompts you to install when a new version is found. Next to it is a Check for Updates… button to check right now. See Automatic updates.
• Share anonymous system info — on by default. The daily update check carries a small profile: macOS version, Mac model and CPU, your app and update-tool versions, preferred language. That list is the whole of it, never your audio, recordings, or notes. Turn it off and the update check still runs, just without the profile.
• Version footer — current build info.

The destination is established during the walkthrough and is not editable here. It is where your notes land, and, when it’s an Obsidian vault, where the plugin is installed. To change it, whether to Apple Notes or back to a vault or folder, use Re-run walkthrough: your prior choices are pre-filled, and steps that are already done check themselves off.

There is no Save button. Changes persist on their own, a toggle or a dropdown the moment you flip it and a text field a moment after you stop typing, and a brief “Settings saved” confirmation appears when it lands. A change you made in another window isn’t reverted by an unrelated change you make here.

That confirmation belongs to Transcription, Summarization, Recordings, and Voice. General’s two preferences, Automatically check for updates and Share anonymous system info, take a different route: they save the instant you flip them but show no banner.

One combination is deliberately held back rather than written: a Quick Note destination of Pinned note with an empty note path. The form keeps showing your selection and the Voice tab explains why, but what actually gets saved is the in-app-inbox default, which is exactly where captures would land anyway. Fill the path in and it saves normally.

Transcription tab

• Transcription model — a dropdown of the available models, with Large v3 Turbo (recommended) as the default, plus a Custom… option that accepts a free-text model name. Larger models are more accurate but slower, and the default is a good balance.
• Language — the spoken-language hint. The default is Auto-detect (recommended), where Oris infers the language from the first few seconds of audio. To force a specific language, choose from the list (English, Spanish, French, German, Italian, Portuguese, Dutch, Japanese, Chinese, Korean) or type a language code into the Custom field. Transcription handles far more languages than the list shows, and summary quality depends on the provider and model you picked.

Summarization tab

• Enable summaries — turn this off to skip the summary step entirely. The transcript still lands in your note. See Skipping summaries entirely.
• Provider — pick the backend: Auto, Local (mlx), Ollama, OpenAI, Anthropic, or Azure OpenAI. The credential fields below change to match the provider you selected, and values for all providers are kept, so switching back doesn’t lose them.

Each cloud or network provider gets its own card of labeled fields:

• OpenAI — API key, and an optional Model.
• Anthropic — API key, and an optional Model.
• Azure OpenAI — Endpoint, API key, Deployment, and an optional API version.
• Ollama — Endpoint, and an optional Model.
• Local (mlx) — no credentials, since it runs on your Mac. A Model override field pins one model instead of letting Oris pick by transcript length. See Pinning a specific local model.

Every cloud and network provider gets a Test button, on its card when you have picked that provider and on its row in the fallback list when the provider is Auto. It checks the values currently in the form with a small live request that exercises the key, the model name, and the endpoint together, then shows either Connected or a specific error pointing at the exact problem. You find out a key is wrong in a second rather than after a meeting.

Fallback order

With Provider set to Auto, the tab shows a drag-reorderable list of providers. Drag them to set the order Oris tries, and each row tells you whether that provider is configured. Providers you haven’t set up are skipped wherever they sit in the list. See Provider auto-detection.

Recordings tab

The tab opens with Recent recordings, your last five recordings and imports as compact rows showing note name, date, mini-stats and status, plus a See all recordings… button that opens the full history in a sheet. Rows carry actions to open or share the landed note, reveal the audio, retry a failed summary, or delete the audio early. See Recordings history. That list is display rather than settings, and nothing in it is written back to your configuration. The settings sit below a divider:

• Audio retention — a Days field controlling how long raw recordings are kept before Oris cleans them up. The default is 90 days, and 0 keeps everything. See Audio retention cleanup.
• Auto-stop on silence — a Stop recording after a stretch of silence switch, a minutes value, and a Warn me … seconds before it stops field. When both the mic and system-audio tracks go quiet for that long, the recording stops itself and transcription runs normally. The default is five minutes with a sixty-second warning, and changes apply to your next recording. See Auto-stop on silence.

Voice tab

The Voice tab holds Quick Note. It stays present whether or not capture is running, so the master switch and your captures are always reachable. Two of these settings are read when Oris launches, the master switch and the hotkey, while destination, activation, and cleanup are re-read for every capture and apply immediately.

• Enable voice capture — the master switch. Because it is read at launch, flipping it shows “Saved — relaunch Oris to apply.” until you restart the app. While capture is off, the tab says so and points out that quick notes you have already taken are still openable below.
• Open quick notes — opens the two-pane quick-notes reader, with captures by day on the left, the selected capture on the right, and Send to vault, Copy, Reveal and Delete above the text.
• Quick note destination — the in-app inbox (the default), a pinned note at a vault path you name, a daily note, or a weekly note. Daily and weekly notes are created in a folder you choose. A live preview shows the exact path your next capture lands in when your notes go to a vault or folder. With an Apple Notes destination these file choices, the preview they feed included, stay configured but don’t act: the connector decides where captures land (a note per day, or one note you name; the Apple Notes page covers both shapes), and the file settings take effect again when you switch back to a vault or folder (which, like any destination change, happens by re-running the walkthrough from the General tab).
• Hotkey — the current combination, shown read-only, defaulting to ⌃⇧Space. A control for changing it in the app is coming. The tab warns you when the combination is one macOS is known to claim for itself, and it shows whether the registration succeeded.
• Activation — press to start and press again to stop, which is the default, or hold to talk and release to finish.
• Tidy up quick notes with AI — off by default. It adds punctuation and casing and drops filler before the capture lands, using the same provider settings as your summaries.

The Obsidian plugin’s settings tab

The plugin’s own settings tab shows only the paths it detected, read-only, and a link to the Oris app for everything else. Recording, the mic ribbon, the status bar pill, and the retry command all work exactly as before.

Oris has a built-in Send feedback surface in the Oris app, so you don’t have to hunt for an email address when something breaks or you have an idea. Reach it two ways: the Send feedback button on the app’s General tab, or Send Feedback… in the app’s Help menu.

Both open a short sheet with a message box. Type what you want to say (what broke, what’s confusing, what you’d love to see) and hit Send…. That opens a draft in your Mac’s mail app, already addressed to [email protected] with your message filled in. Oris itself sends nothing: it just hands the draft to your own mail app, where you review it and hit Send yourself, so you decide what actually goes out.

Diagnostics are opt-in. The sheet has an Include diagnostics toggle, off by default. When you turn it on, the draft appends a few non-sensitive facts that help with troubleshooting: your Oris version and build, your macOS version, and the status (OK or failed) of your most recent recording along with roughly how long ago it ran. It never includes your audio, your recordings, or your notes, just the version numbers, a one-word run status, and a coarse timestamp. Leave the toggle off and the email carries only your own words.

If your Mac has no mail client configured (or the draft won’t open for some reason), use Copy to clipboard instead. It copies the recipient, subject, and body so you can paste them into whatever you use to send mail.

This is an additional, easier channel alongside the private beta’s email ask, not a replacement: emailing [email protected] directly still works exactly as before. Either way, the fastest way to shape what gets built next is to tell me what broke, and it all goes to the same inbox.

Setting Settings → Summarization → Provider to Auto, which is the default, means Oris tries the providers in order and summarizes with the first one that’s configured. The order it starts with is OpenAI, Anthropic, Azure OpenAI, Ollama, Local (mlx). A provider counts as ready only when everything it needs is filled in: a key for OpenAI or Anthropic, the endpoint, key and deployment together for Azure, and for Ollama a reachable server that actually has a model installed. Local (mlx) sits at the end as the guaranteed last resort, so Auto falls back to it even when nothing else is set up: Oris would rather run the on-device path and tell you if it failed than report that no provider was available.

The order reflects a simple bet. If you have paid for a cloud key you probably want it used, a local Ollama server is quicker than spinning up the on-device model, and the on-device model is the always-available free fallback that needs no account at all.

You can override the auto-pick at any time by choosing a specific provider in the same dropdown. An explicit choice is always honored, and the fallback order stops applying the moment you make one.

Changing the order

With Provider set to Auto, the Summarization tab shows a drag-reorderable list of every provider. Drag a row up or down and that becomes the order Oris tries. The change saves as you drop it, with no Save step, and each row tells you whether that provider is configured, so you can see at a glance which ones are actually in play. Providers you haven’t set up are skipped wherever they sit in the list, so it is fine to leave all of them listed and let the order matter only for the ones you use.

Leave the list alone and Oris uses the built-in order above.

When Auto lands on the on-device provider, the model it uses scales to the length of the transcript, so a standup doesn’t pay for a model sized for a strategy session. Pinning one model instead is a single field: see Pinning a specific local model.

Local (mlx) summarizes on your Mac, using Apple’s MLX framework. No API key, no cost, and your transcript text stays on the machine along with the audio. It’s what Oris uses out of the box, and what Auto falls back to when no other provider is configured.

The only time it touches the network is to fetch a model. Oris downloads the default one for you during setup, so your first summary doesn’t stall on it, and any larger model is fetched once, the first time something actually needs it. See Preparing the model for what that looks like while it’s happening.

Which model runs is picked from the length of the transcript: a short one gets the small model, a long one gets a bigger one. That choice is also capped by what your Mac can actually hold, so a long meeting on a smaller machine gets the best model that fits rather than one that would swamp it, which is what keeps a big transcript on a small machine from being the reason a summary fails. It can still fail, the same as any provider; summaries are best-effort everywhere, and the transcript lands regardless. To pin one model and skip the switching entirely, see Pinning a specific local model.

If you already pay for a cloud model, Oris will use it. The three cloud backends are bring-your-own-key, billed to you by the provider you chose, with nothing proxied through a service of ours. Ollama is the fourth option and works differently: it is a server you run yourself, on this Mac or another one on your network, so there is no key and no bill. What they share is that only the transcript text is sent, and only where you pointed it. The audio itself is never sent to them either way.

Pick the provider under Settings → Summarization → Provider, and the fields below it change to match:

• OpenAI — an API key, and an optional Model. Leave the model blank and Oris uses a fast, inexpensive default (gpt-4o-mini). This is the general-purpose choice.
• Anthropic — an API key, and an optional Model, defaulting to claude-haiku-4-5. The best summaries we have measured, at slightly more latency.
• Azure OpenAI — an Endpoint, an API key, a Deployment name, and an optional API version. For anyone whose keys live in an Azure tenant.
• Ollama — an Endpoint, pointing at http://localhost:11434 by default, and an optional Model. Leave the model blank and Oris uses the first model your Ollama server lists, so name one here if you care which.

Any of them changes which model writes the summary, not what the summary looks like. The shape is the same whichever backend runs: the same sections, the same transcript below it, the same footer naming what produced it.

Test connection

Each provider gets a Test button, on its card when you have picked that provider and on its row in the fallback list when the provider is Auto. It takes the values currently in the form, before you have recorded anything, and makes one small live request that exercises the key, the model name and the endpoint together. You get back either Connected or a specific error naming the actual problem, along the lines of “Invalid API key (401)”, “Model not found” or “Endpoint unreachable”. It’s a couple of seconds, and it’s a far better way to find out a key is wrong than a meeting that comes back without a summary.

By default the on-device summarizer picks its model from the length of the transcript. To use one model for everything instead, put a compatible HuggingFace repo id into the Model override field under Settings → Summarization → Local (mlx). Leave it blank and Oris goes back to choosing for you.

It’s worth pinning when you have benchmarked a particular model and want output you can compare across meetings, when you have already downloaded something larger and would rather it were always used, or when you want to try a different model family and see how its summaries read.

Turn off Enable summaries under Settings → Summarization and Oris skips the model call altogether. The transcript still lands in your note, just as a plain section rather than a collapsed one with a summary above it.

People turn this off for good reasons: you already process transcripts somewhere else, you would rather read the conversation yourself for the kind of thing you record, you’re keeping cloud spend down, or an on-device summary takes longer on your machine than you want to wait. Switch it back on whenever you like, and the next recording gets a summary again. Nothing about the recordings you made in between changes.

Behind the notes Oris writes sits one small promise with two halves: the finished content is made durable before it goes into your note, and every landing attempt leaves a receipt. Together they mean a failed write can’t lose the work, and a repeated one can’t give you the same transcript twice.

How a note lands

When a recording finishes, Oris first saves the finished transcript (summary and all) as a durable copy in its own state directory, and only then writes it into your note. If that write succeeds, a receipt records exactly where it landed. If it fails because the note went read-only, the disk filled, or the machine died mid-write, the durable copy simply stays in the outbox, the failure is recorded, and Oris tells you. The recording’s transcript isn’t gone; it just hasn’t landed yet.

The receipt is also what stops duplicates. Before landing anything, Oris checks whether that exact content already reached that destination, so re-running a recovery, clicking retry twice, or replaying an interrupted delivery gives you one copy in your note, not two. The one exception is deliberate: --force on the command line overrides that check, because it exists for the case where you have looked at the note yourself and decided a re-write is what you want. If you’re forcing because Oris couldn’t tell whether a note landed, check first, and use ack when it did.

The same machinery covers imports and quick notes. One honest caveat on scope: the first quick note of a day or week creates its periodic note’s header line just before the capture is persisted, and a quick note you’re still dictating when a meeting recording starts is discarded by design. The durability promise is about finished content on its way into a note, not about every keystroke.

Where you see it

• The Recordings tab’s “Awaiting delivery” section is the outbox made visible: when anything is waiting, it appears at the top of the tab with what’s waiting, where it was going, and why it hasn’t landed. Each item offers what’s actually safe for its state: retry for a plain failure or an interrupted write, Mark delivered… where a blind retry would be the wrong move, and details either way. That covers two situations: the couldn’t-tell case below, and a quick note whose text is already safe in Oris. A quick note never gets a retry button here, because its real recovery is the Quick Notes viewer’s Send to vault; once you’ve sent or kept it, Mark delivered… clears the leftover item without writing anything. While anything is waiting, the Recordings tab itself says so: its label in the tab strip carries the count — Recordings (2) — so a stuck delivery is announced even when you’re elsewhere in the app, and the count disappears the moment the queue drains. The first time the queue goes from empty to non-empty, Oris also posts one macOS notification — “A note couldn’t be delivered — it’s saved in Oris” — so a failure that happens while you’re elsewhere entirely still reaches you; clicking it brings you to the Recordings tab in Oris. It’s one banner per incident, never one per item, it isn’t repeated on later launches for a queue you’ve already been told about, and it holds off for about half a minute first so a queued delivery Oris is about to finish on its own never raises a false alarm. When nothing is waiting, the section isn’t there at all. One entry there isn’t a failure at all: with an Apple Notes destination, a recording finished while the Oris app was closed waits here until you open it, because macOS grants the permission to control Notes to the app. Nothing needs clicking: opening Oris is the whole fix.
• The recordings history joins receipts into each row. A recording whose delivery failed says so in plain words: “delivery failed (permission) — the transcript is saved, not yet in the note”. A retry button lands the saved copy. No re-transcribing, no re-summarizing: the bytes that land are the bytes that were saved.
• The failure notification sends you to the Recordings tab’s awaiting-delivery section, because that is the surface every install has. It used to name a terminal command, which was the wrong advice for anyone who installed the app from the DMG and never touched a shell — and even a repo install doesn’t put that particular command on your PATH. From a checkout, bin/oris-recover reports the same thing in the terminal.
• A crash mid-write is reconciled rather than guessed at: Oris checks the note itself to see whether the write actually happened before deciding anything. In the rare case it genuinely can’t tell, it says so and asks you to look, because you checking the note beats it writing a duplicate. Once you’ve looked and the note is there, Mark delivered… on the awaiting-delivery item records your answer and closes it, without writing anything to your notes.

The oris command line

The same machinery is scriptable through the oris CLI, the power surface behind all of the above. If you installed from the repo, setup.sh puts oris on your PATH. If you installed the app from the DMG, the binary ships inside the bundle at Oris.app/Contents/Resources/oris/bin/oris: call it by that path, or add that directory to your PATH yourself, since the app doesn’t modify your shell.

The verbs you’d actually reach for:

• oris deliveries list --failed shows what’s held in the outbox, and why.
• oris delivery retry <receipt-id> lands a failed delivery from its saved copy.
• oris delivery recover reconciles attempts that were interrupted mid-write (run automatically by oris-recover).
• oris delivery ack <receipt-id> is for the one case Oris can’t resolve alone: it couldn’t tell whether a note landed, you checked, and it’s there. ack records your answer and closes the chain without writing anything to your vault, which is exactly the point (a forced retry in that state is what would create the duplicate).
• oris delivery open <receipt-id> prints the link to where a receipt says the note landed — an obsidian:// link for a vault, a file:// one for a Markdown folder, an oris-applenotes:// one for Apple Notes (which macOS routes back through Oris, since only Oris may ask Notes to show a note). By default it only prints; add --launch to hand that link to macOS as well, which opens it in Obsidian or in whatever app owns the file. (The Oris app never passes --launch — it opens the note itself.)

Everything here is local files under your own state directory. Receipts record ids, paths and outcomes, never note content, and none of it leaves your Mac.

Summarization is best-effort. If the provider is unreachable, the key is wrong, or the model comes back empty, the transcript is inserted into your note exactly as it would have been, with a ⚠️ block where the summary should be. Oris keeps the failure, so nothing about that recording is lost while you go and fix the cause.

Fixing the cause usually means a corrected key or a switch to a different provider under Settings → Summarization. Once that’s done, there are two ways to retry, and both run the same thing.

The Oris app’s recordings history shows a Retry button on any row whose summary failed. One click re-summarizes just that recording, the row spins while it works, and it settles into a green check when the summary lands.

Inside Obsidian, two commands cover the same loop without leaving the editor: Oris: Show failed summaries (no retry) lists what’s pending, and Oris: Retry failed summaries works through all of them and reports back.

The ⚠️ block in your note names the app first and Obsidian second. A recording made without Obsidian can land in the note of someone who doesn’t have Obsidian installed, so the app’s retry is the one route that always applies.

Either way, a retry reuses the transcript that already exists rather than re-transcribing the audio, so it takes as long as a summary and not as long as a meeting. On a file destination, an Obsidian vault or a Markdown folder, it then patches the original note in place, replacing the ⚠️ block with the real summary. A retry that fails again leaves the note untouched, ⚠️ block and all, and records the newer error against that recording instead. The note stays as it was, while the failure you see in the app’s history is always the most recent attempt.

An Apple Notes destination recovers differently, because patching a block inside a Notes note is not shipped yet. There, a successful retry delivers the fresh summary as its own note, titled Summary — <the original note's title>, in the same folder. The original note keeps its ⚠️ block as the pointer to where the summary went. Retrying again with the same summary doesn’t stack copies: the same content is recognized and lands once. Patching in place is planned.

A successful retry is also written down twice, each record with its own job: the note write lands through the delivery core and leaves a receipt naming the note it landed in, and the retry’s outcome is recorded against the recording itself, which is what heals the row in the recordings history to a green check.

When there was no note yet

A recording started without Obsidian has no note while it’s being summarized — the note is created afterwards, wherever your destination puts it. So when the summary fails on one of those, the failure Oris writes down doesn’t name a note, because at that moment there wasn’t one.

Retrying still finds it. Oris records where each recording’s note landed, and a retry with nothing else to go on asks the delivery core for that landing, then heals the note it actually created. You get the same result as any other retry: the ⚠️ block replaced on a file destination (or the sibling summary note created on Apple Notes), the sidecar cleared, a receipt written.

If the landing can’t be worked out, because the record of it was lost to a crash or a cleared state directory, the retry reports the attempt as unsuccessful. It leaves the recovered summary in a file next to the audio so the work isn’t lost, and keeps the failure so the Retry button stays where you can see it. The rule throughout this loop: a retry counts as a success only when the text reached the note you’d open.

If transcription is killed mid-flight, by a reboot, a force-quit, or a machine that ran out of memory, the <!-- TRANSCRIPT_PENDING_<ts>_<pid> --> marker is left sitting in your note with nothing to replace it. The audio is still there; only the step that turns it into a transcript didn’t finish.

Oris can find those orphans. It scans your vault for stranded markers and pairs each one with the recording it most likely belongs to, matching on when the marker was written against when the audio was recorded, within about a minute either way.

Run Oris: Scan for orphan recording markers from Obsidian’s command palette and it shows you what it found: how many stranded markers there are, how long the oldest has been sitting, and which notes they’re in. Scanning never changes anything by itself, which is deliberate, so a marker is never quietly overwritten while you’re still deciding what to do about it.

Actually recovering them is the second, separate step, and the same notice hands you the command for it, filled in for your install so you can copy it straight out. Running it lands the transcripts where they were always meant to go — and it’s smart about how. A marker whose transcript was already produced and saved (the pipeline finished, only the note write didn’t) is delivered from that saved copy: no re-transcription, no re-summarization, and no risk of a second version of the same meeting appearing anywhere. Only a recording that never got as far as a transcript is re-transcribed from its audio. A recording whose note actually landed already — say, in the inbox after a rename went wrong — is recognized and left alone, with the stale marker pointed out so you can delete it.

If someone else recorded the meeting — Zoom’s auto-transcript, Teams, Otter, a copy-pasted plain-text transcript, a VTT/SRT subtitle file — Oris runs it through the same format → summarize → land-in-your-vault flow that a live recording would use. Format is auto-detected; override it (vtt, srt, otter, plain, json) if the sniffer misfires (rare, but possible with copy-pasted text that happens to look JSON-ish).

The Obsidian plugin’s Oris: Import external transcript… command opens a modal: paste a transcript or pick a file, choose a format, and pick where it lands: Inbox, New note (custom path), or an existing note you choose. That last option is labelled Replace marker in existing note, but what it does today is append the import to the end of the note you picked, so expect to find it at the bottom rather than at a marker. The optional “copy original into <vault>/_archive/” toggle preserves the source file with cross-link frontmatter so it survives even if you later delete the produced note. Import runs in the background: clicking Import closes the dialog right away and the work continues while you keep working or start another recording. A status-bar pill (⬆ importing…) shows it running, and when the note lands you get a notice you can click to open it, plus a macOS banner if you have switched away from Obsidian. The transcript is summarized by whichever provider you’ve set up under Settings → Summarization, which is on-device by default (see Local MLX); on that default, a long transcript that needs a bigger model downloads it once. Only one import runs at a time.

Sometimes the recording already exists — a Voice Memo you dictated on your phone, a Zoom or Teams recording someone shared, an .mp3/.wav/.m4a from another tool. Audio file import runs that file through the exact same transcribe → format → summarize → land-in-your-vault pipeline a live Oris recording uses, without you having to re-record it live. It’s the audio sibling of external transcript import: that one takes an already-transcribed file, this one takes raw audio and transcribes it first with the same on-device WhisperKit model.

Supported formats. The picker lists the common ones — .m4a, .mp3, .wav, .aac, .m4b, .caf, .aiff, and .flac. That list is a convenience filter rather than a hard limit, because Oris decodes audio the same way the rest of macOS does. In practice, if QuickTime Player opens the file, Oris can transcribe it. Pick “All files” in the dialog to try one that isn’t listed.

The Obsidian plugin’s Oris: Import audio file… command opens a modal: choose an audio file, optionally set a title, and pick where the note lands — inbox/, a new note at a custom path, or appended to the end of an existing note. The optional “copy the original audio into <vault>/_archive/” toggle preserves the source file so it survives even if you later delete the produced note. Import runs in the background: clicking Import closes the dialog right away and the transcription continues while you keep working. When the note lands you get a notice you can click to open it, plus a macOS banner if you have switched away from Obsidian. The transcript is summarized by whichever provider you’ve set up under Settings → Summarization, which is on-device by default (see Local MLX), and only one import runs at a time.

One thing to know about speaker labels. A live Oris recording captures your microphone and the system audio on two separate tracks, which is what lets it split the transcript into “me” vs. “others” (see me/others speaker labels). An imported audio file is almost always a single mixed track — everyone’s voice is already blended together — so the transcript isn’t speaker-split. The imported note carries a short callout saying so, so it’s never a surprise. (A rare export that happens to carry two separate audio tracks, like some Zoom recordings, does get the split automatically.)

A recording you forget to stop doesn’t run all afternoon. When both your microphone and the call’s audio have been quiet for five minutes, Oris stops the recording itself and transcription runs as normal. A minute before that happens you get a notification telling you it’s about to, so a long thinking pause is easy to rescue: make any sound and the countdown resets.

Change it, or turn it off, under Settings → Recordings → Auto-stop on silence. There’s a switch, the number of minutes, and a Warn me … seconds before it stops field for the heads-up. Changes apply from your next recording.

Sleeping your Mac mid-recording doesn’t count as silence. Oris recognizes the gap for what it is and starts the countdown fresh when you wake up, rather than stopping the recording the moment you open the lid.

There’s a macOS quirk worth knowing about if you work with the lid shut. When your Mac’s output is set to its built-in speakers and the lid is closed, system audio can’t be captured at all. You’d still hear the call, because the sound is coming out of your monitor or whatever else you have plugged in, but the recording would carry your voice and nothing else. You wouldn’t find out until the transcript arrived with only one side of the conversation in it.

Oris checks for that combination before a recording starts and refuses to begin, telling you which outputs you could switch to instead. Pick one of them in Control Center → Sound, or open the lid, and start again.

Changing where your Mac’s sound comes out in the middle of a meeting used to be the kind of thing that quietly cost you the other side of the conversation. Pair AirPods, plug in a USB audio interface, switch to an external display’s speakers, and the system-audio half of the recording is suddenly bound to a device that isn’t there any more.

Oris notices the switch and reconnects system-audio capture to the new device on its own, without stopping the session. No audio is lost across the change. From your perspective, the recording just keeps going.

Sample rates are re-read, not remembered

Reconnecting mid-recording raises a subtler question: the audio format of the system-audio stream can follow the new device. Switch from 48 kHz speakers to a 44.1 kHz interface and the samples arriving afterwards are 44.1 kHz. If Oris still believed 48 kHz, it would label them wrongly and resample by the wrong ratio. The result is audio that plays back roughly 9% fast, and a transcript made from a pitch-shifted recording.

So the format is read fresh rather than remembered. Oris re-reads it whenever reality can have moved: at the start of a recording, again after every device change, and again if the output device changes its own sample rate without the default device changing at all, which is what happens when you adjust the rate in Audio MIDI Setup, or an app like a DAW drives the device. A format that can’t be read, or that comes back nonsensical, is discarded in favour of the last known-good one rather than adopted.

One consequence is worth knowing about. macOS’s own audio encoder accepts sample rates only up to 48 kHz, so if your output device runs above that (a hi-res DAC at 96 kHz, or the headphone jack configured for 96 kHz in Audio MIDI Setup) the recording is encoded at 48 kHz rather than refusing to start. Nothing is lost that matters here: transcription downsamples to 16 kHz mono regardless.

Most Macs make this question boring. Built-in speakers, AirPods, a Bluetooth headset: macOS presents each of those to Oris as a playback device carrying nothing but playback, even when the hardware has a microphone, because the microphone shows up separately as its own input device. So when Oris captures the audio coming out of your machine there is only one stream to take.

Some hardware is not like that. A USB audio interface (a Focusrite Scarlett, MOTU M2, UA Volt, SSL 2, Audient iD4) is a single device carrying its inputs and its outputs together, and macOS presents it that way. So is a dock or a monitor with a built-in mic and speakers, a class-compliant USB headset, and a virtual audio device used as your output, which is what Loopback, BlackHole, and some conferencing apps install. On those, the audio Oris receives arrives as several streams at once: the device’s own inputs, and the system audio Oris actually wants.

Oris works out which stream is which before recording starts, by asking macOS to describe the streams it is about to receive and comparing that against the device it is recording through. It checks the answer rather than trusting it, and it re-checks whenever the picture can have moved, which is when you change output device mid-recording. If that check is inconclusive it tries a second one based on the channel layout.

What it will not do is guess. On this kind of hardware the stream sitting next to the one Oris wants is usually the device’s own input, which is often your microphone, so a wrong guess would quietly file your own voice as the other side of the conversation. If neither check can identify the meeting audio, Oris records nothing for the system track and tells you rather than filing something that looks right and is not.

What you should see

Nothing different. The “others” track holds the meeting, the “me” track holds your microphone, and the transcript separates them as usual. The point of this page is that the interesting cases already work, not that they need attention.

If you want to confirm it, the recorder’s log (~/.local/state/oris/audio-capture.log) records which stream it chose on the sys topology: line at the start of each recording, and again on the stats: line at the end.

Sample rates above 48 kHz

Oris encodes system audio through macOS’s own AAC encoder, and that encoder accepts sample rates only up to 48 kHz. If your output device runs higher, which happens with hi-res DACs and with the headphone jack when it is configured for 96 kHz in Audio MIDI Setup, the recording is encoded at 48 kHz instead of refusing to start. Your playback device is left exactly as you set it. Nothing that matters is lost: transcription downsamples everything to 16 kHz mono anyway.

When it still goes wrong

If the “others” track comes out empty or holds the wrong audio on an unusual setup, the fastest fix is to switch your output to the built-in speakers or a headset for the meeting. Then send the log along with the make and model of the device, because a device that defeats the checks above is worth fixing properly rather than working around.

If a recording keeps failing to write, rather than hiccupping once, and the reason turns out to be that the drive your recordings live on is full, Oris tells you rather than quietly losing audio. You get a single macOS notification reading Disk full — audio write failed. Recording may be losing audio. Free space and stop the recording.

One alert per recording, not a stream of them. Free up some space and stop the recording yourself, at which point the part that was written before the failure transcribes normally. A recording that hit this is still worth stopping properly rather than force-quitting.

Meeting audio adds up, so Oris clears out old recordings on its own. Settings → Recordings → Audio retention sets how long a recording is kept, in days, defaulting to 90. Set it to 0 and Oris stops clearing anything out on its own, leaving deletion as something you do deliberately from a row in the history. When a recording ages out, its audio and the working files that go with it are removed together.

Your notes are never touched. A note that links to the audio keeps its link, which Obsidian then shows as a broken one, so it’s obvious the source recording is gone rather than misplaced.

Cleanup happens when you start a new recording rather than on a schedule, so a long stretch away from Oris won’t churn through old files in the background.

The app’s recordings history shows where each recording stands. While retention is on, every row carries a countdown (“audio: 82d left”), which reads “audio pruned” once the file has gone. Set retention to 0 and no countdown appears at all, because nothing is going anywhere. Because the sweep only runs at the start of a recording, “0d left” means eligible rather than deleted: the file goes the next time you record. Rows also carry a Delete audio now action for clearing one out immediately. That one is worth reading the confirmation on, because deleting a recording’s audio also gives up the ability to retry its summary.

Whisper is known to invent text on silent audio, usually short stock phrases like “Thank you.”, “Thanks for watching.”, “All right.” or “Bye.” Because Oris transcribes your microphone and the call’s audio separately, a stretch where one side says nothing is a stretch where those phantoms would otherwise show up attributed to that side.

Oris catches them before they reach your note, using a curated list of the phrases Whisper reaches for alongside signals about whether there was any real speech in that stretch at all. The bar is deliberately high for anything conversational: short fillers like “okay”, “yeah”, “thank you” or “bye” only count as a phantom when they are the whole segment, so a real sentence that merely contains one of those words (“Okay, so let’s move the launch to Friday…”) is kept however long it runs. The stock video sign-offs (“thanks for watching”, “subscribe to my channel”) are treated more aggressively and matched anywhere in a segment, on the grounds that they are far likelier to be an artifact than something anyone said. If you spend your meetings talking about video scripts, that is the one case where a real line could go, and the recording is what you would check it against, for as long as you still have it: see Audio retention cleanup, which clears recordings after 90 days by default.

The filter runs on each side before the two are woven together, so the transcript you read is already clean.

If you take a call with the audio coming out of your laptop speakers rather than headphones, your microphone hears the other side as well as you do. Left alone, that lands the same sentence twice in the transcript: once cleanly on the others track, and once as a muddier echo on the me track, which reads as though you repeated everyone.

Two passes clean it up. The first is a text-similarity check that compares what the two tracks heard around the same moment and drops the near-duplicate from your track. The second is an independent check of whether your microphone actually heard speech at that point, which catches the leftovers the first pass is too cautious to remove.

Both run automatically on every recording. Headphones sidestep the problem entirely, because the mic never hears the far side in the first place.

The first time you hit record, macOS shows two click-Allow prompts, both labeled Oris: one for Microphone, the obvious one, and one for System Audio Recording, which is what lets Oris capture the other side of a call. macOS treats those as two separate permissions with different risks attached, so there is no single combined grant to click.

Grant them once and they stay granted. Every Oris update keeps the same signed identity, so an update never sends you back through the prompts. If you want them back deliberately, to re-test the flow or to hand the machine on, reset them yourself:

tccutil reset Microphone   com.shariqh.oris.recorder
tccutil reset AudioCapture com.shariqh.oris.recorder

Note the service name for System Audio Recording is AudioCapture, not SystemAudioCapture or kTCCServiceAudioCapture. As of macOS 26.4 that’s the name that works.

The notification prompt

There’s a third prompt, and it isn’t a TCC one: macOS asks separately whether Oris may post notifications. That’s what delivers the “Notes inserted” banner when a recording finishes, along with the auto-stop and summary-failed alerts. Oris only ever asks once, from a dedicated request during the walkthrough (and, for people who never run the walkthrough, at the start of your first recording). Nothing else in the app asks on the side, because macOS grants exactly one prompt and a request fired from the wrong place can burn it without ever showing you anything.

If notifications end up denied, macOS will not present that prompt again. The only way back is System Settings → Notifications → Oris → Allow Notifications. Oris doesn’t let that state hide: the walkthrough’s permission step flags it with a link straight to the pane and a Re-check button, and the app’s General tab carries a permanent Notifications row showing the same thing. Recording, transcription, and summaries all work normally without notifications; you simply don’t get the banner.

Getting Oris is a download, a drag into your Applications folder, and a double-click. There’s no terminal step and no second installer to go and find. The app opens into a guided walkthrough the first time you launch it and handles the rest from there, including putting the plugin into Obsidian for you if that’s where your notes live. Instead of a wall of settings, setup is a short tour:

1. Pick a destination. First the tour asks where your meeting notes should land, offering three cards: Obsidian vault (record from the Obsidian plugin), Markdown folder (any folder — no Obsidian needed), or Apple Notes (straight into Notes on this Mac). Choose the vault and Oris reads Obsidian’s registry and, when the answer is unambiguous (exactly one vault installed, or exactly one currently open), fills it in automatically; only when several vaults are present and none is clearly active does it ask you to pick from the detected list or browse to the folder. Choose a Markdown folder and any writable folder will do — no .obsidian directory required — plus a choice of how notes are named or appended. Choose Apple Notes and the tour explains the one permission macOS needs, asks for it, then lists your Notes accounts and folders to pick from. A line under the cards is honest about the limits: Notion is planned. See Destinations for the full picture. Continue stays disabled until the card you’ve selected is actually finished (a vault picked, a folder chosen, or Apple Notes set up through its permission-and-folder flow), so you can’t step past a destination that couldn’t deliver. If you already had Oris set up, this step says so and Continue is ready immediately; pick a different card and the same rule applies until that card’s setup is done.

2. Install the Obsidian plugin. Only when your destination is an Obsidian vault — pick a Markdown folder or Apple Notes and the tour skips this step entirely, since there’s no vault for a plugin to live in. When it does run, one step puts the recording controls inside Obsidian; the tour waits until Obsidian confirms the plugin is up, with live hints if anything needs a manual toggle. If Obsidian starts in Restricted Mode (which blocks community plugins by default), the tour surfaces the exact toggle to turn it on (Settings → Community plugins → Turn on community plugins) and waits for you to enable Oris.

3. Grant permissions. macOS asks twice here, once for the microphone and once for system audio, because Oris captures both sides of your calls. (An Apple Notes destination needs one more, for permission to control Notes, but that one is asked for back in step 1 where you chose it, not here.) The tour runs a test capture (~8 seconds, plays a chime so the system-audio track has something to hear) and checks both tracks. Missing or denied microphone access and a missing system-audio authorization are hard blocks, since those are required for recording to work. If the system-audio track was authorized but captured only silence during the test (sometimes happens with unusual audio routing), the tour shows a warning and lets you continue anyway; your microphone still records, so you can try a real recording and see whether the other side comes through. A quieter prompt follows, asking for permission to post notifications, which is how Oris tells you a recording finished and your notes landed. If notifications were already turned off for Oris (an earlier install, or a prompt dismissed before you got here), macOS will not ask again, so instead of failing silently the tour says so and offers a direct link to System Settings → Notifications plus a Re-check button once you have flipped it on. Recording works either way, so you can continue anyway; you just won’t see the “Notes inserted” banner.

4. Models prepare while you wait. Recordings are transcribed entirely on your Mac, so the first launch downloads and optimizes the on-device models in the background. A progress strip at the bottom of the step shows a percentage for each model as it downloads, then switches to an explicit Compiling for the Neural Engine label once the download finishes, so a bar sitting at 99% reads as “still working,” not stuck. When it’s done, the strip reports how long each phase took. Meanwhile the tour shows a sample note (summary, action items, decisions, open questions, and the speaker-labeled transcript) so you know exactly what you’ll get before you’ve recorded a thing. (Summaries can also use a cloud provider you configure; the audio itself is never sent to it.)

5. Record your first note. A three-line instruction plus an optional ~20-second read-aloud script, so your first real note lands while the tour is still open to celebrate it. The Back button is on the left; Finish is on the right.

Picking up where you left off. If you relaunch (or re-run) the tour after some steps are already done (destination chosen, plugin loaded, models downloaded), it doesn’t blink past them. A brief summary screen checkmarks everything that’s already set and points at the one step that still needs you, then lands there. The progress dots along the top turn into checkmarks as each step completes, and a Back button lets you step back through finished steps to review or change them without the tour pulling you forward again.

Re-learn the tour anytime. Oris menu → Reset Walkthrough restarts it from the top. Your settings, destination, downloaded models, and permission grants are untouched; it only forgets that you’ve seen the tour.

The home window. Once the walkthrough is done, launching the app takes you to its home window, which is where every setting lives from then on. See Settings for the tab-by-tab tour. The Obsidian plugin carries no provider or model settings of its own, so you configure all of it here.

Oris transcribes on your Mac, which means the first time it runs a model (and occasionally afterward) macOS has to prepare that model for the Neural Engine. That preparation is a one-time cost, but it can take a few minutes, and a silent few-minute wait is indistinguishable from a hang. This is the progress feedback that makes the wait legible.

During setup. The guided walkthrough’s model step shows a live strip: a download percentage for each model as it’s pulled down, and, once the download finishes, an explicit Compiling for the Neural Engine label so a bar sitting at 99% reads as “still working,” not stuck. When it’s done, the strip reports how long each phase took, so you can see where the minutes actually went.

During a recording. Most of the time the model is already warm and transcription starts instantly. But a model can go cold after a macOS update, or after a long stretch of not recording, and then Oris has to re-prepare it right when you stop a recording. When that happens the Obsidian status bar shows ⏳ preparing model…, so the wait reads as preparing rather than broken. It clears the moment real transcription begins.

Offline, once the model is on disk. Loading a downloaded transcription model is pure local work: Oris checks its own model cache first and reaches for the network only when that cache is genuinely missing something. A recording stopped on a plane, behind captive-portal Wi-Fi, or during an ISP blip transcribes exactly like one stopped on a healthy connection. The one transcription case that does need the network is a model that isn’t fully on disk yet (a first run, a switched model, an interrupted earlier download) — and then the status bar says ⬇ downloading model… honestly instead of leaving “preparing” to spin.

For longer meetings. A long transcript may call for a larger summarization model than the one set up during onboarding, and that larger model is fetched the first time it’s needed. That download can be several gigabytes, so instead of a silent pause the status bar shows ⬇ downloading model…, and since you may not be looking at Obsidian at all, Oris also posts a one-time notification telling you it’s downloading a summarizer model and your notes will follow when it’s done. Any live recording that needs a summarizer model Oris hasn’t downloaded before gets the same heads-up, and a longer recording calling for a bigger model is simply the most common reason. (An imported audio file can trigger the same first-use fetch, but shows it in its import progress indicator instead of this banner.) Once it’s downloaded it stays cached, so the wait is a one-time cost per model.

None of this needs any action from you. It’s feedback, not a step. The point is simple: whether it’s your very first recording or your longest meeting yet, Oris tells you it’s working instead of leaving you guessing.

After the setup walkthrough lands your first note, Oris offers an optional tour of what it can do. It’s never required: a small, dismissible prompt — “Take a 1-minute tour of what Oris can do?” — appears alongside the first-note celebration with Take the tour and Maybe later. Finishing setup works exactly the same whether or not you take it. (You can also reach the tour, or skip straight to your notes, right from the first-note step — before you record anything.)

The tour is a short, card-per-feature walkthrough — Next, Back, progress dots, and a Done. Each card explains one feature in a sentence or two and, where it helps, a concrete “try it now” nudge.

What the tour covers

The current tour walks through the shipped feature set:

• Recording basics — how you start and stop a meeting, which depends on the destination you chose during setup. In an Obsidian vault: click the mic icon in the left ribbon to start, click it again to stop; a marker drops into your note and the transcript lands there when it’s done (there’s no default keyboard shortcut — bind one yourself under Settings → Hotkeys if you’d like). For a Markdown folder: click Start recording in the strip at the top of the Oris app, click Stop when you’re done, and when the recording finishes Oris writes it into your folder the way that destination places notes — a new file named by your pattern, or appended to the single note you chose. See Recording without Obsidian.
• Both sides, no bot — Oris captures your microphone and the call’s audio together and labels them “me” and “others.” Nothing joins the meeting, and the audio is transcribed on your Mac.
• Auto-stop on silence — a recording you forget to stop ends itself after 5 minutes of silence on both sides, with a heads-up notification 60 seconds before.
• Record, then carry on (Obsidian destinations) — the moment you start recording you’re free to switch notes, rename this one, even quit Obsidian; the recorder runs on its own and the transcript follows its marker back into place.
• Troubleshooting & recovery — if a summary can’t be generated the transcript still lands and the failure is called out, and you can retry it once you’ve fixed the cause: from Obsidian’s command palette, or from Recordings → See all recordings… in the app, which is the route that always works. In a vault you also get orphaned-marker recovery, for a note that wandered off mid-transcription.
• Quick Note — press your quick-note hotkey anywhere on your Mac (⌃⇧Space by default), say the thing, and the text is filed without opening anything; captures land in an in-app inbox by default, or straight into a note you pin or a daily or weekly note. See Quick Note.
• Import & reshape transcripts (Obsidian destinations) — bring in a transcript you already have (a .vtt/.srt caption file, an Otter export, a meeting tool’s download) and Oris formats and summarizes it like a recording you made here.

The Quick Note and Import & reshape cards appear only when the matching capability is present in your install, and the import card lists only the parts that are actually available, so the tour never advertises a feature you don’t have. Quick Note’s card shows once voice capture is enabled. Cards like this light up on their own once their capability ships, so there’s no separate update to chase.

The same rule covers your destination. The tour teaches the flow you actually chose: a Markdown-folder setup is never told to click Obsidian’s ribbon icon or to run a command from Obsidian’s command palette, and the cards that only make sense inside a vault — the marker that follows a renamed note, orphaned-marker recovery, importing transcripts — are simply not shown. Change your destination and the tour changes with it, since it reads the destination when you open it rather than when the app starts.

Only what’s new — no forced replays

The tour is built so a returning user is never marched back through steps they’ve already seen. Oris remembers which cards you’ve been through (separately from the setup walkthrough’s own state). If a later update adds a new feature, the next launch surfaces an opt-in “We added something new — take a look?” rather than replaying the whole tour. If you’ve already seen everything, you’re not prompted at all.

Re-open it any time

You can open the tour whenever you like from the Oris app’s General tab — the Feature tour button is always there. When there are cards you haven’t seen yet (for example, after an update added a feature), a small New badge appears beside it. Declining (“Maybe later”) just stops the prompt from nagging — it doesn’t hide the tour from the General tab.

Oris checks for updates automatically — once a day, in the background. When a new version is available, it lets you know with a quick prompt that shows a short “What’s new” summary of what changed; one click downloads the cryptographically verified update and installs it. You don’t need to visit a download page or run a script.

What updates, what stays put

The update replaces the app and refreshes the Obsidian plugin bundled with it (see below). Your notes, recordings, configured providers, API keys, and the on-device models are all untouched. Oris’s promise that it never sends your audio anywhere carries forward unchanged through every update.

Keeping the Obsidian plugin in sync

The Obsidian plugin ships inside the app, so each app build carries a matching plugin. When you launch the app it keeps your vault’s plugin matched to the installed app — normally that means copying in a newer plugin after an update, but it also means restoring the matching plugin if you ever roll the app back, so the plugin and the app version it talks to never drift apart. You don’t reinstall anything. Obsidian keeps running the previously loaded plugin until it’s reloaded, so the next time you’re in Obsidian you’ll see a quick “Oris updated — reload to apply” prompt with a Reload now link. One click swaps in the matching plugin; until then, recording keeps working with the version already loaded.

Verification

Every update is code-signed with a Developer ID certificate and notarized by Apple before it’s published. On top of that, Oris uses Sparkle’s Ed25519 signature scheme: each download is signed with a private key that never leaves the maintainer’s control, and the app verifies the signature cryptographically before installing anything. A tampered or corrupted file is rejected.

Checking manually

Both controls live under Settings → General → Updates: an Automatically check for updates toggle, on by default, and a Check for Updates… button for checking right now. The same manual check sits in the Oris menu → Check for Updates…. Either one contacts the update server, tells you whether a new version is there, and offers to install it.

Turn the toggle off and Oris stops checking on its own; the manual button still works whenever you want it.

Oris is an ordinary Mac app, so removing it is the ordinary thing: quit Oris, then drag Oris from your Applications folder to the Trash. Nothing else has to be undone first.

Your notes and your recordings are not part of the app. They are your own files, they live in your vault and in the recordings folder, and they stay exactly where they are. Uninstalling removes the tool that produced them, not the work.

What stays behind. Two things outlive the Trash. The Obsidian plugin stays installed in the vault, where you remove it the way you remove any community plugin, under Settings → Community plugins in Obsidian. And your Oris settings are kept outside the app, deliberately, so that an update never loses them. If you reinstall later, the app opens straight to its home window with everything as you left it rather than starting the walkthrough again.

Clear your API keys before you uninstall, not after. Those settings include any provider keys you pasted in, and they survive the app being deleted. So if you’re passing the Mac on, selling it, or just done with a provider, do this while Oris is still installed: open Settings → Summarization, empty the API key field on every provider card you filled in, and wait for the Settings saved confirmation. There’s no Save button, so clearing the field is the whole action. Then quit and drag the app to the Trash. Doing it in that order is the difference between a key that’s gone and a key that’s still sitting on a machine you no longer own.

If something is wedged, start with the walkthrough. A full uninstall is rarely what you actually want. Settings → General → Re-run walkthrough steps you back through vault, plugin, permissions, and models without touching a single setting, and it fixes most of what a reinstall would have fixed. See Guided walkthrough.

Making macOS ask about the microphone again. Removing the app does not remove the permissions you granted it. If you want the microphone and system-audio prompts to appear from scratch, reset them explicitly: see Microphone and System Audio Recording permissions.