PluelyPluelyDocs

Getting Started

Linux Permissions for Pluely: Mic & Screen Capture Setup

Linux doesn't have one unified permission system the way macOS and Windows do — what you need to check depends on your audio server (PipeWire or PulseAudio) and your display server (X11 or Wayland), which in turn depend on your distribution and desktop environment. This page covers the two things Pluely v1 needs — microphone input and screen capture — and how to verify each on a typical modern Linux setup.

Microphone via PipeWire or PulseAudio

Most current Linux distributions route audio through PipeWire (often with PulseAudio compatibility) or plain PulseAudio. Pluely v1 needs a working input device selected in this layer to hear you in Listen mode and for push-to-talk.

Check your input device is present and selected:

  • Open your desktop's Sound settings (the exact path varies — for example GNOME's Settings → Sound, or KDE's System Settings → Audio) and confirm the correct microphone is chosen as the input device, and that its input level moves when you speak.

  • From a terminal, you can list audio sources directly. On a PipeWire or PulseAudio system:

    pactl list short sources

    Look for your microphone in the list and make sure it isn't muted.

Permission model varies by distro/desktop: Some distributions use PipeWire's session/portal permissions to gate microphone access per application (similar in spirit to macOS), prompting the first time an app requests audio. Others rely entirely on ALSA/PulseAudio device permissions with no per-app prompt at all — if the device is unmuted and selected, any app including Pluely can use it. If you're unsure which model your system uses, the safest first step is always the Sound settings panel above.

Symptom if missing or misconfigured: Listen mode shows no waveform movement for your voice and never transcribes your side of a conversation; push-to-talk does nothing when held.

Screen capture and portal permissions (especially on Wayland)

Screenshots in Ask mode, and capturing system audio for the other side of a call in Listen mode, depend on your display server:

  • X11 sessions generally allow screen capture more freely, with fewer prompts.
  • Wayland sessions route screen capture through xdg-desktop-portal (and a backend specific to your desktop, such as the GNOME or KDE portal implementation). The first time Pluely requests a screen capture, your desktop should show a portal permission dialog asking you to pick a screen, window, or region to share, and possibly to remember your choice. If this dialog never appears, or you dismissed it once and it's now silently denying, that's usually the culprit.

How to check/reset portal permissions: The details vary by desktop environment, but the general approach is:

  1. Confirm xdg-desktop-portal (and the desktop-specific backend, e.g. xdg-desktop-portal-gnome or xdg-desktop-portal-kde) is installed — it ships by default on most modern distributions but can be missing on minimal installs.
  2. Look for a screen-sharing or remote-desktop permission setting in your desktop's privacy settings, where previously denied permissions for an app can sometimes be reset.
  3. If a portal prompt was dismissed rather than answered, try the capture again in Pluely to re-trigger it.

Symptom if missing: Screenshot capture fails, returns a blank image, or nothing happens when you try to attach a screen capture; in Listen mode, only your own microphone transcribes and the other side of the call never appears.

When in doubt, check the input device first

Because Linux configurations vary so widely, the fastest diagnostic is almost always confirming, at the audio-server level, that a microphone is selected, unmuted, and showing input — that isolates whether an issue is audio configuration versus a screen-capture/portal permission, which need different fixes.

Last updated 2026-07-10 · pluely.com