docs: propose guest foreground work and restart notices

[vincentkoc]

What Problem This Solves

Guest users need a clear outcome when a Gateway restart interrupts their work. Automatically resuming that work requires authority and recovery machinery that the first guest experience does not need.

Why This Change Was Made

Propose bounded foreground guest turns, a persistent stopped-after-restart notice, and a fresh authorized request to continue in the same thread. Reuse existing session, transcript, and sandbox registry SQLite payloads: no new table, column, database, sidecar, or schema-version bump. The allocation marker retirementPolicy: 'foreground-owner' keeps cleanup with its original owner until whole-process shutdown is confirmed.

User Impact

This is a design proposal only. History remains available, interrupted guest work never resumes automatically, and staff behavior stays unchanged. Durable jobs and unqualified detached execution remain outside the initial guest profile. Generic cleanup retains marked or uncertain allocations. Older builds can ignore both markers, so incompatible downgrades require quiescing and reconciliation under compatible code first. Schema compatibility alone does not make rollback safe. Runtime containment and engine qualification remain implementation requirements.

Related proposals: #70 and #71.

Evidence

• Compared the design against frozen OpenClaw source b6bd69d6e85f9a2d6ae5f0bf15e5fcfe6dd88490; exact owner links are in the RFC.
• Checked required template sections, draft metadata, frozen source links, public privacy, and whitespace.
• Technical prose lint passes with zero hard findings; retained advisory wording preserves uncertainty about external effects.
• Independent source-informed design review completed before final publication.
• No runtime code, schema, server configuration, or deployment changes. End-to-end lifecycle proof belongs to the implementation.

The required maintainer-discussion thread is pending. This RFC remains draft and unmerged, with no implementation issue until acceptance.

[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. Reviewed September 23, 2026, 12:23 AM ET / 04:23 UTC (Revision 3).

ClawSweeper review

What this changes

Adds an RFC proposing bounded guest turns, persistent restart-interruption notices, fresh authorization to continue, and owner-controlled cleanup of retained sandbox allocations.

Merge readiness

⛔ Blocked before merge - 2 items remain

Keep open for maintainer discussion and acceptance. This is a coherent, distinct draft proposal with no blocking document defects found; current main does not contain it, and the related durable-work proposals do not supersede it.

Priority: P3
Reviewed head: 0e4434284515c4cc38cb615db8d677bbf848c85f
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused, source-anchored RFC with explicit implementation boundaries and no blocking document defects; pending acceptance does not reduce patch quality.
Proof confidence	🌊 off-meta tidepool	Not applicable: This member-authored RFC changes only proposal text, so runtime proof is not a merge gate here; no stored-data implementation changes, migration, or deployed compatibility claim are introduced.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This member-authored RFC changes only proposal text, so runtime proof is not a merge gate here; no stored-data implementation changes, migration, or deployed compatibility claim are introduced.
Evidence reviewed	8 items	Pinned introduced change: Read the complete introduced diff: one new 347-line RFC, with no executable, deployment, dependency, or storage implementation changes. The whitespace check passed. Required acceptance process: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted metadata before merging. The captured body and latest author comment explicitly confirm that discussion and acceptance remain pending. Re-review continuity: The prior review had no findings. The latest commit adds allocation retirement ownership, uncertain-cleanup retention, and explicit incompatible-downgrade restrictions. Local comparison against the previous head failed because a required historical blob could not be fetched (HTTP 403); the exact commit patch was then inspected through GitHub's API.
Findings	None	None.
Security	None	None.

How this fits together

The proposed Gateway policy sits between authenticated guest requests and model or tool execution. Session and transcript records preserve interrupted-turn outcomes, while sandbox allocation records keep cleanup separate from permission to resume work.

flowchart TD
  A[Guest request] --> B[Current authorization]
  B --> C[Bounded foreground turn]
  C --> D[Session and allocation records]
  E[Gateway restart] --> F[Stop recovery]
  D --> F
  F --> G[Persistent interruption notice]
  D --> H[Owner confirms shutdown before cleanup]

Loading

Decision needed

Question	Recommendation
Should the initial shared-Gateway guest profile prohibit durable execution and use the proposed restart-stop and allocation-retention contract?	Accept the bounded guest direction: After maintainer discussion, accept the design with its documented containment and rollback qualification gates.

Why: This selects guest capabilities and operational tradeoffs; the repository requires explicit discussion and acceptance before the RFC can merge.

Before merge

• Complete next step (P2) - Create and link the required maintainer-discussion thread; obtain acceptance, then create the implementation issue and update RFC status and issue metadata before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

None.

Technical review

Best possible solution:

Adopt a bounded guest lifecycle with explicit interruption outcomes and conservative cleanup, while retaining runtime containment and upgrade qualification as implementation gates.

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

Not applicable: this PR proposes future behavior and does not claim to fix an executable defect in this repository.

Is this the best way to solve the issue?

Yes as a design proposal: it reuses named lifecycle and storage owners, separates terminal outcomes from physical shutdown, and makes rollback limitations explicit; product acceptance remains a human decision.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 967d9aac7472.

Labels

Label changes:

No label changes.

Label justifications:

• P3: This is a design-document addition with no immediate runtime or deployment effects.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This member-authored RFC changes only proposal text, so runtime proof is not a merge gate here; no stored-data implementation changes, migration, or deployed compatibility claim are introduced.

Evidence

What I checked:

• Pinned introduced change: Read the complete introduced diff: one new 347-line RFC, with no executable, deployment, dependency, or storage implementation changes. The whitespace check passed. (rfcs/0039-guest-foreground-work-and-restart-notices.md:1, 0e4434284515)
• Required acceptance process: README requires a maintainer-discussion thread, acceptance, an implementation issue, and accepted metadata before merging. The captured body and latest author comment explicitly confirm that discussion and acceptance remain pending. (README.md:80, 967d9aac7472)
• Re-review continuity: The prior review had no findings. The latest commit adds allocation retirement ownership, uncertain-cleanup retention, and explicit incompatible-downgrade restrictions. Local comparison against the previous head failed because a required historical blob could not be fetched (HTTP 403); the exact commit patch was then inspected through GitHub's API. (rfcs/0039-guest-foreground-work-and-restart-notices.md:233, 0e4434284515)
• Current-main and related-proposal boundary: Current main's tracked RFCs and guest/foreground/restart searches do not contain this proposal. The supplied bodies for docs: propose service-owned work authority #70 and docs: propose persistent Agent runtime lifecycle #71 describe broader durable Enterprise execution; both remain open and unmerged. This RFC explicitly preserves their separate scope. (rfcs/0039-guest-foreground-work-and-restart-notices.md:328, 0e4434284515)
• Explicit dependency contract: The RFC cites frozen openclaw/openclaw storage and recovery owners as reusable mechanisms, explicitly distinguishing them from an implemented guest policy. These links justify checking that dependency's storage contract; no Codex dependency is asserted. (rfcs/0039-guest-foreground-work-and-restart-notices.md:184, 0e4434284515)
• Allocation storage anchor verified: The cited registry serializes allocation metadata into sandbox_registry_entries.entry_json and has exact-generation retirement checks. This supports the proposed storage location, without proving the proposed retirement policy already exists or that old readers preserve it. (src/agents/sandbox/registry.ts, b6bd69d6e85f)

Likely related people:

• unknown: The claimed source-line change could not be verified from bounded local history. (role: source history unknown; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (2 earlier review cycles)

• reviewed 2026-09-22T12:59:06.874Z sha 228b602 :: blocked before merge. :: none
• reviewed 2026-09-22T13:30:59.691Z sha a36dc5d :: blocked before merge. :: none

[vincentkoc]

@clawsweeper re-review

Please review exact head 0e44342. The RFC remains draft pending maintainer discussion and acceptance.

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/35818280507
• Updated: 2026-09-23T04:25:55.379Z