How to transcribe Zoom, Meet, and Teams without a bot in the participant list

The audio you need to transcribe a Zoom meeting is already playing on your computer. You don't need a bot to fetch it. You don't need the Zoom API. You don't even need permission from the host.

On Mac and Windows, the operating system will hand you that audio directly — through ScreenCaptureKit and WASAPI loopback respectively. Nothing joins the call. Nothing appears in the participant list. The other side sees a normal participant, because that's all there is.

This article explains how to transcribe Zoom meetings without a bot — and do the same for Google Meet and Microsoft Teams — using system audio instead of the Zoom API. CatchMeet, which we built, shows up later as one implementation of the approach, not the headline.

Disclosure: we build CatchMeet. The capture method below is the approach. CatchMeet is one implementation of it.

Why a bot in the participant list is a problem

When a transcription bot joins a meeting, it becomes a participant. That sounds harmless until the practical consequences become clear:
`

`
There's also a practical limitation: bots join as a separate identity. They aren't the participant. They don't have the participant's microphone, audio context, or local playback. They capture a stream the platform gives them — if the platform gives them one at all.

The alternative is to capture the audio on the participant's side. That's what system audio capture does.

The core idea: system audio, not Zoom API

There are three common ways to get meeting audio for transcription:
`

`
The Zoom API is the official path. It's powerful for cloud recordings, calendar automation, and enterprise compliance. But it requires scopes, approvals, and often a paid plan. It doesn't give a universal live audio stream for every meeting type, and it certainly doesn't help with Google Meet or Microsoft Teams.

System audio is different. It captures whatever the computer is playing — the incoming voices from Zoom, Meet, or Teams — directly from the output device. From the platform's perspective, nothing unusual is happening. It's just a participant with speakers on.
`

`
That's the key insight: a bot isn't necessary, and neither is the Zoom API. What's needed is the audio that's already coming out of the machine.

How system audio capture works on Mac — ScreenCaptureKit

On macOS, the modern way to capture system audio is ScreenCaptureKit. Apple introduced it in macOS 12.3, but the functionality evolved significantly across versions.
`

`
The minimum practical version: for reliable per-application system audio capture, macOS 14.2 is the realistic floor. On 12.3–14.3, system audio can be captured, but it will be a mix of everything playing — not just the meeting.

Known issues: developers have reported crashes with EXC_BAD_ACCESS during system audio capture on certain configurations. There's also a privacy alert on macOS 15 that appears when an app requests to bypass the system private window picker — this is normal and expected.

What the other side sees: nothing new. The participant is still just a participant. Zoom, Meet, and Teams don't know system audio is being captured, because the capture happens at the OS level, below the meeting app.
`

`
Limitations: the right macOS version, the system audio recording permission, and a stable output device are required. If audio devices are switched mid-call, the capture may need to be restarted. And critically — ScreenCaptureKit does not separate audio by participant. It mixes all remote voices into a single system audio stream.

How system audio capture works on Windows — WASAPI loopback

On Windows, the equivalent is WASAPI loopback. WASAPI (Windows Audio Session API) lets an application capture the audio being sent to an output device without a virtual cable.

In practice:

• The app enumerates audio output devices.
• It opens the selected device in loopback mode.
• It receives the same audio the user hears — including remote participants' voices in Zoom, Meet, or Teams.
• The transcription engine processes that stream.

What the other side sees: again, nothing. No bot joins. No notification fires.

The hard parts — and how to handle them:
`

`
Details on each:

• Exclusive mode. If Teams or another app has exclusive control of the audio device, WASAPI loopback will fail to capture. The fix is to disable exclusive mode in Sound Settings → Device Properties → Advanced, or use per-process loopback to target the meeting app directly.
• Sample rate mismatch. If the capture client is set to 44.1 kHz but Teams forces the hardware to 48 kHz, the engine may drop the connection. Modern libraries handle some of this automatically — NAudio 3, for example, now adapts bit depth and channels in exclusive mode, leaving only sample-rate mismatches for upstream resampling. In stubborn cases, a virtual audio cable remains the industry-standard fallback.
• Process targeting. Teams spawns multiple processes. Hooking the UI shell process instead of the Media Foundation process yields zero bytes. Since Windows 10 build 19041, per-process loopback with PROCESS_LOOPBACK_MODE_INCLUDE_TARGET_PROCESS_TREE captures the entire process tree.

`

`
Limitations: the output device must be active. Exclusive-mode audio can block loopback. And like ScreenCaptureKit, WASAPI loopback gives a mixed stream — not per-speaker audio.

The diarization problem (and what to do about it)

This is the part most articles skip. System audio capture gives a single mixed stream of all remote participants. It does not indicate who said what.
`

`
Why it's harder: platform APIs often provide participant metadata — names, join times, speaker events. System audio capture gives none of that. It provides the audio waveform and nothing else.

What can be done:
`

`

What doesn't work: expecting the OS to magically separate speakers. Neither ScreenCaptureKit nor WASAPI loopback does this. A separate layer is required.

What the other side sees

This is the part most people care about, so precision matters.

When system audio capture is used for transcription:
`


But here are the scenarios people actually search for:


`
What if the host enables recording? Then Zoom, Meet, or Teams will show a recording indicator to everyone. That indicator is about the platform's own recording, not local capture. Transcription continues unaffected.

What if the meeting has DLP enabled? Enterprise DLP tools in Teams, Slack, and Zoom are built for chat and file content, not live audio streams. Native DLP typically cannot inspect voice or screen-share content. That said, some organizations deploy endpoint monitoring that can detect unusual audio capture. Company policy should be checked.

What if Zoom has audio watermarking enabled? Zoom can embed an inaudible watermark in the audio played through each participant's speakers. If someone records the meeting with a separate microphone or third-party tool and shares the audio, Zoom can potentially identify which participant was responsible. Local and cloud recordings made directly through Zoom do not contain this watermark.

What if someone complains? That's a legal question, not a technical one. See below.

What can give it away: sharing the screen with the transcription window visible, or using speakers so the microphone picks up the transcription audio. Headphones avoid the latter.

Consent: the part that can't be skipped

System audio capture is invisible to the platform. But invisibility is not the same as legality.
`

`
In the United States, federal law operates on a one-party consent basis — it's legal to record if at least one person in the conversation is aware and consents. But over a dozen states, including California, Florida, and Pennsylvania, require all-party consent. California's Invasion of Privacy Act is particularly broad: it prohibits not just recording, but also "reading, attempting to read, or learning" the contents of communications without all parties' consent.

Recent lawsuits against AI notetakers like Otter.ai have focused on exactly this gap. Plaintiffs allege that Otter's notetaker joins meetings, records conversations including those of non-users, and uses the data to train machine learning models — all without proper consent or disclosure.
`

`
What this means in practice: if transcribing a meeting with participants in all-party consent states, or in multiple jurisdictions, the strictest rule applies. Participants should be told. Their permission should be obtained. The absence of a bot doesn't remove that obligation.

Corporate policies: some organizations explicitly prohibit third-party transcription tools. One policy states: "Personal AI transcribers or any other third-party transcription tools are strictly prohibited during group calls." Company rules should be checked before capturing anything.

Step-by-step: transcribe Zoom, Meet, and Teams without a bot

Before starting

`

`

Mac — ScreenCaptureKit

`

`

Windows — WASAPI loopback

`

`

Zoom, Google Meet, Microsoft Teams

`

`

• What's common: all three play remote audio through the system output. System audio capture works identically.
• Breakout rooms: system audio captures whatever is heard. In a breakout room, that room's audio is captured. In the main room, breakout rooms aren't heard — and neither is the capture.
• Corporate accounts: some organizations restrict third-party apps. System audio capture is unaffected, since it runs locally — but company policy may still prohibit it.

CatchMeet as one implementation

CatchMeet is a practical example of how this approach comes together. It uses ScreenCaptureKit on Mac and WASAPI loopback on Windows to capture system audio. It transcribes locally, without joining the meeting as a participant, and without the Zoom API.
`

`
What CatchMeet doesn't do: it doesn't connect to Zoom, Meet, or Teams as a bot. It doesn't appear in the participant list. It doesn't require host approval. It's one way to implement the system-audio approach — not the only way.

For those who'd rather not assemble the pieces themselves, CatchMeet is a reasonable starting point.

Limitations and when a bot or API is still better

System audio capture is powerful, but it isn't universal.
`

`
When it doesn't fit:

• Meetings where audio isn't played locally (server-side recording, fully automated pipelines with no human present).
• Scenarios where the computer is off or the meeting runs on a device that isn't controlled.
• Situations requiring per-speaker audio without additional diarization work.

When the Zoom API is better:

• Enterprise compliance and cloud recording retrieval.
• Calendar-driven automation.
• Workflows that need official platform data.

When a bot is better:

• Large-scale automated meeting capture where a visible participant is acceptable.
• Platforms or configurations where the API doesn't provide the audio needed.

Trade-offs of system audio: requires an active machine, depends on OS permissions, diarization is harder, and consent compliance is the user's responsibility.

FAQ

How do I transcribe Zoom meetings without a bot?
Capture system audio on the local machine using ScreenCaptureKit on Mac or WASAPI loopback on Windows. The transcription happens locally, and no bot joins the meeting.

Will the other side know I'm transcribing?
Not from the participant list or a bot notification. But if the law requires informing participants, do so. Using headphones also prevents audio leakage through the microphone.

Does system audio capture work with breakout rooms?
Yes — whatever audio plays through the speakers or headphones is captured. In a breakout room, that room's audio is captured. In the main room, breakout rooms aren't heard, and neither is the capture. A bot can't follow a participant into a breakout room unless the host explicitly allows it; system audio capture follows automatically.

What happens if the host enables recording?
The platform shows a recording indicator to everyone. That indicator is about the platform's built-in recording, not local capture. Transcription continues unaffected.

Does corporate DLP detect system audio capture?
Native DLP in Teams, Slack, and Zoom is built for chat and file content, not live audio streams. It typically cannot inspect voice or screen-share content. However, some organizations deploy endpoint monitoring that may detect unusual audio capture. Company policy should be checked.

Can I transcribe Google Meet and Microsoft Teams the same way?
Yes. System audio capture is platform-agnostic. If the audio plays through the output device, it can be captured.

Does CatchMeet join as a participant?
No. It captures system audio locally and does not appear in the participant list.

Is it legal to transcribe a meeting without telling participants?
It depends on the jurisdiction. Federal law in the US operates on one-party consent, but over a dozen states require all-party consent. California's CIPA is particularly broad. When in doubt, tell people and get permission.

What about diarization — who said what?
System audio gives a mixed stream. A transcription engine with built-in diarization (AssemblyAI, Deepgram, Rev) is needed to separate speakers. Even then, mapping speakers to names requires additional work.

Does this work on macOS 12 or 13?
System audio capture works from macOS 12.3, but reliable application-specific capture requires macOS 14.2 or later. On older versions, all system audio is captured, not just the meeting.

Does this work on Windows 10?
Per-process loopback requires Windows 10 build 19041 (version 2004) or later. Basic WASAPI loopback works on earlier versions, but exclusive-mode or sample-rate issues may appear.

Conclusion

A bot in the participant list isn't necessary to transcribe a meeting. The Zoom API isn't necessary either. What's needed is system audio — the audio the computer is already playing — captured at the OS level.
`

`
On Mac, that's ScreenCaptureKit (macOS 14.2+ for reliable app-specific capture). On Windows, that's WASAPI loopback (with per-process targeting on build 19041+). The other side sees a normal participant, because that's all there is.

CatchMeet is one implementation of this approach. For anyone looking to transcribe Zoom meetings without a bot, it's a reasonable place to start.