remote-desktop

There are tools for this — use them, not a command line

remote_open, remote_close, remote_list and the remote_profile_* family exist so a connection is a first-class thing on this desktop rather than a process you launched and have to remember. Each is a row in the action log, which means "who connected to what, when" is answerable. A run_command "xfreerdp ..." hides the whole session inside one row and leaves a process nobody tracks.

remote_profile_list shows what is already saved — look before you ask for credentials that may already be stored. remote_profile_save keeps a connection for next time; remote_profile_delete removes one.

The window that opens is on the shared screen

This is the part that is different here. A remote desktop session opens a window on the desktop people are watching, and everything on the far machine becomes visible to everyone in the room. So:

• Say what you are connecting to before you connect.
• desktop_state reports who is present. If somebody is watching and the remote machine holds anything private, that is worth a word first.
• request_control before you drive it, and release_control when done — the session is on the shared display and the ordinary rules apply.

The three, and what actually goes wrong with each

RDP (xfreerdp, Windows and Windows Server). The two failures that account for most of it: certificate prompts hanging a non-interactive launch (/cert:ignore for a host you have verified out of band — do not make that a habit on the open internet), and NLA. /u: /d: for user and domain; a wrong domain reads as a wrong password.

VNC (vncviewer, most Linux and macOS hosts). VNC on its own is not encrypted — say so if it is going anywhere but a LAN, and tunnel it:

ssh_tunnel_local   local 5901 → remote 5901 over ssh
remote_open        localhost:5901

That is the right shape for VNC across any untrusted network, and it costs one extra call.

AnyDesk is a GUI application with its own ID and its own prompts. It is launch_app plus a person, not something to automate: the far side has to accept the session, and the access code is a credential. Drive the window with the ui_* tools if you must, and expect to hand over to a person for the acceptance step.

Credentials, and the one that catches people

A remote-desktop password is a credential like any other: it does not go into a tool argument, where it would be in the transcript and the action log forever. Use a saved profile, or ask_human and have the person type it.

The specific trap: typing a password into the remote session with type_text puts it in your own conversation on the way there. If a login on the far side needs a secret, that is the person's keystroke to make, not yours — say so and hand over.

Close what you opened

remote_list before you finish. A session left open holds a seat on the far machine, keeps a window on this shared screen, and is exactly the residue somebody else has to notice and clean up. remote_close, and say you did.