[stevenlee-oai]

Two containers can write the same ordinary Docker volume even after the original Gateway has stopped. This RFC21 follow-up asks how Compute could prevent competing writers from attaching to embedded Agent state while a replacement recovers. Compute and runtime maintainers can review this storage guarantee separately from Gateway managed mode. Proposal

OCE #2982 accepts temporary operator recovery after an embedded hard crash. OCE #2633 implements unattended recovery for a verified Docker predecessor and the first Gateway container restarted by kubelet in the same Pod. Both cases passed its restart check at bb403839. A new Pod with an unverifiable owner requires operator confirmation. #3355 covers dedicated Gateway state. Managed mode #2982 · Unattended recovery #2633 · Passing restart check · Dedicated recovery #3355

On Docker Engine 29.9.0, the stopped Gateway retained its name and was the only listed attachment. A differently named initializer then mounted the same volume and wrote a marker. A separate reader saw the write. The proposal describes how to test a storage mechanism against that case. No provider mechanism has been selected.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR proposes provider-verified recovery of embedded Gateway state after an unclean stop and links the plan from RFC-0021.

Example: An embedded Gateway using OpenClaw 9cc4450e is killed and replaced on its retained state volume.

• Before: The replacement cannot verify the foreign-namespace owner and refuses automatic takeover.
• After: The proposal permits automatic confirmation only after Compute proves exact predecessor termination and exclusive volume custody; otherwise an operator confirms recovery.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A useful, bounded proposal with no concrete introduced defect; the provider custody mechanism remains an explicit design decision.
Proof confidence	🌊 off-meta tidepool	Not applicable: This PR changes specifications only and claims no unattended implementation; the inspected linked screenshot shows simulated managed-mode UI, and its video preparation failed with ffprobe ENOENT with no browser tool available, neither affecting this proposal's proof requirements.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Docs · Worth it: Yes
User problem: An embedded Gateway replacement can remain unavailable after an unclean stop because retained locks belong to an unverifiable process in another PID namespace.
Reason: The maintainer-authored proposal records a concrete rollout dependency and the necessary safety boundary without claiming implementation or provider qualification.

Merge readiness

⛔ Blocked before merge - 1 item remains

Keep this PR open for Compute and runtime design review: it identifies a concrete recovery boundary, preserves operator confirmation when custody is uncertain, and introduces no runtime changes.

Priority: P2
Reviewed head: e5c0c5c90d4cace9616232706f68e6757e86342d
Owner decision: Required. See Decision needed.

Decision needed

• Question: Which deployment mechanism can enforce exclusive volume access across the embedded Gateway, workspace initializer, and other Docker clients throughout recovery?
• Recommendation: Qualify enforceable provider custody: Compute and runtime owners identify an enforceable deployment boundary and retain the disabled automation gate until its success and competing-writer cases pass.
• Why: The proposal explicitly leaves this mechanism open because container-name reservation and a one-time attachment inventory do not prevent another writer.

Before merge

• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

Compute manages Agent workloads and retained volumes; the proposed bootstrap would combine provider custody evidence with OpenClaw's fingerprinted recovery command before admitting model work.

flowchart TB
  A[Stopped embedded Gateway] --> B[Retained Agent state]
  C[Compute Driver] -. verifies termination and custody .-> D[Proposed trusted bootstrap]
  B -. inspected locks .-> D
  D -. qualified custody .-> E[Native recovery and first chat]
  D -. unresolved custody .-> F[Operator confirmation]

Loading

Technical review

Best possible solution:

Keep automatic recovery disabled until a provider can enforce exclusive custody throughout handoff and qualify successful recovery plus competing-writer refusals.

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

No runtime reproduction is required for this documentation-only PR; source inspection confirms the shared-volume initializer and heartbeat-aging test assumptions, while the linked failed job belongs to the managed-mode branch.

Is this the best way to solve the issue?

The proposal uses the existing Compute lifecycle and native fingerprinted recovery command, correctly separating exact termination from exclusive custody and preserving operator recovery when either cannot be established.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 1bd061c09f1c.

Provenance checked

• RFC-0021 remaining work keeps the original intent (fcc969f: RFC-0021: Define the runtime contract for OCE-managed deployments #2367 proposed managed-runtime restrictions while explicitly leaving runtime qualification incomplete.)

Security

None.

Evidence

What I checked:

• Pinned documentation-only introduction: The introduced diff adds the planned recovery document and changes only the RFC's remaining-work paragraph; no production code, schema, dependencies, or tests change. (specs/plans/0048-embedded-gateway-owner-recovery.md:8, e5c0c5c90d4c)
• Existing Docker owners support the proposed distinction: The workspace initializer mounts the Agent's persistent state under a separate container name, while container removal uses force deletion without retaining the proposed termination evidence; Gateway-name reservation therefore cannot establish the proposed custody guarantee. (apps/controller/src/drivers/compute/docker/index.ts:788, 1bd061c09f1c)
• Current restart test has a different assumption: Current main artificially ages the killed owner's heartbeats before replacement; the proposal accurately distinguishes that image test from qualification of unattended provider-controlled recovery. (tests/integration/runtime-image-gateway-unclean-restart.test.mjs:185, 1bd061c09f1c)
• Kubernetes contract already distinguishes access mode from fencing: The current storage reference states that ReadWriteOnce permits multiple Pods on one node and requires operator fencing for partitioned or forced replacements, consistent with the proposal's separate Kubernetes qualification. (docs/reference/drivers/kubernetes-compute/storage-and-credentials.md:52, 1bd061c09f1c)
• Linked work remains distinct: feat: add Gateway managed mode to Agent deployments #2982 records the embedded restart failure and explicitly links this proposal; feat(compute): isolate Docker Gateway state and verify ownership before recovery #3355 scopes recovery to dedicated private state and leaves automatic recovery disabled in ordinary composition.
• Explicit native recovery dependency: The plan directly relies on this pinned implementation: recovery compares the inspected fingerprint and refuses a demonstrably live holder; the proposed Compute responsibility supplies the separate custody guarantee. (src/infra/gateway-lock-recovery.ts:90, 9cc4450e9d79)

Labels

Label changes:

• add P2: This scoped design proposal addresses retained-state restart qualification without changing current runtime behavior.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.

Label justifications:

• P2: This scoped design proposal addresses retained-state restart qualification without changing current runtime behavior.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed October 26, 2026, 2:40 PM ET / 18:40 UTC.