ASCII Box release hides bounded cleanup progress for stale claims

[shunkakinoki]

Summary

ASCII Box release can spend its full bounded cleanup window without progress output, including when the native Box has already been deleted and the only remaining state is a stale Crabbox claim. To an operator, both automatic --stop-after always cleanup and explicit crabbox stop appear hung.

Observed incident

During the 2026-09-02 incident recorded in #1727 (comment):

1. The pre-fix run exhausted its 20-minute SSH-readiness ceiling.
2. Cleanup emitted no terminal result for more than two additional minutes.
3. After interrupting the owner, explicit crabbox stop --provider ascii-box --target linux --id cbx_9463a02d8f1d also emitted no progress for two minutes.
4. Native box delete --yes --json bx_gxym9gf4 was accepted, and box info bx_gxym9gf4 --json returned 404.
5. A second explicit stop using the patched endpoint build still produced no progress while reconciling the stale local claim.

The release path is bounded by boxReleaseTimeout, so this is not proven infinite execution. The defect is that a bounded multi-minute reconciliation is operationally indistinguishable from a hang, and an authoritative native deletion does not provide a fast claim-reconciliation path.

Expected behavior

• Emit periodic, structured release progress including the current phase and remaining deadline.
• Return promptly when an exact native-not-found result plus complete provider inventory proves the originally claimed Box is absent.
• Retain the claim when absence is uncertain, inventory is incomplete, identity changed, or provider access failed.
• Preserve cancellation and the existing exact-ownership fencing.
• Never start a replacement lease as part of cleanup recovery.

Suggested regression coverage

• Exact GetBox not-found plus complete inventory absence removes only the unchanged original claim without issuing another delete.
• Not-found plus incomplete/failing inventory retains the claim.
• Replacement identity in inventory retains the claim.
• Progress output is emitted during a slow bounded release and stops after cancellation/timeout.
• ReleaseLease remains bounded when the Box CLI child does not settle.

Related execution-routing fix: #1728

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 1, 2026, 9:03 PM ET / September 2, 2026, 01:03 UTC.

Summary
Keep open: current main retains the claim on a Box lookup 404 before it can perform complete-inventory absence confirmation, and its bounded release path has no periodic cleanup progress output.

Reproducibility: yes. —source-reproducible: an exact Box lookup 404 causes release to return before inventory confirmation, and the current test asserts claim retention for that case. Live provider proof remains required for the repair.

Next step
Current source proves a narrow adapter defect, and no open PR in the supplied context owns this cleanup or progress behavior.

Review details

Best possible solution:

Add adapter-local absence reconciliation and periodic phase/deadline progress while preserving the exact claim fence and retaining claims for every ambiguous observation.

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

Yes—source-reproducible: an exact Box lookup 404 causes release to return before inventory confirmation, and the current test asserts claim retention for that case. Live provider proof remains required for the repair.

Is this the best way to solve the issue?

Yes: adapter-local reconciliation after both exact not-found and complete absence is the narrowest safe repair; a generic core fallback or lease replacement would violate the provider ownership boundary.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Claim removal must remain limited to a recognized native not-found result plus a successful complete inventory that lacks the unchanged claimed ID; all failed, partial, or identity-conflicting observations must retain the claim.
• Progress reporting must be cancellation-aware and must not extend the three-minute release deadline or expose credentials or private endpoint details.
• The provider change needs real create/use/destroy proof with no residue before merge, as required for funded remote providers.

Codex review notes: model internal, reasoning high; reviewed against c9cdc3598753.

Label changes

Label changes:

• add P2: A stale ASCII Box claim and opaque bounded cleanup affect a provider-specific lifecycle path but do not establish an emergency-wide outage.
• add impact:other: The report concerns provider cleanup observability and stale lease-claim reconciliation, which are not covered by the more specific impact labels.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: A stale ASCII Box claim and opaque bounded cleanup affect a provider-specific lifecycle path but do not establish an emergency-wide outage.
• impact:other: The report concerns provider cleanup observability and stale lease-claim reconciliation, which are not covered by the more specific impact labels.

Evidence reviewed

Acceptance criteria:

• go test -race ./internal/providers/asciibox
• go vet ./...
• go build -trimpath -o /tmp/crabbox-ascii-cleanup ./cmd/crabbox
• Run a redacted real ASCII Box create/use/destroy cleanup trace that exercises the repaired release path and confirms no residue.

What I checked:

• Current stale-claim path: The guarded release first requires GetBox to return a matching Box; any lookup error, including a recognizable 404, returns immediately and retains the claim, so it never reaches complete inventory confirmation. (internal/providers/asciibox/ownership.go:159, c9cdc3598753)
• Regression coverage exposes the gap: Current coverage explicitly classifies lookup 404 as an uncertain release and asserts that the claim is retained; it has no case for exact not-found plus complete inventory absence. (internal/providers/asciibox/ownership_test.go:99, c9cdc3598753)
• Release visibility is only boundary output: The CLI prints a release-start line and only emits a provider release message after ReleaseLease returns; the adapter's polling loop has no writer or progress callback. (internal/cli/run.go:3769, c9cdc3598753)
• Documented lifecycle contract: The provider documentation requires an exact unchanged claim, successful native deletion, and complete inventory absence before removal; it also documents the three-minute release budget. (docs/providers/ascii-box.md:100, c9cdc3598753)
• Feature history routing: Blame attributes the current exact-release implementation to commit 983a299; raw-parent comparison was unavailable locally, so this is routing evidence rather than an introduction claim. (internal/providers/asciibox/ownership.go:159, 983a2996cef0)
• Vision fit: VISION.md assigns provider-specific lifecycle reconciliation to adapters and calls for clear diagnostics, bounded cleanup, exact ownership, and fail-closed handling of failed inventory operations. (VISION.md:3, c9cdc3598753)

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.