RFC: Remote Agent Harness Bridge

[omarshahine]

Summary

Adds a draft RFC for a first-class remote AgentHarness bridge in OpenClaw.

Notes

• Status starts as draft.
• Implementation issue is intentionally blank until accepted.
• rfc_pr frontmatter points to this draft PR.

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed July 6, 2026, 7:27 PM ET / 23:27 UTC.

Summary
The PR adds a 410-line draft RFC for a first-class remote AgentHarness bridge with a remote-harness plugin, frame protocol, transport configuration, and fail-closed runtime selection.

Reproducibility: not applicable. This PR adds an RFC document, not a runtime bug with a failing behavior path. The reviewable check is source inspection of the RFC file and repository lifecycle guidance.

Review metrics: 3 noteworthy metrics.

• Diff Surface: 1 file added, 410 lines. The review surface is a new RFC document, so process, numbering, and product direction are the main merge questions.
• RFC Id Conflict: 1 existing 0009 file on main. The added file reuses an existing RFC id and needs renumbering before merge.
• Lifecycle State: draft status, 0 maintainer reviews. README says draft RFCs need discussion and acceptance before merging.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🌊 off-meta tidepool
Patch quality: 🦐 gold shrimp
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Rename the RFC file to an unused id such as the next maintainer-assigned number.
• [P2] Add or link the required maintainer-discussion thread before moving out of draft.

Risk before merge

• [P1] The RFC is still status: draft; README says draft RFCs should not merge to main and requires a maintainer-discussion thread before acceptance.
• [P1] The proposal commits OpenClaw to new runtime, plugin, configuration, transport, and security-boundary direction, so markdown correctness is not enough for product acceptance.
• [P1] The current head still adds a second top-level RFC using id 0009, which leaves RFC references and any future sidecar directory ambiguous.

Maintainer options:

1. Decide the mitigation before merge
   Keep this open as a draft RFC, renumber it to an unused RFC id, add maintainer-discussion evidence, and have maintainers decide whether the remote harness bridge belongs in accepted OpenClaw direction.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] A narrow repair can renumber the RFC file, but it must not change status, implementation issue, or product direction.

Maintainer decision needed

• Question: Should OpenClaw accept a first-class remote-harness AgentHarness bridge as core RFC direction after the numbering and RFC lifecycle gaps are fixed?
• Rationale: The draft proposes new runtime/plugin/configuration/security-boundary surface, and repository lifecycle guidance requires maintainer discussion and acceptance before merge.
• Likely owner: kevinlin-openai — They authored the RFC lifecycle guidance used to decide whether this draft can advance.
• Options:
  • Keep Draft For Discussion (recommended): Keep the PR open as a draft, require an unused RFC id and maintainer-discussion thread, then evaluate acceptance.
  • Accept After Mechanical Fixes: Approve the remote-harness direction and merge only after the id, lifecycle metadata, and implementation issue are updated appropriately.
  • Decline Core Direction: Close or redirect the idea to an external/plugin experiment if maintainers do not want this committed in core RFCs.

Security
Cleared: The diff is Markdown-only and does not change code, dependencies, workflows, or secrets handling; the remote-execution security model remains a product-design review topic.

Review findings

• [P2] Renumber the new RFC before merge — rfcs/0009-remote-agent-harness-bridge.md:1

Review details

Best possible solution:

Keep this open as a draft RFC, renumber it to an unused RFC id, add maintainer-discussion evidence, and have maintainers decide whether the remote harness bridge belongs in accepted OpenClaw direction.

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

Not applicable; this PR adds an RFC document, not a runtime bug with a failing behavior path. The reviewable check is source inspection of the RFC file and repository lifecycle guidance.

Is this the best way to solve the issue?

No as-is; the RFC is an appropriate place to discuss the direction, but the duplicate RFC id must be fixed and maintainer discussion/acceptance is required before merge.

Full review comments:

• [P2] Renumber the new RFC before merge — rfcs/0009-remote-agent-harness-bridge.md:1
  The earlier review already raised this, and the current head still adds rfcs/0009-remote-agent-harness-bridge.md while main already has rfcs/0009-hosted-feeds-for-plugins-and-skills.md. Keeping two top-level RFCs under the same id makes README's <id>-<short-name>.md convention and optional rfcs/<id>/ sidecar directory ambiguous, so please rename this proposal to an unused RFC id before merge.
  Confidence: 0.94

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: not found in the target repository.

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

Label changes

Label justifications:

• P3: This is a draft RFC/product proposal with a low-risk documentation-process blocker, not an urgent runtime regression.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: Not applicable: this PR only adds an RFC document, so there is no after-fix product behavior for the contributor to demonstrate.

Evidence reviewed

Acceptance criteria:

• [P1] find rfcs -maxdepth 1 -type f -name '[0-9][0-9][0-9][0-9]-*.md' -print | sort.
• [P1] git diff --check origin/main...HEAD.

What I checked:

• Target AGENTS.md check: No AGENTS.md exists inside the openclaw/rfcs target repository root, so no target-specific AGENTS policy applied. (a8e0ba2701d6)
• PR diff surface: The PR adds one new Markdown RFC file with 410 inserted lines; the frontmatter starts as status: draft and points rfc_pr to this PR. (rfcs/0009-remote-agent-harness-bridge.md:1, 753c64390912)
• RFC id collision: Current main already contains rfcs/0009-hosted-feeds-for-plugins-and-skills.md, while this PR adds another top-level 0009 RFC file. (rfcs/0009-hosted-feeds-for-plugins-and-skills.md:1, a8e0ba2701d6)
• RFC process guidance: README says new RFCs use <id>-<short-name>.md, draft RFCs should not merge to main, and each new RFC needs a maintainer-discussion thread before acceptance. (README.md:45, f4fdf38f4717)
• Lifecycle flow provenance: The accepted RFC flow requires a discussion thread, accepted status, implementation issue, and then merge; this PR is still draft with no maintainer review visible. (README.md:88, e366ea9825a4)
• Live PR state: GitHub reports this PR is open, draft, mergeable, has one changed file, no assignees, no review requests, and no maintainer reviews; the previous ClawSweeper comment raised the same renumbering blocker at the current head. (753c64390912)

Likely related people:

• kevinlin-openai: Authored the README/template guidance governing RFC naming, draft status, and acceptance flow used for this review. (role: RFC process author; confidence: high; commits: f4fdf38f4717, e366ea9825a4; files: README.md, rfcs/0000-template.md)
• Dallin Romney: Recently clarified the RFC sidecar layout in the same README/template area relevant to duplicate numeric ids. (role: recent RFC structure contributor; confidence: medium; commits: 3aa7d727383f; files: README.md, rfcs/0000-template.md)
• Gio Della-Libera: Authored and updated the current main RFC already using id 0009, which is the concrete collision with this PR. (role: existing RFC id owner; confidence: medium; commits: 89cf322325b0, a8844eb53a2b; files: rfcs/0009-hosted-feeds-for-plugins-and-skills.md)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

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.

Review history (1 earlier review cycle)

• reviewed 2026-07-06T23:23:03.159Z sha 753c643 :: needs real behavior proof before merge. :: [P2] Renumber the new RFC file before merge

[omarshahine]

Closing this draft in favor of #31.

Eduardo's RFC carries the same remote AgentHarness direction with the fuller event protocol, Gateway-owned decision flow, terminal/persistence semantics, transport/container boundary, and conformance target. Keeping one draft will make review cleaner, so #31 should be the canonical discussion thread for this proposal going forward.