Option to have remote access via RustDesk, ScreenConnect, etc.

[bdunncompany]

It would be great if there was a way to define alternative remote access methods. For example with RustDesk, it would be pretty simple:

rustdesk:// # standard
rustdesk:///r # force relay
rustdesk:///r@ # relay via specific server

ScreenConnect is a bit more complicated:

https://example.screenconnect.com/Host#Access///08a2cb26-8786-443c-9d45-1bfb4b290a3d/Join

[bdunncompany]

Took a stab at implementing this on a fork. Working POC in production at my MSP — full multi-provider toggle (Built-in WebRTC / RustDesk / ScreenConnect Backstage / ScreenConnect regular) verified end-to-end on Safari + Chrome.

Branch: https://github.com/bdunncompany/breeze/tree/feat/pluggable-remote-launchers (1 commit, 8 files, +361/-3)

Shape

New inheritable category on PartnerSettings:

interface RemoteAccessProvider {
  id: string;
  name: string;
  urlTemplate: string;       // 'rustdesk://{id}?password={password}'
                             //  or 'https://acme.screenconnect.com/Host#Access///{id}/Join'
  customFieldKey: string;    // device.custom_fields key holding the per-device id
  password?: string;         // optional preset
  enabled: boolean;
}

interface InheritableRemoteAccessSettings {
  providers?: RemoteAccessProvider[];
  defaultProviderId?: string;
}

{id} and {password} placeholders are substituted with percent-encoded values. The browser auto-detects launch mode by URL prefix — http(s):// opens in a new tab; anything else hands off to the OS protocol handler. Server builds the URL inside the device GET response so the preset password never reaches the web bundle.

Highlights

• Zero behavior change without configuration. The Connect Desktop button keeps doing exactly what it does today unless a partner admin sets a default provider in Partner Settings → Remote.
• Built-in option always present in the provider list — selecting it falls back to the bundled WebRTC desktop session. Removing the current default also routes back to built-in instead of silently picking another provider.
• URL builder runs under withSystemDbAccessContext so the partner-axis RLS on partners doesn't strip the row when the request scope is org/partner. Mirrors how remoteAccessPolicy.ts does the same lookup.
• 10 new Vitest cases covering placeholder substitution, percent-encoding of URL-reserved chars (the # in passwords trap), the ScreenConnect HTTPS template, and all the null/disabled/missing-field branches.
• Full workspace test suite green for everything the patch touches:
  • @breeze/api — 4064 passed, 28 skipped, 0 failed (389 test files)
  • @breeze/shared — 551 passed, 0 failed
  • @breeze/viewer — 114 passed, 0 failed
• Workspace typecheck (api/web/shared) — 0 errors / 0 warnings.
• (Note: @breeze/web shows 23 pre-existing failures in stores/auth, stores/aiStore, stores/orgStore, and backup/RecoveryBootstrapTab — all Cannot read properties of undefined (reading 'setItem'/'removeItem'/'clear') localStorage issues. Verified identical 23 failures on upstream main (commit 9ae5bf9) by checking out main and running the same files. None of those test files are touched by this patch; reproduces on a clean checkout, likely Node-version sensitivity. Mentioning here for transparency.)

Threat model

The preset password lives in partner.settings JSON, which is readable by partner admins via GET /orgs/partners/me. That's the same trust boundary as notifications.smtpPassword already in that JSON. The web bundle never carries the password — it only ever sees a fully-built URL right before it fires. Org-level admins inherit access via the partner cascade like any other inheritable setting.

Out of scope (filed separately if interest)

• Audit logging of external launches. /remote/sessions only records WebRTC + remote-shell. External launches aren't tracked. Real concern for compliance ("who connected to what when") — would extend the remote_sessions schema with a new type and have the button POST before firing the URL.
• Multi-tool icon-button row. When several providers are enabled, the single Connect Desktop button could be replaced with one icon-button per provider (similar to NinjaOne's stacked RDP / NinjaOne Remote / ScreenConnect icons). UX-only follow-up; current design is one button + a default selector.
• Built-in provider catalog. "Add RustDesk" / "Add ScreenConnect" pre-fill buttons so MSPs don't have to look up URL syntax. RustDesk, ScreenConnect, TeamViewer, AnyDesk, Splashtop are the common targets.

Happy to PR this if the design looks reasonable to you, or fold in any direction changes you'd want first.

[bdunncompany]

A small UX follow-up worth visualizing before I file a separate issue for it: instead of keeping the single Connect Desktop button when several providers are enabled, render one icon-button per enabled provider — same pattern NinjaOne uses with their stacked RDP / NinjaOne Remote / ScreenConnect icons.

Same data model — consumes the existing partners.settings.remoteAccessProviders array, just renders one icon per enabled: true entry. The current default provider keeps an indicator dot + outline so it stays the obvious "primary" target. Renames Run Script → Scripts and Remote Tools → Tools to make horizontal room.

Fallbacks:

• Partner with no providers configured → shows a single icon for the built-in WebRTC option, identical to today's behavior.
• Device missing the configured custom field for a given provider → that provider's icon is dimmed with a tooltip explaining why.
• Narrow viewports → icons collapse into a single button-with-popover (icon = current default; arrow opens picker).

Provider icons would come from a partner-uploadable asset slot, with a built-in catalog for the common ones (rustdesk, screenconnect, teamviewer, anydesk, splashtop).

Happy to fold this into the same PR or file as a follow-up — whichever you prefer.

[ToddHebebrand]

Heads up — #680 (Pluggable remote-desktop launcher: RustDesk / ScreenConnect / TeamViewer / …) is open and in review. That should land the bulk of what's described here.

[ToddHebebrand]

Shipped — the pluggable remote-desktop launcher landed on main in #680 (merged 2026-05-15). RustDesk / ScreenConnect / TeamViewer plus arbitrary custom launchers are configurable, as discussed here.

Thanks @bdunncompany for the detailed write-up and the implementation. Closing as resolved — reopen if anything's off in your environment.