Best possible solution:

Land the narrow PATH-resolution change with the existing validation, regression assertion, and changelog if maintainers accept process PATH as the intended scp lookup contract.

Do we have a high-confidence way to reproduce the issue?

Yes. The current-main source unconditionally spawns /usr/bin/scp, so a host with scp available elsewhere on PATH but not at /usr/bin/scp has a clear failing path before SSH connection setup; I did not live-reproduce that exact host layout because this runner has /usr/bin/scp.

Is this the best way to solve the issue?

Yes. Spawning scp by command name while preserving spawn without a shell, the existing arguments, and host/path validation is the narrowest fix for PATH-based OpenSSH installs; a new config option would be heavier than the reported portability bug requires.

What I checked:

• Current main hardcodes scp path: Current main calls spawn("/usr/bin/scp", ...) in the remote media staging helper, so installs with scp elsewhere on PATH remain affected on main. (src/auto-reply/reply/stage-sandbox-media.ts:321, df069f7b0222)
• Remote staging path is scoped: Remote media staging only reaches scpFile after MediaRemoteHost is present and the source path passes the channel remote attachment root check. (src/auto-reply/reply/stage-sandbox-media.ts:94, df069f7b0222)
• Argument validation remains in place: normalizeScpRemoteHost rejects whitespace/options and normalizeScpRemotePath rejects shell metacharacters/control characters before spawning scp. (src/infra/scp-host.ts:18, df069f7b0222)
• Documented behavior uses SCP for remote attachments: The iMessage docs say remote attachment paths can be fetched via SCP when remoteHost is set and that strict host-key checking is used. Public docs: docs/channels/imessage.md. (docs/channels/imessage.md:406, df069f7b0222)
• PATH resolution behavior checked: A local Node spawnSync("scp", ...) check spawned when PATH included /usr/bin:/bin and returned ENOENT when PATH was set to a nonexistent directory, confirming the proposed command-name lookup depends on PATH.
• PR diff scope: The provided PR diff changes only the scp executable string, adds an assertion that the spawned program is scp, and adds a changelog line. (src/auto-reply/reply/stage-sandbox-media.ts:321, 56c2e20b6fdb)

Likely related people:

• amknight: Local blame attributes the current stageSandboxMedia helper and scpFile implementation, including the hardcoded /usr/bin/scp call, to this current-main history. (role: current-main line owner; confidence: medium; commits: 6a8b4e422e82; files: src/auto-reply/reply/stage-sandbox-media.ts, src/auto-reply/reply.stage-sandbox-media.scp-remote-path.test.ts)
• Omar Shahine: Recent current-main commits touched the iMessage surface that provides remoteHost and remote attachment roots feeding this staging path. (role: recent adjacent owner; confidence: medium; commits: df069f7b0222, e259751ec9c9; files: extensions/imessage/src/monitor/monitor-provider.ts, extensions/imessage/src/media-contract.ts, docs/channels/imessage.md)
• steipete: Besides proposing this PR, local history shows recent current-main commits by Peter Steinberger in nearby auto-reply/plugin runtime helper areas, making him a plausible maintainer route for this small behavior change. (role: adjacent maintainer and PR proposer; confidence: medium; commits: 6a4069dead0f, 830a72d2eeea; files: src/auto-reply, extensions/imessage)

Remaining risk / open question:

• PATH-based lookup intentionally executes whichever scp the OpenClaw service environment resolves; this is a maintainable portability tradeoff but should be accepted explicitly by the maintainer handling the PR.

Codex review notes: model gpt-5.5, reasoning high; reviewed against df069f7b0222.