ASCII Box cannot satisfy fixed lease IDs required by OpenClaw cloud workers

[shunkakinoki]

Problem

OpenClaw cloud-worker dispatch through the bundled Crabbox provider cannot provision the ascii-box backend because OpenClaw correctly requests a deterministic lease ID for replay safety.

The dispatch reaches Crabbox and fails before provider mutation:

Worker provider operation failed: Crabbox warmup failed with exit code 2: provider=ascii-box does not support fixed idempotent lease IDs

Reproduction

1. Configure an OpenClaw cloudWorkers.profiles entry with outer provider crabbox and settings.provider: ascii-box.
2. Confirm crabbox doctor --provider ascii-box passes with auth/control plane ready.
3. Dispatch a managed-worktree session to that profile.
4. OpenClaw invokes Crabbox warmup with its deterministic --lease-id; Crabbox rejects ascii-box because the backend does not implement IdempotentLeaseIDBackend.

Observed with OpenClaw 2026.8.1 and the current Crabbox development build on Linux x86_64. The rejection occurs before an ASCII Box start is consumed.

Expected behavior

The ASCII Box backend should support Crabbox logical fixed lease IDs with replay-safe create/inspect/stop behavior, or the provider/docs matrix should explicitly mark it incompatible with OpenClaw cloud-worker lifecycle. OpenClaw must not fall back to non-idempotent allocation because an ambiguous retry could create duplicate paid machines.

Why configuration cannot solve this

The OpenClaw profile schema intentionally has no option to disable fixed-ID replay safety, and Crabbox YAML cannot add the missing backend capability. This needs a provider-level lifecycle implementation.

[clawsweeper]

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

Summary
This is a valid, currently reproducible request for a new provider capability, not an existing-behavior regression: current main deliberately rejects fixed IDs for ASCII Box before allocation. The generic backend documentation already records that only specific adapters support this optional capability; a maintainer must decide whether ASCII Box has a safe public reconciliation primitive worth implementing.

Reproducibility: yes. from source: passing a valid fixed lease ID reaches the admission check in internal/cli/run.go, and the ASCII Box backend does not implement the required capability, so warmup exits before allocation.

Maintainer decision needed

Question	Recommendation
Should Crabbox invest in a generic fixed-ID lifecycle for ASCII Box only if its public control plane can safely reconcile interrupted creates, or retain the unsupported capability and document that boundary per provider?	Retain the boundary and document it: Keep fixed-ID rejection for ASCII Box and add an explicit provider-level limitation and compatibility-matrix entry.

Why: The current contract intentionally makes fixed IDs optional, while a safe implementation for a funded provider depends on a provider-specific recovery guarantee that current source does not establish.

Next step
The source proves the requested unsupported capability, but enabling it safely requires a maintainer decision about the ASCII Box public lifecycle and paid-resource recovery guarantees.

Review details

Best possible solution:

Retain the fail-closed default unless maintainers confirm a public ASCII Box create/reconcile mechanism that can bind one logical lease across retries; otherwise add an explicit ASCII Box limitation and compatibility-matrix entry.

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

Yes, from source: passing a valid fixed lease ID reaches the admission check in internal/cli/run.go, and the ASCII Box backend does not implement the required capability, so warmup exits before allocation.

Is this the best way to solve the issue?

No for an unconditional implementation: the current fail-closed path is safer until a provider-native interrupted-create reconciliation mechanism is established; the generic documentation already states that fixed IDs are optional and unsupported backends are rejected.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Adding fixed-ID support without a provider-native, crash-recoverable create/reconciliation key could turn ambiguous retries into duplicate billed Boxes; current pre-allocation rejection avoids that outcome.

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

Label changes

Label changes:

• add P2: This is a bounded provider-capability gap affecting retry-safe remote allocation, but current behavior fails safely before a paid resource is created.
• 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:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This is a bounded provider-capability gap affecting retry-safe remote allocation, but current behavior fails safely before a paid resource is created.

Evidence reviewed

What I checked:

• Fixed-ID admission is intentionally fail-closed: Current warmup checks the configured backend for the idempotent fixed-ID contract and exits before acquisition when it is absent. (internal/cli/run.go:86, 9ab5b3ba7e05)
• ASCII Box does not implement the fixed-ID path: Its acquisition path generates a fresh lease ID and calls the native create operation; it has no fixed-ID capability declaration or requested-ID handling. (internal/providers/asciibox/backend.go:36, 9ab5b3ba7e05)
• Current documentation defines this as optional: The provider-backend contract names direct AWS, Machine0, and local-container as fixed-ID implementations and says warmup rejects other backends before provisioning. (docs/provider-backends.md:172, 9ab5b3ba7e05)
• ASCII Box lifecycle has a create-before-claim recovery boundary: The adapter creates a Box, validates it, and only then publishes its ownership claim, so fixed-ID support needs a proven provider-specific way to recover an interrupted creation without allocating a replacement. (internal/providers/asciibox/backend.go:55, 9ab5b3ba7e05)
• Recent ASCII Box lifecycle history: The latest direct provider lifecycle change is commit 67ccaef, “fix(ascii-box): persist deletion operations for safe cleanup retries (fix(ascii-box): persist deletion operations for safe cleanup retries #1731),” by Shun Kakinoki; the original provider feature dates to f870823 by Peter Steinberger. (internal/providers/asciibox/backend.go:36, 67ccaeff1bc6)
• Vision fit: VISION.md assigns provider-specific lifecycle rules to adapters and requires funded providers to have real create/use/destroy proof with no residue before merge. (VISION.md:3, 9ab5b3ba7e05)

Likely related people:

• Shun Kakinoki: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• 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.