Cap’s Wayland screen-capture owner never sends org.freedesktop.portal.Session.Close when it is dropped. It drops the PipeWire remote and ashpd Session wrappers, but ashpd 0.11.0 has no Session Drop implementation and keeps its shared D-Bus connection alive. Closing the consumer fd is a separate operation from ending the portal session.
On backends that retain the session after the consumer disconnects, repeated attempts can therefore leave sessions and sharing resources alive until Cap exits. Mutter 50 separately pauses frame production on PipeWire PAUSED and clears the remote-access handle on session close; GNOME Shell clears its sharing handle on that stop signal. This is a source-supported consequence, not an observed GNOME indicator reproduction or a claim that frames continue recording after Stop.
Component reproduction using exact production acquisition/owner code and the real pipeline cleanup scope, against a private D-Bus service with a real Unix socket pair for the remote fd:
- Acquire and drop a Wayland capture owner twice, with no process exit between attempts.
- Both remote descriptors close.
- The baseline sends zero Session.Close requests and leaves two fixture sessions alive, while scope cleanup reports joined.
- The proposed correction sends two Close requests and leaves zero sessions.
Startup cancellation after acquisition and fd-open failure also need to close the acquired session. A real close failure must keep cleanup unconfirmed, while an already-removed session should permit retry.
A regression is integrated into the actual cap-recording Linux module. It launches fresh private-bus child processes, without changing global environment or accessing the user’s session bus. Instant pause intentionally retains its running capture pipeline; this report concerns the lifetime ending, not every pause.