Describe the bug
When using "Set Clipboard" (or Automatic Clipboard) to push clipboard content from the local browser to a remote device, the clipboard text appears to be injected as literal keystrokes into whatever window/control is currently focused on the remote, rather than being written directly to the remote OS clipboard. If the remote's focused control happens to be somewhere that interprets typed text as a command (e.g. a File Explorer address bar), this can cause unintended application launches on the remote — in my case, a Terminal window opens briefly (in the MeshAgent install folder) and then closes almost immediately.
Steps to reproduce
Connect to a remote Windows device via MeshCentral Remote Desktop.
Ensure Automatic Clipboard is off; use "Set Clipboard" manually (issue reproduces with Automatic Clipboard on too).
Copy some text locally that happens to match or resemble a command Explorer's address bar would interpret (in my case landed on something resolving near the agent's install path).
Click "Set Clipboard" to push it to the remote.
Observe: a Terminal window flashes open at the MeshAgent install directory, then closes almost immediately.
Expected behavior
Setting the remote clipboard should only populate the OS clipboard buffer on the remote device — it should never be interpreted as active input/keystrokes into whatever window happens to be focused, and should not be capable of triggering command execution or app launches.
Environment
Reproduced on stock MeshCentral (official web UI), both "Set Clipboard" and "Automatic Clipboard".
Browser: Chrome
Confirms this is not specific to a custom implementation — reproducible on stock MeshCentral.
Additional context
This looks like a security-relevant issue since clipboard content a user did not intend as remote input is effectively being executed as keyboard input on the remote machine, with no target-window awareness or sandboxing. Would appreciate clarification on whether setclip is intentionally implemented via keystroke simulation rather than a native clipboard API call on the agent side, and whether there's a safer path planned (e.g. native SetClipboardData calls on Windows/Linux agents instead of synthetic key events).
Describe the bug
When using "Set Clipboard" (or Automatic Clipboard) to push clipboard content from the local browser to a remote device, the clipboard text appears to be injected as literal keystrokes into whatever window/control is currently focused on the remote, rather than being written directly to the remote OS clipboard. If the remote's focused control happens to be somewhere that interprets typed text as a command (e.g. a File Explorer address bar), this can cause unintended application launches on the remote — in my case, a Terminal window opens briefly (in the MeshAgent install folder) and then closes almost immediately.
Steps to reproduce
Connect to a remote Windows device via MeshCentral Remote Desktop.
Ensure Automatic Clipboard is off; use "Set Clipboard" manually (issue reproduces with Automatic Clipboard on too).
Copy some text locally that happens to match or resemble a command Explorer's address bar would interpret (in my case landed on something resolving near the agent's install path).
Click "Set Clipboard" to push it to the remote.
Observe: a Terminal window flashes open at the MeshAgent install directory, then closes almost immediately.
Expected behavior
Setting the remote clipboard should only populate the OS clipboard buffer on the remote device — it should never be interpreted as active input/keystrokes into whatever window happens to be focused, and should not be capable of triggering command execution or app launches.
Environment
Reproduced on stock MeshCentral (official web UI), both "Set Clipboard" and "Automatic Clipboard".
Browser: Chrome
Confirms this is not specific to a custom implementation — reproducible on stock MeshCentral.
Additional context
This looks like a security-relevant issue since clipboard content a user did not intend as remote input is effectively being executed as keyboard input on the remote machine, with no target-window awareness or sandboxing. Would appreciate clarification on whether setclip is intentionally implemented via keystroke simulation rather than a native clipboard API call on the agent side, and whether there's a safer path planned (e.g. native SetClipboardData calls on Windows/Linux agents instead of synthetic key events).