pull_file --target from the Windows CLI to a non-mesh peer reports success with a local path that never lands

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

Symptom

From the Windows dev box (ab 2.1.46 running locally, CLI 2.1.46, ADOM_API pointed at the hc relay), a --target pull of a screenshot from a NON-mesh peer reports success with a local path that does not exist:

adom-bridge --target arav-rog pull_file '{"filePaths":["C:/Users/arav/AppData/Local/Temp/adom-bridge-shots/screen-1788644759945.safe.png"],"saveTo":"C:/tmp/jl155"}'
-> success:true, durationMs:235, files:[{name, path:"C:/tmp/jl155/screen-1788644759945.safe.png", size:782192, sha256, chunks:1}], savedTo:"C:/tmp/jl155"

C:\tmp\jl155 stays empty (checked from PowerShell, MSYS bash, and the Claude package shadow), nothing lands on the relay host either (find / -name screen-1788644759945* on galliaApril: nothing). The _hint says the file was pulled "to THIS machine". The --target screenshot verbs have the same gap: desktop_screenshot_screen returns the REMOTE safePath and no localSafePath, and the CLI's auto-pull does not run for a targeted call.

arav-rog is on the relay but not in the mesh directory (mesh off there), so this is the hc-relay fallback of the 2.1.43 "pull via the local ab" path (cli/src/relay.rs::mesh_pull_via_local -> local ab mesh::pull_files_json). A mesh peer (ConfRoomROG) pulls fine.

Expected

Either the bytes land at saveTo on the caller's machine, or the response says clearly that they did not (and where they went). A 235 ms "success" with a 782 KB file and a path that does not exist is the worst of the three.

Workaround used

Decode the inline base64 output.data.image a targeted desktop_screenshot_screen already returns (safe-size PNG), which is what the #155 harness ended up doing.

1 Reply

John Lauer · 2mo ago

Fixed in 2.1.49 (CLI + relay), verified live from the same setup that failed.

Root cause: the relay's streamed pull writes the file on the RELAY host at the saveTo the CLI passed, on the assumption that CLI and relay share a filesystem (true in a container, false for a Windows CLI with ADOM_API pointed at the cloud relay). The CLI then reported the relay's summary as a local path. The "C:/tmp/jl155/..." you asked for landed on galliaApril under its cwd as a literal C:\... path.

Fix: when the relay is not on this host (relay_is_remote(): api host is not loopback / host.docker.internal), the CLI asks the relay to spool (destinationPath: "spool:<name>"); the relay writes under its temp dir and returns a one-shot spoolToken; the CLI downloads GET /pull-spool/<token>/<name> (CLI-identity gated, file deleted after serving), verifies sha256, and reports the LOCAL path with route: "relay-spool". On the relay host nothing changed; a mesh peer still goes over the mesh.

Verified: adom-bridge --target arav-rog pull_file {saveTo:"C:/tmp/jl156"} from AdomLapper -> C:\tmp\jl156\screen-1788644759945.safe.png, 782192 bytes, sha256 matched, route: relay-spool. Requires the relay to run 2.1.49 (galliaApril's was bounced onto it; an older relay makes the CLI report "the relay did not spool the file" instead of a phantom success).

John Lauer closed this · 2mo ago