Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

stageSandboxMedia copies remote attachments via scpFile, which always uses spawn("/usr/bin/scp", ...). That path is POSIX-specific. On Windows, OpenSSH’s client is typically scp.exe on PATH, not /usr/bin/scp, so staging can fail with spawn/ENOENT even when scp is installed. The same hardcoding is fragile on Linux systems where scp is not installed at /usr/bin/scp.

Steps to reproduce

1. Run OpenClaw on Windows (or a host where scp is not at /usr/bin/scp).
2. Exercise inbound media staging with MediaRemoteHost set so the code path calls stageRemoteFileIntoRoot → scpFile (see src/auto-reply/reply/stage-sandbox-media.ts).
3. Observe failure to stage remote files (spawn error / missing executable), while scp may work from a normal shell.

Expected behavior

Remote staging should resolve scp in a portable way (e.g. scp on PATH, platform-specific detection, or documented requirement with a clear preflight error), consistent with other tooling in the repo that uses platform-aware binary resolution.

Actual behavior

scpFile unconditionally invokes /usr/bin/scp, so remote staging depends on a fixed FHS path and fails on typical Windows (and possibly other) layouts.

OpenClaw version

2026.5.4

Operating system

Ubuntu 24.04 / Windows 11

Install method

npm global

Model

anthropic/claude-sonnet-4.5

Provider / routing chain

anthropic

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

High for operators using remote inbound media on Windows or non-standard layouts: attachments may not stage; replies may run without expected media or error opaquely depending on caller. Critical only if you can show this breaks a documented, common production path (add evidence when filing).

Additional information

Confirm duplicate issues on GitHub for scp, stageSandboxMedia, MediaRemoteHost, or /usr/bin/scp before filing.