fix(run): --id loads the configured provider before resolving the lease claim

[coygeek]

Summary

crabbox run --id <lease-or-slug> can fail before resolving a healthy reusable lease when the
configured default provider differs from the provider recorded in the lease's local claim. The run
loads the configured provider first, so a missing credential for that unrelated provider prevents
reuse even though the exact claim already identifies the correct provider and the lease is ready.

This is a non-security lifecycle-routing bug. It was reproduced with a local-container lease while
the configured default was Hetzner with no Hetzner credential.

Steps to reproduce

1. In a Git repository, configure or inherit provider=hetzner without setting HCLOUD_TOKEN or
   HETZNER_TOKEN.

2. Create a reusable local-container lease:

   crabbox warmup \
     --provider local-container \
     --slug provider-resolution-repro \
     --os ubuntu:24.04

3. Confirm the claim and lease are healthy:

   crabbox inspect \
     --provider local-container \
     --id provider-resolution-repro \
     --json

   The reproduced lease reported provider=local-container and state=leased with a ready SSH
   endpoint.

4. From the same repository, use the documented run-by-ID form without repeating the provider:

   crabbox run --id provider-resolution-repro --no-sync -- true
   echo "exit=$?"

5. Run the negative control against the same lease:

   crabbox run \
     --provider local-container \
     --id provider-resolution-repro \
     --no-sync \
     -- true

6. Release the lease:

   crabbox stop \
     --provider local-container \
     --target linux \
     --id provider-resolution-repro

Expected behavior

When --id names an exact local claim for the current repository and the caller did not explicitly
select a provider, run should resolve the claim and use its recorded provider to reuse the lease.
An unrelated configured provider should not need to initialize successfully.

The red/green closure signal is:

• with provider=hetzner configured and no Hetzner token, a claimed local-container lease succeeds
  through crabbox run --id <slug> --no-sync -- true without an explicit provider; and
• an explicit --provider remains authoritative, while a new run without --id retains the normal
  configured-provider behavior.

Actual behavior

The run without --provider exits with status 3 before reaching the lease:

HCLOUD_TOKEN or HETZNER_TOKEN is required
exit=3

The negative control with --provider local-container reuses the same claim and lease successfully:

lease=cbx_98151bfa77b4 slug=provider-resolution-repro provider=local-container target=linux
running on 127.0.0.1 true
command complete

Affected area

• internal/cli/run.go, particularly provider loading and reusable-lease resolution in
  runCommandWithBenchmarkRecord.
• Local lease claims used by run --id to bind a lease to its repository and provider.
• The provider-agnostic run --id examples and reuse contract in docs/commands/run.md.

Runtime or environment

• Crabbox CLI: 0.40.0
• Current source also inspected at main revision
  ce9487f552054326d9209d3ba9606d01a36f5666
• Host: macOS ARM64
• Container runtime: Docker client/server 29.6.2, Linux ARM64 server
• Lease provider: local-container
• Configured default provider: hetzner
• Coordinator: not configured

Evidence

The current main implementation loads configuration, applies lease flags, and calls
loadBackend(cfg, ...) before reusable-lease resolution. When --provider is absent, the configured
Hetzner provider therefore initializes first and rejects the missing credential before the supplied
slug can resolve to its local-container claim.

The claim itself was valid: explicit-provider inspect returned a ready local-container lease, and
the explicit-provider control ran true on it successfully. The only changed input between the red
and green runs was --provider local-container.

docs/commands/run.md describes --id as reusing an existing lease and repeatedly demonstrates
crabbox run --id <slug> ... without a provider flag. The concepts documentation also says the local
claim is required for run --id to resolve slugs and enforce repository ownership.

Open and closed Crabbox issues and pull requests were searched on 2026-08-08 for run --id, provider
resolution, lease claims, configured defaults, and the Hetzner credential error. No report for this
exact run-by-ID failure was found.

Impact

Reusable lease handles are not self-sufficient when the user's configured provider changes or when a
lease was created with a one-command provider override. Documented run --id workflows can fail with
an opaque credential error for a provider unrelated to the target lease, forcing callers to remember
and repeat provider-specific routing state already present in the claim.

This affects automation and handoffs in particular: a stable lease ID or slug appears sufficient, but
the command can stop before inspecting it.

Additional context

This is distinct from these existing open issues:

• bug(doctor): bare doctor fails on unchosen hardcoded Hetzner ship default #1247 concerns bare doctor treating the unchosen
  compiled Hetzner default as a hard readiness failure. This report concerns an explicit reusable
  lease whose claim identifies another provider.
• feat(list): add a credential-free local claim inventory across providers #1250 requests a read-only, all-provider local claim
  inventory while intentionally preserving provider-scoped list. This report concerns execution
  routing for one exact claimed lease.
• feat(local-container): support explicit native architecture selection #1242 covers explicit native architecture selection for
  local-container; it does not cover provider selection for lease reuse.

The current workaround is to repeat the provider on every reused command:

crabbox run --provider local-container --id <lease-or-slug> -- <command>

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 9, 2026, 6:54 PM ET / 22:54 UTC.

Summary
Keep open: current main and the latest release still load the configured backend before resolving --id, so an unrelated provider credential failure can block documented lease reuse.

Reproducibility: yes. —current source gives a high-confidence path: an implicit configured provider is loaded at internal/cli/run.go:556, while --id resolution occurs later at line 818; a claim contains the target provider.

Next step
The defect is narrow and source-proven, but bulk-filed context and the clawsweeper:no-new-fix-pr label prohibit automated repair dispatch.

Review details

Best possible solution:

Add a provider-neutral pre-backend route for an unambiguous local --id claim, retain explicit-provider behavior, and cover implicit reuse, explicit override, and new-lease paths with regression tests.

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

Yes—current source gives a high-confidence path: an implicit configured provider is loaded at internal/cli/run.go:556, while --id resolution occurs later at line 818; a claim contains the target provider.

Is this the best way to solve the issue?

Yes—the narrow provider-neutral route is consistent with the documented reuse contract and VISION.md’s requirement that claims retain routing metadata, provided explicit provider selection and ambiguous claims remain protected.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The repair must preserve an explicit --provider as authoritative and avoid silently selecting an ambiguous slug claim.

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

Label changes

Label justifications:

• P2: A documented reusable-lease workflow can fail when an unrelated configured provider lacks credentials.
• impact:other: The affected behavior is provider routing for lease reuse rather than a more specific owned impact class.

Evidence reviewed

What I checked:

• Current execution ordering: Current main loads the configured backend before entering the --id resolution branch, so backend configuration can fail before the local claim is considered. (internal/cli/run.go:556, ee6cf15b4cbc)
• Claim routing data exists: The local claim resolver can read an exact ID and scan claims for a slug; claims include a recorded provider, providing the data needed to route implicit reuse before backend initialization. (internal/cli/claim.go:1270, ee6cf15b4cbc)
• Documented reuse contract: The command documentation states that run --id reuses an existing lease and accepts a stable ID or slug without requiring a provider flag. (docs/commands/run.md:38, ee6cf15b4cbc)
• Release and current-main check: The routing files are unchanged between v0.41.1 and current main; the release tag contains the same backend-before-resolution ordering, so this remains shipped behavior. (internal/cli/run.go:556, 70aaebd10836)
• History provenance: Blame attributes both the backend-loading and --id resolution lines in the shipped source to the v0.41.1 release commit; no later change to these routing files is present on main. (internal/cli/run.go:818, 70aaebd10836)
• Maturity label unavailable: The required maturity shortlist helper could not locate qa/maturity-scores.yaml in this checkout, so no maturity label is supported despite the documented CLI contract.

Likely related people:

• Peter Steinberger: Current blame and the v0.41.1 release provenance attach the run ordering and claim resolution lines to this source history. (role: recent source contributor; confidence: high; commits: 70aaebd10836; files: internal/cli/run.go, internal/cli/claim.go)
• Vincent Koc: Repository shortlog shows substantial historical work across the run, status, and claim files, though the shallow available history does not expose an exact introducing commit. (role: substantial adjacent contributor; confidence: low; files: internal/cli/run.go, internal/cli/status.go, internal/cli/claim.go)

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.