Target-hosted snapshot command terminates its lifecycle owner and leaves the gateway stopped

[hannesrudolph]

Summary

Running ocm env snapshot create <env> from an agent process hosted by that
same target environment stops the Gateway that owns the caller before the
snapshot can complete.

In the observed run, the command lost its caller, created no snapshot, and left
the target service stopped. A different gateway had to take over recovery.

Environment

• OCM 0.2.33
• macOS arm64
• Target environment: openclaw
• Target binding at reproduction: source-full OpenClaw 2026.8.1
  (fleet-main-692cb7b1f28-installed-full)
• Caller: clawcode Codex agent hosted by the openclaw Gateway

Reproduction

1. Start an agent turn on OCM environment openclaw.

2. From that agent's Code Mode process, run:

   ocm env snapshot create openclaw \
     --label pre-openclaw-2026.8.2-20260901 \
     --json
   

3. Observe the target Gateway and caller process while snapshot creation
   enters its cold/stopped phase.

Actual behavior

The snapshot command emitted progress through 181 seconds:

[ocm] Creating snapshot for openclaw (166s elapsed; still running)
[ocm] Creating snapshot for openclaw (181s elapsed; still running)

Then:

• OCM stopped the target Gateway and changed its service state to
  running=false, desiredRunning=false.
• The Gateway WebSocket closed with code 1006 because the caller's own
  Gateway went away.
• The Clawcode agent process, its OCM snapshot child, and the wrapper process
  were no longer present.
• The durable handoff receipt remained running.
• ocm env snapshot list openclaw --json showed no new snapshot.
• The environment remained stopped on the old 2026.8.1 binding.

A Rescue-hosted operator then took ownership and ran the same snapshot command
from outside the target environment. It completed successfully in about 84
seconds and created checkpoint 1788306816-305800000.

Expected behavior

OCM should not leave a target stopped with no snapshot merely because the
caller was hosted by the target Gateway.

Possible acceptable contracts:

• Refuse the command before mutation when OCM can prove the caller belongs to
  the target Gateway, with guidance to run it from another environment.
• Move the cold snapshot operation into a daemon-owned transaction that
  survives caller disconnection and restores the recorded service policy.
• Provide a durable asynchronous transaction receipt that an external owner
  can monitor and recover without replaying the command.

Impact

• A lifecycle agent can terminate itself mid-command.
• The command has an unknown terminal outcome from the agent's perspective.
• The target remains unavailable until another gateway or human takes over.
• Naive retry risks duplicate lifecycle work because the original receipt is
  still nonterminal.

Evidence boundary

Proven:

• The target-hosted agent invoked the command.
• OCM stopped the target.
• The caller and snapshot process disappeared.
• No new snapshot was created.
• The target remained stopped until external recovery.
• The same command completed when run from a different Gateway.

Unknown:

• Which layer should own self-lifecycle admission: OCM CLI, OCM daemon, or
  OpenClaw task handoff.
• Whether the snapshot copy itself had begun before the caller was terminated;
  no terminal command result survived.

Evidence

The complete local receipt, logs, process observations, and recovery proof are
under:

/Users/hrudolph/.ocm/artifacts/openclaw-8.2/2026-09-01/openclaw-8.2-20260901T232956Z/

Key files:

• 59-production-pre-snapshot-command.log
• receipt.json
• proof.json
• 60-rescue-takeover-snapshot-list-command.log
• 61-rescue-production-snapshot-command.log

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 4, 2026, 8:57 AM ET / 12:57 UTC.

Summary
Keep open for maintainer confirmation: current release v0.2.38 contains a targeted self-lifecycle guard that covers snapshot quiescence, but this member-authored report is not eligible for automated closure.

Reproducibility: no. for the reported failure on current main: the source now separates a target-owned caller from the Gateway process group, or refuses before stopping the Gateway. The historical v0.2.33 scenario is clearly mapped to that guarded path, but no current live run was performed in this read-only review.

Regression provenance
Possible regression — probable (reproduction; failure trace; reviewed change). No predecessor PR is attributed.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Maintainer decision needed

Question	Recommendation
Should this member-authored report be closed as fixed after a maintainer confirms the v0.2.38 target-hosted snapshot path creates a checkpoint and restores the Gateway?	Confirm and close: Run or accept a current v0.2.38 target-hosted snapshot verification, then close as fixed.

Why: Source and release provenance strongly indicate that the reported macOS process-group failure is addressed, but member-authored items require explicit maintainer judgment rather than automated closure.

Next step
No repair PR is appropriate: current released code appears to address the failure, and explicit maintainer confirmation is required before closing this member-authored report.

Review details

Best possible solution:

Retain the current pre-quiescence ownership guard and confirm it with one target-hosted snapshot run on the released build before closing the report as fixed.

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

No for the reported failure on current main: the source now separates a target-owned caller from the Gateway process group, or refuses before stopping the Gateway. The historical v0.2.33 scenario is clearly mapped to that guarded path, but no current live run was performed in this read-only review.

Is this the best way to solve the issue?

Yes, the current pre-quiescence ownership guard is the narrowest solution because it protects the caller before any Gateway stop while leaving external and other-environment callers unchanged.

AGENTS.md: not found in the target repository.

Remaining risk / open question:

• The current test coverage verifies group classification but does not provide a captured target-hosted snapshot run on current v0.2.38 showing both checkpoint creation and Gateway restoration.

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

Label changes

Label justifications:

• P1: A failed snapshot can leave a managed Gateway unavailable until another operator recovers it.
• impact:crash-loop: The report concerns process-level Gateway availability after lifecycle teardown.

Evidence reviewed

What I checked:

• Current snapshot lifecycle path: The snapshot-create handler locks the environment, prepares capture, quiesces the service, creates the checkpoint, and always attempts service restoration after capture. (src/cli/env.rs:809, c5e7126c9b6c)
• Self-owned caller preservation: Before stopping a running target, snapshot quiescence calls the preservation guard. On Unix it identifies a caller in the target Gateway process group, moves it to a new group, or returns an error before the stop when the operation owns that group. (src/service/mod.rs:169, c5e7126c9b6c)
• Documented snapshot contract: The usage guide states that snapshot create stops a running managed Gateway and restores the recorded service policy afterward. (docs/USAGE.md:442, c5e7126c9b6c)
• Fix and release provenance: Path history identifies merged commit e04c101, "fix: managed Gateway upgrades no longer stop midway (fix: managed Gateway upgrades no longer stop midway #135)", in the lifecycle module; it is contained in v0.2.36, v0.2.37, v0.2.38, and current main. (src/service/mod.rs:296, e04c10166d6b)

Likely related people:

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