Sayli ships from one codebase to Windows, macOS, and Linux. Most of it behaves identically everywhere. Four things do not, because they depend on what the operating system allows rather than on us: whether the Sayli window can be kept out of a screen capture, how Sayli hears the other side of the call, what you have to grant before it can, and whether Sayli can notice a call starting on its own.
This page is the single statement of that. Section 2.7 of the Terms points here, and the app itself reports what your own device can do, in Settings and in the live window.
- On a screen share
- The window is removed from the capture entirely. On an older Windows 10 build it becomes a blank region instead, which is visible as a black box.
- Hearing the call
- The call is captured through WASAPI loopback.
- What you grant
- Microphone is a privacy switch in Windows Settings, not a prompt. System audio needs no permission.
- Noticing a call starts
- Sayli notices the Zoom, Teams or Webex app using your microphone and offers to turn itself on. Calls in a browser tab are not noticed.
- Builds
- Installer, 64-bit and ARM
- On a screen share
- On macOS 26 and later the window is removed from the capture. We measured it, and it holds in current Zoom and Teams. On macOS 13 to 15 Sayli makes the same request, but we have not confirmed that every screen-share app honours it there, so some may still show the window.
- Hearing the call
- On macOS 14.2 and later the call is captured through a CoreAudio process tap. On 13.0 to 14.1 it goes through ScreenCaptureKit.
- What you grant
- Microphone, plus System Audio Recording Only on macOS 14.2 and later. On 13.0 to 14.1 the system audio path needs Screen Recording instead.
- Noticing a call starts
- Sayli notices the Zoom, Teams or Webex app, or a browser, using your microphone and offers to turn itself on. No permission is needed.
- Builds
- Apple Silicon and Intel
- On a screen share
- The Sayli window cannot be removed from a screen capture on Linux. Neither X11 nor Wayland has a way to exclude a window, so there is nothing to ask for. Share a single window rather than your whole screen, or keep Sayli on a display you are not sharing.
- Hearing the call
- The call is captured through the PulseAudio monitor source, which PipeWire also serves.
- What you grant
- No operating-system permission gates the microphone or system audio. Sayli needs a keyring (gnome-keyring or kwallet) to keep you signed in between launches.
- Noticing a call starts
- Sayli notices the Zoom, Teams or Webex app using your microphone and offers to turn itself on. Calls in a browser tab are not noticed.
- Builds
- AppImage and .deb
About the screen-share claim
This is the one place we will not round up.
Windows gives us a real exclusion. From Windows 10 version 2004 onward, an app can ask the compositor to leave a window out of every capture, and Sayli does. The window is not in the recording, not in the share, not in the screenshot. On an older Windows 10 build the same call produces a blank region instead, which the other side sees as a black box.
macOS 26 and later gives us all of it. Sayli marks its window as not-for-sharing and macOS leaves it out of the capture. We measured it directly, and it holds in current Zoom and Teams. On macOS 13 to 15 Sayli makes the same request, but we have not confirmed that every screen-share app honours it on those versions, so treat it as partial there: some may still show the window.
Linux gives us none of it. There is no per-window exclusion in X11 and none in Wayland either. This is not a missing feature we have not got to; the request does not exist in the protocol. On Linux, share a single window rather than your whole screen, or keep Sayli on a display you are not sharing.
No bot joins your meeting. Nothing dials in, no participant appears, and no recording banner is shown to the room, because Sayli captures on your own machine rather than joining the call. That part does not depend on your operating system. What depends on your operating system is only whether the Sayli window can be kept out of a capture you start yourself.
Hearing the other side
Your microphone gives Sayli your voice. The other side arrives as system audio, and every operating system routes that differently.
WASAPI loopback. Nothing to grant, nothing to configure.
A CoreAudio process tap. macOS asks once, inline, for "System Audio Recording Only". Granting takes a click and no trip to System Settings.
ScreenCaptureKit, which macOS gates behind the Screen Recording permission instead. Same result, older mechanism.
The PulseAudio monitor source, which PipeWire also serves. No permission gate. If no monitor source exists, Sayli says so and runs on your microphone alone rather than pretending it heard the room.
Noticing that a call has started
Every meeting app opens your microphone when you join. Sayli watches for that, asks no permission to do it, and offers to turn itself on. It never reads your screen, your window titles or your browser tabs to decide.
Turn it off in Settings, under Meetings, and Sayli never checks. For anything it cannot notice, start Sayli yourself, or turn on "Launch Sayli at login" so it is already running. The countdown before a scheduled call and the Coming up list come from your connected calendar on every platform.
Staying signed in
On Windows and macOS your session lives in the operating system's own
credential store. On Linux, Sayli uses the desktop keyring. If no keyring is
installed, Sayli refuses to write your session to disk rather than storing it
in something only pretending to be encrypted, which means you sign in again on
each launch. Installing gnome-keyring or kwallet fixes it for good.
Builds
Sayli updates itself. It checks on launch and again while it runs, then offers to restart into the new version.