After steam-jupiter-stable replaced the regular steam package on a recent CachyOS Handheld Edition update, Steam now triggers a KDE screencast/screen-share portal permission prompt every time it autostarts on dropping from gamescope game mode to the regular desktop session. This happens with no Remote Play action taken, and cannot currently be suppressed.
Background
The update that introduced this:
steam-jupiter-stable-1.0.0.85-10 and steam-1.0.0.85-7 are in conflict. Remove steam?
Autostart entry that launches Steam on desktop session entry:
/etc/xdg/autostart/steam.desktop
Exec=/usr/bin/steam -silent -steamdeck
Steps to Reproduce
Run steam-jupiter-stable on a KDE Plasma/Wayland desktop session (not inside gamescope)
Launch via the autostart entry above, or directly: steam -silent -steamdeck
A KDE system permission dialog appears asking to share the screen with Steam, with no Remote Play or broadcast action taken
What's Been Ruled Out
Remote Play disabled in Steam settings — prompt still occurs
-nopipewire flag (documented for the standard Linux client) — no effect on this build
steamos-manager — checked both user and root daemon logs (journalctl --user -u steamos-manager, sudo journalctl -u steamos-manager) at time of prompt; no screencast/portal activity logged
Stale Steam process — confirmed via ps aux no lingering instance was interfering; tested clean launches after pkill -9 steam
Additional Detail: Possible Portal-Side Bug
xdg-desktop-portal-kde 6.7.0 logs marshalling errors at the time screencast is requested/denied:
QDBusMarshaller: cannot add a null QDBusVariant
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid QVariant passed in arguments
Namespace "org.kde.kdeglobals.General" is not supported
The portal's permission store screencast table remains empty even after repeatedly denying the prompt:
$ busctl --user call org.freedesktop.impl.portal.PermissionStore /org/freedesktop/impl/portal/PermissionStore org.freedesktop.impl.portal.PermissionStore List s screencast
as 0
This suggests denials aren't being persisted — possibly a separate portal-side bug — but the practical effect is there's currently no way to permanently dismiss the prompt through normal KDE permission management. The Plasma 6.5+ Application Permissions panel is also non-functional/greyed out on this system, likely for the same underlying reason.
Expected Behavior
Steam should not request screencast capture on a normal desktop-mode autostart without an active Remote Play/broadcast session, and/or -nopipewire should suppress this on Jupiter-flavored builds the same way it does on the standard Linux client.
Your system information
tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs] logs attached as tar.gz archivelogs.tar.gz
Summary
After
steam-jupiter-stablereplaced the regularsteampackage on a recent CachyOS Handheld Edition update, Steam now triggers a KDE screencast/screen-share portal permission prompt every time it autostarts on dropping from gamescope game mode to the regular desktop session. This happens with no Remote Play action taken, and cannot currently be suppressed.Background
The update that introduced this:
steam-jupiter-stable-1.0.0.85-10 and steam-1.0.0.85-7 are in conflict. Remove steam?
Autostart entry that launches Steam on desktop session entry:
/etc/xdg/autostart/steam.desktop
Exec=/usr/bin/steam -silent -steamdeck
Steps to Reproduce
What's Been Ruled Out
Additional Detail: Possible Portal-Side Bug
xdg-desktop-portal-kde 6.7.0 logs marshalling errors at the time screencast is requested/denied:
QDBusMarshaller: cannot add a null QDBusVariant
QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid QVariant passed in arguments
Namespace "org.kde.kdeglobals.General" is not supported
The portal's permission store screencast table remains empty even after repeatedly denying the prompt:
$ busctl --user call org.freedesktop.impl.portal.PermissionStore /org/freedesktop/impl/portal/PermissionStore org.freedesktop.impl.portal.PermissionStore List s screencast
as 0
This suggests denials aren't being persisted — possibly a separate portal-side bug — but the practical effect is there's currently no way to permanently dismiss the prompt through normal KDE permission management. The Plasma 6.5+ Application Permissions panel is also non-functional/greyed out on this system, likely for the same underlying reason.
Expected Behavior
Steam should not request screencast capture on a normal desktop-mode autostart without an active Remote Play/broadcast session, and/or -nopipewire should suppress this on Jupiter-flavored builds the same way it does on the standard Linux client.