fix(dev): stream docker save without buffering in kind image load

[pallakatos]

Problem

kars dev (and kars dev --release) fails at step "Loading kars images into the kind cluster" with:

local-k8s dev failed: Command's stdout was larger than 100000000 characters:
/opt/homebrew/bin/docker save 'karsacr.azurecr.io/openclaw-sandbox:latest'
maxBuffer exceeded

Root cause

loadImageIntoKind() in cli/src/commands/dev/local-k8s.ts pipes docker save <image> straight into the kind node's ctr import:

const save = execa(runtime, ["save", image]);
const importProc = execa(runtime, ["exec", "-i", node, "ctr", "-n=k8s.io", "images", "import", "-"], …);
save.stdout.pipe(importProc.stdin);

Even though the stream is piped, execa still accumulates the subprocess stdout into its result, capped at maxBuffer (default 100 MB). The openclaw-sandbox image exceeds 100 MB, so execa throws maxBuffer exceeded and aborts the entire bring-up.

Fix

Pass { buffer: false } to the docker save subprocess. The tarball is never needed in memory — it streams directly to ctr import — so buffering is pure overhead and the source of the failure. One-line change plus an explanatory comment.

Testing

• Reproduced: kars dev --release aborts at "Loading kars images" on a host where the sandbox image is > 100 MB.
• With the fix, docker save | ctr import streams to completion and the kind load proceeds.

Scope

Isolated, standalone CLI bugfix; no behavioral change beyond no longer aborting on large images.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None