Remote desktop
View and control a whole computer, and understand who is allowed to.
On this page
A whole computer, not one app
An app preview shares one running application. Remote desktop shares the whole screen of the computer running Lyre, over its own permission and its own control channel. It is built into the desktop app, so a normal install needs no Docker, RDP server, gateway or separately installed helper.
No project and no coding assistant are required. The host publishes its screens as opaque sources, so a client cannot name a display handle, a port or a path.
For a practical first session and the differences between a screen, a saved app and a project preview, follow view and control your computer with Lyre.
Windows and macOS hosts serve a native screen. Linux hosts do not advertise a native screen on this native capture path.
the computer you want to see is running Lyre Studio and is reachable from the device you will use.
Start a session
-
Keep Lyre running
Leave Lyre Studio open on the computer you want to see.
-
Open Remote desktop and pick the computer
Choose Remote desktop and select the computer.
-
Choose a screen
Under Computer screens, choose View Whole Desktop or open a specific screen. Opening the tab never starts capture. Each source has its own action.
-
Start viewing
The viewer tells you whether the session is View only or Control.
Saved applications are listed separately under Quick Access. Starting one of those starts that application alone, and leaving its viewer stops only that session.
Your client predates whole-desktop viewing. Update the client; the host does not need to change.
you can see the host computer’s screen and the viewer says whether input is accepted.
Who may view, and who may control
Viewing and controlling are separate grants, and the host decides which one a connection gets. A view-only session sends no input, and the host refuses input for it rather than trusting the client.
| Access | Whole desktop |
|---|---|
| Owner or account access | Uses that connection’s existing access to the host. |
| Approved developer | One developer native session per screen; saved external gateways use one developer slot. |
| A paired device | Pairing on its own grants nothing. |
| Shared-app viewer | No desktop access at all. |
Desktop access does not grant agents, source, terminals or host settings. A shared-app grant cannot open a desktop. When another developer holds the selected source, the chooser reports that state.
the computer appears as an available screen, and if you expected control, the viewer says Control rather than View only.
The operating system still decides
Lyre does not work around a system permission decision. Find your operating system below.
macOS
macOS presents Screen Recording and Accessibility prompts. Allow both when asked.
-
Allow both prompts
Screen Recording shows the screen; Accessibility allows Lyre to send clicks and keys.
-
A check ended while you were deciding
Approve it, then reconnect. The approval is recorded even if the first attempt failed.
Windows
Windows cannot send input to a window running at a higher integrity level. Control of an elevated application is refused rather than faked.
If the app you want to drive is running elevated, you can watch the screen but not click inside it. This is a Windows rule, not a Lyre setting.
Stopping it, losing the connection, losing access, a capture failure or a failed input helper all end it. Resuming needs a new start, and the viewer offers Reconnect for that.
the screen is live and, if you wanted control, your clicks and typing reach the host.
Listen to host audio
Native Windows and supported macOS screen streams can include system output audio. Use AudioPlay host audio on desktop/browser to enable client playback. Muting the stream leaves the host's speakers unchanged.
On macOS, allow the required recording permissions and reconnect. Missing audio readiness can leave video available without an audio track. These screen streams exclude microphone capture; saved external gateways have their own audio behavior.
Away from the same network
On one network the picture can connect directly. Away from it, media needs a working ICE route. The host supplies short-lived relay credentials when its account-backed or operator-configured media relay is available.
A control connection that completes does not prove the picture arrives. When a session connects and stays black, the media path is the thing to check, not the permission.
Individual-app streaming follows a local-network-only policy. Native whole-desktop viewing and control use separate connection and platform checks; a working control channel still does not establish a working media route.
the screen updates when you move on the host, even away from your own network.
Choose an available virtual screen
Lyre can add a separate screen without changing your physical displays, and the host decides whether it is able to. Availability is not assumed from the operating system, so the action stays unavailable on a host that cannot complete it rather than failing after you choose it.
Use the readiness and setup information reported by your host. On macOS the bundled helper and recording permission are required. Windows requires its driver and service setup; Linux availability depends on its supported display setup. Viewing a physical screen remains a separate choice.
you can still view a real screen, whether or not a virtual one is offered.
An external RDP/VNC gateway is a separate choice
If you already run an RDP or VNC gateway, select Use existing RDP/VNC gateway to reach a host that way. That route keeps its own target, credentials and text clipboard, and it is never required to view a real screen natively. Lyre does not install a gateway server for you.
See connectivity for how a connection is routed, and security and privacy for what a session can reach.
When it does not start
- This host is offline.
- Lyre Studio is running on that computer and is reachable.
- This device does not have access to this host’s desktop.
- Check the access level on the host. Pairing is not desktop access.
- Another developer is using it.
- Check the session that is already open, or ask that developer to stop it.
- This host’s operating system cannot serve remote desktop.
- Check the host platform. Linux hosts serve no native screen on this native capture path.
- Remote desktop is not configured on this host.
- Check the host's own remote desktop settings.
- The picture appears but clicking or typing does nothing
- Check that the session is in Control, that access has not been revoked, and the operating system permission above. A view-only session refusing input is the correct result.
When you report a problem, include the exact message, your client platform, and whether you were on the same network. See updating and reporting problems.