docs: propose host-owned process execution authorization

[beenhero]

Related: openclaw/openclaw#97152

What Problem This Solves

Host-owned process execution paths cannot currently require a plugin's external verification through the lifecycle accepted in RFC 0011. The alternatives are a competing generic approval path or a second resolver lifecycle, neither of which gives one clear authorization owner.

Why This Change Was Made

This draft narrows the earlier cross-harness resolver proposal to one concrete capability: host-owned process.exec. It reuses OpenClaw-owned approval and attempt state, lets configuration select one provider, binds authorization to an exact executable subject, keeps generic allow unavailable while verification is required, and keeps provider proofs outside core. It explicitly does not claim universal tool or harness coverage.

User Impact

There is no runtime change in this RFC. If accepted and implemented, external providers such as wallet or hardware-key plugins could gate exact Codex command executions and later command-automation adapters without replacing the process runner. Provider-owned standing grants could avoid repeat ceremonies while each invocation still receives a host-bound authorization.

Evidence

• Compared the proposal against accepted RFC 0011 and the open state/SDK/runtime/TUI implementation slices in feat(approvals): persist external verification attempts openclaw#134897 through #134901.
• Inspectable redacted immutable-execution drill: a real owner signature was cold-verified, mutation of the source path did not alter the published bytes executed, and authorization preceded process completion.
• Inspectable redacted scheduled standing-grant drill: the no-approval control started no process; one signature covered four distinct occurrences; revocation survived restart.
• Inspectable redacted manual standing-grant drill: the second distinct manual occurrence reused the grant without creating another approval request.
• The redaction and coverage note lists omitted sensitive fields and states the limit beside the artifacts: these are consumer/requirements evidence from a broad-resolver automation prototype, not after-change proof of the proposed RFC 0011 host-owned adapter. The prototype's separate proof ledger and host proof reference are explicitly not carried into this proposal. Codex adapter behavior must be re-proved on the accepted implementation.
• All evidence JSON parses successfully and git diff --check passes.

The required maintainer-discussion thread is still pending; this PR remains a draft until that thread is linked. Because this PR changes no production owner, after-change runtime proof belongs to the implementation PR; RFC acceptance requires a maintainer decision on that design-only proof override.

[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: needs real behavior proof before merge. Reviewed September 14, 2026, 11:59 PM ET / September 15, 2026, 03:59 UTC (Revision 3).

ClawSweeper review

What this changes

Adds a draft design for operator-selected external authorization of exact process invocations, with three redacted prototype evidence exports.

Merge readiness

⛔ Blocked before merge - 4 items remain

Keep open: this proposes a distinct extension beyond the accepted plugin-owned approval contract. The newly committed evidence makes the prototype observations inspectable and clearly limits their claims; it does not establish implementation of the proposed adapter.

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

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The proposal is coherent and its evidence limitations are honest, but prototype proof cannot satisfy the outstanding after-change proof gate.
Proof confidence	🦐 gold shrimp (3/6)	Needs stronger real behavior proof before merge: No production owner changes here. The three inspected artifacts support automation-prototype requirements, but explicitly do not exercise the proposed Codex adapter or registration contract. Because these files are under rfcs/, the literal docs/ exemption does not apply; an explicit RFC-specific override remains the appropriate resolution, with runtime proof retained for implementation. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs stronger real behavior proof before merge: No production owner changes here. The three inspected artifacts support automation-prototype requirements, but explicitly do not exercise the proposed Codex adapter or registration contract. Because these files are under rfcs/, the literal docs/ exemption does not apply; an explicit RFC-specific override remains the appropriate resolution, with runtime proof retained for implementation. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	8 items	Default branch and distinct scope: GitHub confirms main remains at the supplied revision. Its accepted RFC explicitly excludes resolving core exec approvals, so the merged foundation does not implement this proposal. Required RFC acceptance process: README requires a maintainer-discussion thread, explicit acceptance, an implementation issue, and accepted frontmatter before merging. The captured and live PR bodies both acknowledge that the discussion is pending. Complete introduced surface: The verified introduced delta contains only the RFC, its evidence README, and three JSON exports: 570 added lines across five files. No production, dependency, workflow, or executable test files change; diff whitespace validation passed.
Findings	None	None.
Security	None	None.

How this fits together

This repository records OpenClaw design decisions rather than implementing its runtime. The proposed approval boundary would take a frozen process invocation, combine existing policy checks with provider verification, and return permission to the existing process runner.

flowchart TD
  A[Process invocation] --> B[Existing policy checks]
  B --> C[Frozen execution subject]
  C --> D[Host approval lifecycle]
  E[Configured verification provider] --> D
  D --> F[Final admission checks]
  F --> G[Existing process runner]

Loading

Decision needed

Question	Recommendation
Should this RFC advance as an opt-in process-only extension of RFC 0011, with a design-only proof override and runtime evidence deferred to implementation?	Advance the bounded RFC: Discuss and accept the process-only boundary, explicitly override proof for this RFC, and retain the stated runtime acceptance requirements.

Why: Accepting a new host authorization contract and exempting this document from the literal runtime-proof gate require maintainer intent; prototype results cannot decide either.

Before merge

• Add real behavior proof - Needs stronger real behavior proof before merge: No production owner changes here. The three inspected artifacts support automation-prototype requirements, but explicitly do not exercise the proposed Codex adapter or registration contract. Because these files are under rfcs/, the literal docs/ exemption does not apply; an explicit RFC-specific override remains the appropriate resolution, with runtime proof retained for implementation. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Resolve merge risk (P1) - The exact Codex execution envelope and minimum host-owned grant metadata remain unresolved design questions; accepting the RFC would not establish enforceable adapter coverage.
• Complete next step (P2) - Link the maintainer discussion and obtain explicit design acceptance and an RFC-specific proof override before merging; then set accepted status and link the implementation issue. Update the PR body to trigger re-review, or ask a maintainer for @clawsweeper re-review if needed. Future runtime evidence may use terminal traces, logs, or recordings with private details redacted.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Change footprint	5 documentation/evidence files, +570 lines; production +0, tests +0	This is a design proposal with supporting artifacts, so merging it does not activate runtime authorization behavior.

Merge-risk options

Maintainer options:

1. Decide the mitigation before merge
   Extend the existing approval lifecycle through an explicitly accepted, opt-in process boundary, with adapter-specific execution and upgrade proof required in the implementation PR.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Technical review

Best possible solution:

Extend the existing approval lifecycle through an explicitly accepted, opt-in process boundary, with adapter-specific execution and upgrade proof required in the implementation PR.

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

Not applicable: this is a design proposal, and the accepted RFC explicitly excludes the host-owned execution scope it requests.

Is this the best way to solve the issue?

Yes as a design direction: reusing the canonical approval lifecycle avoids a competing resolver, while exact adapter feasibility remains subject to acceptance and implementation proof.

AGENTS.md: not found in the target repository.

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

Labels

Label justifications:

• P2: The proposal addresses a concrete external-authorization capability gap without changing current runtime behavior.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦐 gold shrimp and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: No production owner changes here. The three inspected artifacts support automation-prototype requirements, but explicitly do not exercise the proposed Codex adapter or registration contract. Because these files are under rfcs/, the literal docs/ exemption does not apply; an explicit RFC-specific override remains the appropriate resolution, with runtime proof retained for implementation. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

What I checked:

• Default branch and distinct scope: GitHub confirms main remains at the supplied revision. Its accepted RFC explicitly excludes resolving core exec approvals, so the merged foundation does not implement this proposal. (rfcs/0011-plugin-owned-external-verification-approvals.md:68, 967d9aac7472)
• Required RFC acceptance process: README requires a maintainer-discussion thread, explicit acceptance, an implementation issue, and accepted frontmatter before merging. The captured and live PR bodies both acknowledge that the discussion is pending. (README.md:83, 967d9aac7472)
• Complete introduced surface: The verified introduced delta contains only the RFC, its evidence README, and three JSON exports: 570 added lines across five files. No production, dependency, workflow, or executable test files change; diff whitespace validation passed. (rfcs/0038-host-owned-process-execution-authorization.md:1, f77d7ec8599c)
• Inspectable evidence and explicit limitations: All three exports were read and parse successfully. They report immutable execution, two manual occurrences, four scheduled occurrences, a no-process negative control, and durable revocation. The accompanying note explicitly identifies a different automation prototype, not the proposed host-owned adapter. (rfcs/0038/evidence/README.md:11, f77d7ec8599c)
• Dependency and implementation boundary: The proposed first adapter explicitly depends on Codex app-server command approvals, but the exact protocol envelope remains an unresolved question. The RFC expressly reserves adapter compatibility, generic-allow suppression, and final execution proof for implementation acceptance; this review does not certify those runtime contracts. (rfcs/0038-host-owned-process-execution-authorization.md:284, f77d7ec8599c)
• Accepted contract history and routing: History ties the core-exec exclusion to the accepted external-verification RFC. The commit's raw parent is faf2a3a, whose tree lacks this RFC. GitHub independently confirms docs: propose plugin-owned external verification approvals #15 merged, with Guardiola31337 as author and kevinlin-openai as merger. (rfcs/0011-plugin-owned-external-verification-approvals.md:68, d380c05ed058)

Likely related people:

• Pablo Guardiola: Raw commit d380c05 adds rfcs/0011-plugin-owned-external-verification-approvals.md:68 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: d380c05ed058; files: rfcs/0011-plugin-owned-external-verification-approvals.md)
• kevinlin-openai: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

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

• Obtain the explicit RFC-specific proof override already requested in the previous review.
• Link the required maintainer discussion and, upon acceptance, update frontmatter with accepted status and the implementation issue.

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-15T03:20:34.429Z sha ad6b531 :: needs real behavior proof before merge. :: none
• reviewed 2026-09-15T03:51:51.105Z sha 32f533b :: needs real behavior proof before merge. :: none