cli.js sandbox arch resolver hard-codes x64/arm64 only — blocks ppc64le even when apply-seccomp is present

Summary

The sandbox / seccomp arch resolver in cli.js maps process.arch to a binary-path directory using a hard-coded ternary that only handles x64 and arm64:

// cli.js v2.1.112 (minified, reformatted)
const arch = process.arch === "x64" ? "x64"
           : process.arch === "arm64" ? "arm64"
           : null;

For any other arch, arch ends up null and the code falls through to the warning:

[Sandbox Linux] apply-seccomp binary not available - unix socket blocking disabled.
Install @anthropic-ai/sandbox-runtime globally for full protection.

Even when @anthropic-ai/sandbox-runtime IS installed globally AND its vendor/seccomp/<arch>/apply-seccomp directory contains a valid binary for the running arch, the resolver above returns null and never looks at it.

Concrete case: ppc64le (IBM POWER)

I've just opened anthropic-experimental/sandbox-runtime#219 which adds ppc64le as a third target arch to sandbox-runtime — tested on real IBM Power S824 hardware, static 847 KB binary, same build pattern as the existing x64/arm64 entries.

Once that merges and sandbox-runtime@next ships vendor/seccomp/ppc64le/apply-seccomp, claude-code still won't find it until the cli.js resolver above accepts ppc64 (Node's process.arch returns ppc64 on ppc64le Linux, even though the directory name uses the ppc64le suffix to be explicit).

Proposed change

Extend the resolver to accept any arch that sandbox-runtime ships a binary for. Minimally, add ppc64:

const arch = process.arch === "x64" ? "x64"
           : process.arch === "arm64" ? "arm64"
           : process.arch === "ppc64" ? "ppc64le"
           : null;

Better — resolve the arch dynamically from what's actually shipped in sandbox-runtime/vendor/seccomp/:

// Pseudocode — pick whatever subdirectory matches the running arch
const SUPPORTED_ARCHES = { x64: "x64", arm64: "arm64", ppc64: "ppc64le" };
const arch = SUPPORTED_ARCHES[process.arch] ?? null;

Either form is a one-line change in the source that generates cli.js. I'm reaching for the source because patching the minified cli.js directly on my install works but obviously breaks on every upgrade.

Why this matters

• POWER8 / ppc64le is a legitimate Linux AI-tooling target. vllm added ppc64le CPU backend support recently (vllm-project/vllm#37586). Claude Code running on POWER inside your own repo ecosystem would close a nice loop.
• Related issue: #50443 asks for ppc64le SEA binary support in post-v2.1.113 releases. This issue is narrower — even if SEA binaries land, this resolver still needs extending.
• The "dynamically resolve from shipped directories" pattern would future-proof the resolver for riscv64, s390x, or whatever other archs community members port apply-seccomp to. Low maintenance, high ergonomics.

Verification on my end

v2.1.112 on IBM Power S824 (Ubuntu 20.04, Node.js v22 from source):

• Before patch: resolver returns null → unix-socket-blocking disabled, warning logged
• After I hand-patched the ternary to include ppc64: resolver finds my locally-built vendor/seccomp/ppc64le/apply-seccomp → sandbox mode works end-to-end, no warning
• claude --version → 2.1.112 (Claude Code) — unchanged

Happy to provide the exact grep string (it's literally the line quoted above) or test a patched cli.js if there's a canary build.

Context

• Related PR: anthropic-experimental/sandbox-runtime#219 — adds ppc64le to the upstream sandbox-runtime. That's the prerequisite for this resolver change to actually matter.
• Related issue: #50443 — umbrella request for ppc64le support including the SEA split in v2.1.113+.

Thanks.