Surface and fail sandbox teardown when Docker removal fails

[SUaDtL]

Surface and fail sandbox teardown when Docker removal fails

Severity: high | Confidence: 0.99 | Effort: M

Where:

• plugins/ca-sandbox/tools/destroy.ts:63-85
• plugins/ca-sandbox/tools/destroy.ts:107-122
• plugins/ca-sandbox/tools/cli.ts:368-376

Evidence: if (r.code === 0) removedContainers.push(c) and the equivalent volume branches discard every non-zero Docker result, after which the CLI unconditionally return 0. A bounded injected-runner reproduction made discovery return container c1 and volume v1, made every removal return exit 125, and both destroySandbox and prune still returned ordinary result objects with empty removal arrays and no failure field.

Impact: A daemon outage, permission failure, or in-use object can leave untrusted sandbox containers and source volumes running while automation receives exit code 0. The advertised teardown/prune guarantee is therefore false precisely on the failure path where cleanup matters most.

Recommendation: Treat every failed removal as a structured failure, continue best-effort cleanup of the remaining targets, re-list the scoped objects after removal, and make the CLI exit non-zero with bounded diagnostics whenever any target remains or any removal failed.

Acceptance criteria:

• Injected non-zero container and volume removal results are retained in a bounded failure list and make sandbox destroy and sandbox prune exit non-zero.
• Teardown continues attempting all discovered targets even after one removal fails.
• A final label-scoped verification detects and reports any remaining targeted objects.
• Tests cover mixed success/failure, Docker-daemon failure, and complete success for both destroy and prune.