RFC 0012: Gateway-Independent OpenClaw Core

[fuller-stack-dev]

Summary

• Propose a Host-owned OpenClaw core that keeps conversations, sessions, cron, heartbeat, tasks, and durable delivery intent running independently of channel connectivity and Control Server restarts.
• Preserve the existing openclaw gateway command, gateway.* config, protocol, UI/TUI/CLI behavior, and external plugins through a Compatibility Supervisor and automatic legacy co-located placement.
• Make configuration reload and restart behavior owner-scoped, then roll out the logical and physical split through proof-gated phases.
• Include a detailed implementation-plan sidecar covering ordered work packages, plugin-developer compatibility, rollout gates, risks, and fault/upgrade proof.

Visual Proposal

• Pagedrop: Gateway-Independent OpenClaw Core implementation proposal

Verification

• git diff --check origin/main...HEAD
• RFC frontmatter, required heading order, and one-paragraph summary validator
• RFC-relative link validator
• Current-source survey against openclaw/openclaw main at 127e174c9e4de36f2eccb96300bb3efa69ae9a32

Process Follow-up

• Create the required maintainer-discussion thread for the RFC.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 15, 2026, 11:53 AM ET / 15:53 UTC.

ClawSweeper review

What this changes

The PR adds RFC 0012 and a phased implementation plan for separating OpenClaw’s durable core runtime from Gateway and channel lifecycles while preserving Gateway compatibility.

Merge readiness

⚠️ Ready for maintainer review - 4 items remain

Keep open: this member-authored draft RFC is a coherent architecture proposal, not work already implemented on current main, and acceptance requires an explicit maintainer decision on its compatibility contract.

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

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The RFC is a coherent, focused proposal whose merge readiness is intentionally gated on maintainer direction rather than runtime proof.
Proof confidence	🌊 off-meta tidepool	Not applicable: This documentation-only RFC does not require after-fix runtime proof; acceptance instead depends on an explicit architecture decision.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This documentation-only RFC does not require after-fix runtime proof; acceptance instead depends on an explicit architecture decision.
Evidence reviewed	5 items	RFC lifecycle policy: Current repository policy says draft RFCs must remain unmerged, require a maintainer-discussion thread, and may be accepted only after creating an implementation issue and updating the RFC status. Current main does not contain the proposed RFC: A current-tree search found no Gateway-independent-core RFC, Compatibility Supervisor, or equivalent proposal on main; the RFC paths have no local history, so this PR’s central contribution is not already implemented in this repository. RFC process provenance: The current lifecycle and template guidance dates to the RFC-process update by kevinlin-openai and the sidecar-layout clarification by Dallin Romney.
Findings	None	None.
Security	None	None.

How this fits together

The proposal concerns OpenClaw’s runtime composition boundary: channels and control clients currently enter through Gateway, which also owns sessions, scheduled work, and delivery behavior. It proposes a Host-owned core while retaining existing Gateway-facing commands, configuration, protocols, and plugin behavior.

flowchart LR
  A[Channel connections] --> B[Gateway compatibility layer]
  C[Control clients] --> B
  B --> D[Host-owned core]
  D --> E[Sessions and conversations]
  D --> F[Scheduled work and tasks]
  D --> G[Durable delivery intent]
  D --> H[Compatible Gateway outputs]

Loading

Decision needed

Question	Recommendation
Should OpenClaw adopt the proposed Host-owned core direction and its stated compatibility guarantees for existing Gateway commands, configuration, protocol clients, and plugins?	Accept the RFC direction: Adopt the Host-owned core target and use the phased plan as the compatibility contract for follow-on implementation work.

Why: This RFC selects a long-term runtime ownership and rollout policy; source review cannot determine whether maintainers want to commit to that product and compatibility direction.

Before merge

• Resolve merge risk (P1) - Accepting the RFC commits maintainers to preserve Gateway commands, configuration, protocol clients, and plugin behavior through a major lifecycle split.
• Resolve merge risk (P1) - Moving ownership of sessions and durable delivery intent requires future fault and upgrade proof to prevent state discontinuity, dropped work, or misrouted delivery.
• Complete next step (P2) - A maintainer must decide whether to adopt the proposed runtime ownership and compatibility contract before any implementation work is queued.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Proposal scope	2 new documents, 919 added lines	The PR is an architectural RFC plus implementation-plan sidecar, rather than an executable runtime change.

Merge-risk options

Maintainer options:

1. Approve an explicit compatibility contract first (recommended)
   Require an architecture owner to confirm the Gateway, plugin, session, and delivery guarantees before accepting the RFC.
2. Narrow the first phase
   Accept only an in-process ownership split with fault and upgrade proof before committing to a supervised process boundary.
3. Pause the RFC
   Defer the proposal if maintainers do not want to own its long-term compatibility commitment.

Technical review

Best possible solution:

Record an explicit architecture decision, create the required maintainer-discussion thread, and—if accepted—open the implementation issue before changing the RFC status and merging it.

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

Not applicable: this PR proposes an architecture and rollout direction rather than reporting a current failing behavior.

Is this the best way to solve the issue?

Unclear: the staged compatibility-first approach is coherent, but accepting this long-term runtime ownership change requires maintainer product and architecture judgment.

AGENTS.md: not found in the target repository.

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

Labels

Label justifications:

• P2: This is a significant but non-urgent architecture proposal awaiting an explicit maintainer direction.
• merge-risk: 🚨 compatibility: The RFC commits to preserving existing Gateway commands, configuration, protocol behavior, and external plugins through a lifecycle split.
• merge-risk: 🚨 message-delivery: The proposal relocates durable delivery intent across ownership boundaries, which must avoid drops or misrouting during rollout.
• merge-risk: 🚨 session-state: The proposal relocates responsibility for conversations and sessions, making state continuity an explicit acceptance concern.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• feature: ✨ showcase: ClawSweeper spotlight: unusually compelling feature idea for maintainer attention. The proposal identifies a high-leverage reliability direction: separating durable agent work from transport and control-server lifecycles while preserving installed integrations.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This documentation-only RFC does not require after-fix runtime proof; acceptance instead depends on an explicit architecture decision.

Evidence

What I checked:

• RFC lifecycle policy: Current repository policy says draft RFCs must remain unmerged, require a maintainer-discussion thread, and may be accepted only after creating an implementation issue and updating the RFC status. (README.md:80, af708f0ddb6f)
• Current main does not contain the proposed RFC: A current-tree search found no Gateway-independent-core RFC, Compatibility Supervisor, or equivalent proposal on main; the RFC paths have no local history, so this PR’s central contribution is not already implemented in this repository. (rfcs/0012-gateway-independent-core.md:1, af708f0ddb6f)
• RFC process provenance: The current lifecycle and template guidance dates to the RFC-process update by kevinlin-openai and the sidecar-layout clarification by Dallin Romney. (README.md:38, e366ea9825a4)
• Submitted scope: The supplied PR metadata identifies two new documentation files: the RFC and its implementation-plan sidecar, totaling 919 added lines; the PR body itself records the required maintainer-discussion thread as follow-up. (rfcs/0012-gateway-independent-core.md:1, ffa5250ddcb4)
• Local inspection limitation: The checkout is a blobless promisor clone and the PR-head object could not be fetched because GitHub DNS resolution failed; the PR review therefore uses the supplied hydrated PR body, file list, and patch context alongside local current-main policy inspection. (ffa5250ddcb4)

Likely related people:

• kevinlin-openai: Authored the current RFC-process update that defines draft, discussion, acceptance, and implementation-issue requirements. (role: RFC process contributor; confidence: high; commits: e366ea9825a4; files: README.md, rfcs/0000-template.md)
• Dallin Romney: Authored the current documentation clarifying RFC sidecar material, directly relevant to this RFC plus implementation-plan structure. (role: RFC sidecar-layout contributor; confidence: high; commits: 3aa7d727383f; files: README.md, rfcs/0000-template.md)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Create the required maintainer-discussion thread and capture an explicit decision on the compatibility contract.

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 (46 earlier review cycles; latest 8 shown)

• reviewed 2026-08-09T19:46:51.029Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-09T22:01:02.495Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-09T23:10:23.459Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-11T03:13:44.298Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-12T01:10:10.917Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-13T22:36:02.619Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-14T04:27:08.502Z sha ffa5250 :: needs maintainer review before merge. :: none
• reviewed 2026-08-14T07:01:40.932Z sha ffa5250 :: needs maintainer review before merge. :: none