[deep-review] C5: openclaw://agent?message=… deep link sends chat.send with no UI confirmation

[codemonkeychris]

Summary

The openclaw://agent?message=… (and openclaw://send?message=…) deep link path calls chat.send against the user's gateway without any UI confirmation. These deep links are reachable from:

1. Any same-user process via the unauthenticated OpenClawTray-DeepLink named pipe.
2. Any webpage the user visits that contains an openclaw:// link (one click is enough on packaged installs because of the protocol handler registration).

Where

• Deep-link dispatch: src/OpenClaw.Tray.WinUI/Services/DeepLinkHandler.cs:54-266
• Action wiring: src/OpenClaw.Tray.WinUI/App.xaml.cs:4286-4324 (DeepLinkActions struct fields including OpenChat, SendMessage, etc.)
• The pipe server: src/OpenClaw.Tray.WinUI/App.xaml.cs:4246-4282 (StartDeepLinkServer)

Why it matters

Two attack vectors:

1. Same-user processes: any user-mode malware or a benign app running buggy code can write to the pipe and trigger chat.send. The agent treats this as a legitimate user message — no audit trail, no consent.
2. Drive-by web: a malicious page can convince the user to click an openclaw://agent?message=Run+rm+-rf link, which the OS resolves to a chat.send against the user's agent. The agent may then propose, and depending on exec-approval policy execute, the embedded command.

Compare to:

• Slack / Discord: slack://channel?id=… switches focus but never sends a message.
• VS Code: vscode:// extension URIs require the user to approve the extension and surface a prompt for sensitive actions.

Proposed fix

For any deep link whose effect is "send a message to the agent" or "trigger a destructive action", show a ContentDialog previewing the message and asking the user to confirm Send / Cancel. Show the source if possible (pipe vs OS-routed URI).

Keep openclaw://hub, openclaw://settings, etc. as no-op-friendly navigations — the issue is specifically the message-injection paths.

Severity

Critical — message injection from low-trust callers.

[shanselman]

Closing this one-off deep-review issue as consolidated, not necessarily fixed. The useful signal is preserved in #372: deep-link send confirmation remains useful signal, but should be verified and fixed fresh. We will take these one at a time from #372 after verifying against current master instead of keeping the issue list flooded.