Dominic Böttger
← Back to blog

Optimize Microsoft Teams on Omarchy with a Proper Chromium PWA

Published on April 18, 2026 by Dominic Böttger (today) · 5 min read

Microsoft does not ship a native Teams client for Linux anymore. On Omarchy — Arch + Hyprland — the best option is Teams as a Chromium Progressive Web App. Done right, it uses less RAM than the old Electron client, sees the right camera and screen, and stays locked to the work profile you actually want.

This is the setup I landed on after polishing it: a real installed PWA, launched from a custom .desktop entry into a specific Chromium profile, with Wayland screen capture and AMD/Intel VA-API hardware decode and encode enabled.

The problem with the default launcher

Omarchy’s omarchy-launch-webapp helper wraps Chromium with --app=<URL>. That gives you a chrome-less window — but:

  • It does not pick a Chromium profile, so Teams attaches to whatever profile happens to be current.
  • It is not a registered PWA, so the window identity (StartupWMClass) falls back to the generic chromium class, and flags like --app-id= can not target the window.
  • Flags like --app-id= can not target it because there is no manifest in Chromium’s web-app registry.

The fix is to install Teams as a real PWA once, then point the .desktop entry at its app-id.

Step 1: install Teams as a real PWA

  1. Open Chromium in the profile you want Teams tied to (mine is the Default profile, labelled Work).
  2. Navigate to https://teams.microsoft.com and log in.
  3. In the URL bar, click the install icon (or Menu → Cast, save, share → Install Teams).

Chromium now writes a manifest under ~/.config/chromium/<Profile>/Web Applications/Manifest Resources/<app-id>/ and an auto-generated launcher at ~/.local/share/applications/chrome-<app-id>-Default.desktop. Grab the id:

ls ~/.config/chromium/Default/Web\ Applications/Manifest\ Resources/

On my machine that returned ompifgpmddkgmclendfeacglnodjjndh. Yours may differ because the id is derived from the manifest URL and the profile.

Step 2: point a stable .desktop entry at the PWA

Omarchy’s own Teams.desktop lives at ~/.local/share/applications/Teams.desktop. Replace the Exec line so it bypasses omarchy-launch-webapp and launches Chromium directly — with the profile pinned and the PWA referenced by app-id:

[Desktop Entry]
Version=1.0
Name=Teams
Comment=Teams
Exec=/usr/bin/chromium --profile-directory=Default --app-id=ompifgpmddkgmclendfeacglnodjjndh
Terminal=false
Type=Application
Icon=/home/you/.local/share/applications/icons/Teams.png
StartupNotify=true
StartupWMClass=chrome-ompifgpmddkgmclendfeacglnodjjndh-Default

Two details matter:

  • --profile-directory=Default forces the Work profile regardless of what Chromium is currently doing. Profile names in ~/.config/chromium/Local State look like Default, Profile 1, etc.; match the folder name, not the display name.
  • StartupWMClass=chrome-<app-id>-<profile> is the window class the compositor actually reports (confirm with hyprctl clients). Chromium’s own auto-generated launcher uses crx_<app-id> here, which is an X11-era artifact — on Wayland the real class carries the profile suffix. Setting the matching value means Walker’s startup notification, any window-switcher, and later automation all see the PWA as a first-class app instead of a generic chromium window.

Hide the duplicate Chromium-generated launcher so the app drawer shows only yours:

sed -i '/^Name=Microsoft Teams (PWA)/a NoDisplay=true' \
  ~/.local/share/applications/chrome-ompifgpmddkgmclendfeacglnodjjndh-Default.desktop
update-desktop-database ~/.local/share/applications

Step 3: install VA-API drivers for hardware video

Video calls burn CPU unless Chromium can offload decode and encode to the GPU. On Arch you need libva plus the matching driver:

# AMD (Radeon 880M / 890M etc.)
sudo pacman -S --needed libva libva-mesa-driver libva-utils

# Intel (modern iGPUs)
sudo pacman -S --needed libva intel-media-driver libva-utils

Verify:

vainfo

You want to see VAProfileH264* with both VAEntrypointVLD (decode) and VAEntrypointEncSlice (encode). Also VP9Profile0 if possible — Teams negotiates VP9 in recent builds.

Step 4: Chromium flags for Wayland and Teams

Put these into ~/.config/chromium-flags.conf (Chromium on Arch reads this on launch):

--ozone-platform=wayland
--ozone-platform-hint=wayland
--enable-features=TouchpadOverscrollHistoryNavigation,WebRTCPipeWireCapturer,VaapiVideoDecodeLinuxGL,VaapiVideoEncoder
--ignore-gpu-blocklist
--enable-zero-copy

What each one does:

  • --ozone-platform=wayland / --ozone-platform-hint=wayland: run natively on Wayland. No XWayland round-trip, sharper HiDPI, proper cursor scaling.
  • WebRTCPipeWireCapturer: use the PipeWire portal for screen sharing. Without it, Chromium tries to grab X11 windows and the share-picker is empty.
  • VaapiVideoDecodeLinuxGL / VaapiVideoEncoder: wire Chromium’s WebRTC pipeline to VA-API for H.264 / HEVC / VP9 / AV1 decode and encode.
  • --ignore-gpu-blocklist: bypass the conservative driver blocklist, which still refuses some working setups.
  • --enable-zero-copy: skip an extra frame copy between the decoder and the compositor — noticeable on iGPUs.

Restart Chromium completely (pkill -x chromium and relaunch — flags are only read at startup).

Step 5: verify the stack is live

Open chrome://gpu in a normal Chromium window and check:

  • Video Decode and Video Encode: both should read Hardware accelerated.
  • WebRTC: should list the PipeWire capturer.
  • Compositing: hardware accelerated, Vulkan or OpenGL backend.

Then open Teams from Walker, start a meeting, and check nvtop or radeontop. During a call you should see decoder and encoder activity on the GPU while CPU stays low. On my AMD 890M idle Teams with camera on drops from ~35% CPU to about 12% with VA-API engaged.

Why this is worth doing

Treating Teams as a first-class PWA rather than a URL shortcut gives you three wins at once:

  1. Correct profile every time — no more accidentally posting into the wrong tenant because Chromium opened against the last-used profile.
  2. Stable window identity — hyprctl clients shows a predictable class, so any future automation or per-app rule has something reliable to match on. (Note: mako still shows notifications as Chromium — the browser does not forward the PWA name to the notification daemon.)
  3. Real hardware acceleration — half the CPU load and a much cooler laptop during long meetings.

The whole setup is under twenty lines of config once you know which ones.

Written by Dominic Böttger

← Back to blog

Comments are powered by GitHub Discussions. A GitHub account is required to comment.

Recent Blogposts

to blog