[BUG] - Concurrent Wayland permission probes invalidate and delete persistent restore token

[jorgegarciaavila]

Issue Checklist

• [x ] Includes repro steps that result in the bug occurring
• [ x] Searched for existing issues
• [ x] Filled out the below sections
• [ x] Does not relate to hosting (server configuration, reverse proxy, Cloudflare, etc.)
  • Connection issues are likely due to something in between the browser/agent and the ControlR backend app, not the app itself.
  • Please go to the Discussions section for help with hosting setups.

Describe the bug

On KDE Plasma Wayland, ControlR occasionally loses its persistent remote-control permission.

The logs show that two permission probes start almost simultaneously using the same XDG restore token. The first probe succeeds, rotates the single-use token, and saves the replacement. The second probe times out after five seconds, treats the token as stale, and deletes the replacement token saved by the first probe.

ControlR then reports that remote-control permission is no longer granted and requires the user to grant it again locally.

To Reproduce

Steps to reproduce the behavior:

1. Install the ControlR agent on KDE Plasma running Wayland.
2. Grant persistent remote-control permission through the XDG portal.
3. Open the ControlR Permissions view.
4. The view may trigger two permission refreshes nearly simultaneously.
5. One probe succeeds while the other times out.
6. ControlR deletes the saved restore token and reports permission as not granted.

The issue is intermittent because the probes must overlap.

Client Info

Browser: Firefox 154
Language/Locale of Browser: English (United States)

Agent Version: 0.27.6.0
Agent OS: EndeavourOS/Arch Linux, KDE Plasma Wayland
Language/Locale of Agent OS: English (United States)

Server Info (if self-hosting)

Server OS: Linux Docker host
Language/Locale of Server OS: English (United States)
Docker image tag: latest

Other relevant info:

This occurs inside the Linux DesktopClient/XDG portal permission handling and does not appear related to server hosting or connectivity.

Logs

19:00:24.115 Wayland permission probe starting.
19:00:24.115 Starting Wayland restore token probe.
19:00:24.154 Wayland permission probe starting.
19:00:24.154 Starting Wayland restore token probe.
19:00:24.489 Saved restore token
19:00:24.489 Probe succeeded: restore token is valid and was rotated.
19:00:24.489 Wayland permission probe completed in 374ms. Granted=true
19:00:29.155 Error starting RemoteDesktop System.Threading.Tasks.TaskCanceledException: A task was canceled.
19:00:29.156 Probe failed: restore token is stale.
19:00:29.156 Wayland permission probe completed in 5002ms. Granted=false
19:00:29.156 Restore token probe failed, deleting stale token
19:00:29.157 Deleted stale restore token
19:00:29.158 Wayland desktop client permission state: RemoteControl=false

Additional Context/Info

XDG restore tokens are single-use and replaced after a successful restore. It appears that both probes load the same token before either finishes.

A possible fix would be to:

Serialize restore-token probes with a lock or SemaphoreSlim.
Treat timeouts separately from confirmed invalid tokens.
Before deleting a failed token, verify that the token file still contains the same token used by that probe, so a newer rotated token is not deleted.

[bitbound]

Thanks for the report, and for including logs. I have a couple other Wayland-related issues I want to look at once I get Permission V2 out. I'll add this to the list.