Summary

stageRemoteFileIntoRoot -> scpFile (in src/auto-reply/reply/stage-sandbox-media.ts) spawned /usr/bin/scp directly. That POSIX-FHS path does not exist on Windows native (OpenSSH ships scp.exe outside /usr/bin), Homebrew/Nix prefixes, or any custom OpenSSH install layout. Inbound remote media staging fails with spawn ENOENT on those hosts even though scp is installed and works from a normal shell.

Root Cause

• src/auto-reply/reply/stage-sandbox-media.ts:316 (pre-fix): spawn("/usr/bin/scp", [...]) is hardcoded to a Linux-FHS absolute path.
• Execution path: inbound channel media with MediaRemoteHost set -> stageSandboxMedia -> stageRemoteFileIntoRoot -> scpFile -> spawn("/usr/bin/scp", ...) -> ENOENT on Windows / non-FHS hosts.
• The argv (-o BatchMode=yes, -o StrictHostKeyChecking=yes, -- separator before user-provided host:path) already prevents shell injection. Switching from absolute path to bare scp keeps the same argv contract — no shell expansion, no widened attack surface — and lets child_process.spawn resolve the OS-appropriate binary via PATH.

Changes

• src/auto-reply/reply/stage-sandbox-media.ts: replace "/usr/bin/scp" with "scp" so PATH lookup picks the OS-appropriate OpenSSH client (Windows native scp.exe, Homebrew/Nix prefixes, custom installs). Add a brief comment noting the security argument is preserved by the existing argv guards.
• src/auto-reply/reply.stage-sandbox-media.scp-remote-path.test.ts: add a regression test that asserts child_process.spawn is called with command "scp" (not "/usr/bin/scp"), so a future revert reintroduces the cross-platform breakage visibly.
• CHANGELOG.md: single-line entry under Unreleased / Fixes.

Real behavior proof

• Behavior or issue addressed: Inbound remote attachment staging fails with spawn ENOENT on hosts where scp lives outside /usr/bin (Windows native OpenSSH at C:\Windows\System32\OpenSSH\scp.exe, Homebrew under /opt/homebrew/bin, Nix store paths, etc.). Reporter confirms scp works from a normal shell on the same host but stageSandboxMedia cannot use it. Issue: [Bug]: Remote inbound media staging spawns hardcoded /usr/bin/scp (broken on Windows / non-FHS layouts) #78677
• Real environment tested: Local OpenClaw checkout on Windows 11 + Node 24 (an environment that itself has the bug — scp.exe lives at C:\Windows\System32\OpenSSH\scp.exe, not /usr/bin/scp). The patched production resolver was exercised through the actual stageSandboxMedia -> stageRemoteFileIntoRoot -> scpFile call chain (no stubbing of the production seam) using the test harness's mocked child_process.spawn to capture the resolved argv before the Windows OpenSSH binary actually runs.
• Exact steps or command run after this patch:

  git checkout fix/scp-resolve-on-path
  pnpm install
  pnpm test src/auto-reply/reply.stage-sandbox-media.scp-remote-path.test.ts --no-coverage
  

• Evidence after fix (terminal output captured locally on PR head 5c2b87f27a running on Windows 11):

  [test] starting test/vitest/vitest.auto-reply.config.ts
  
   RUN  v4.1.5 C:/Users/pss/OneDrive/Documents/github/openclaw-78677
  
   Test Files  1 passed (1)
        Tests  3 passed (3)
     Start at  18:32:20
     Duration  7.18s
  
  [test] passed 1 Vitest shard in 14.13s
  

• Observed result after fix: The new regression test confirms the production scpFile now calls child_process.spawn("scp", [...]) instead of child_process.spawn("/usr/bin/scp", [...]). On Windows, spawn("scp", ...) resolves to C:\Windows\System32\OpenSSH\scp.exe via PATH; on Linux/macOS without /usr/bin/scp (e.g. Homebrew, Nix), it resolves to whichever scp is on PATH. The two existing argv-guard tests (shell-metacharacter rejection, slugged remote cache directory for path-separator session keys) still pass — the security/path-injection argv contract is unchanged.
• What was not tested: A live remote ssh handshake against a real macOS/Linux/Windows OpenSSH server is not reproduced on the contributor machine (would need a paired remote host + matching key). The fix is purely a PATH-resolution change at the spawn boundary; the surrounding argv (BatchMode, StrictHostKeyChecking, -- separator) and the normalizeScpRemoteHost / normalizeScpRemotePath guards that come before spawn are unchanged. Maintainers may apply proof: override if a live handshake is required.

Test

• pnpm test src/auto-reply/reply.stage-sandbox-media.scp-remote-path.test.ts — 3/3 passed (was 2; +1 PATH-resolution regression).

Notes

• Scope: smallest complete fix. Single-line value change in spawn plus a regression test. No other call sites of /usr/bin/scp exist in the repo (grep -r "/usr/bin/scp" src extensions returns only this one location).
• Compatibility: hosts that DO have scp at /usr/bin/scp continue to work — PATH resolution will still find it there (it is on the default PATH on POSIX systems). The change strictly widens compatibility.
• Security: argv (-o BatchMode=yes, -o StrictHostKeyChecking=yes, -- before user input) is unchanged. normalizeScpRemoteHost and normalizeScpRemotePath continue to reject shell metacharacters before spawn is invoked, so PATH resolution does not reintroduce any injection class.

Closes #78677