fix(policy): reject unsupported policy keys#87074
Conversation
|
Codex review: needs maintainer review before merge. Reviewed June 2, 2026, 5:59 PM ET / 21:59 UTC. Summary PR surface: Source +359, Tests +175, Docs +2. Total +536 across 3 files. Reproducibility: yes. from source: current main lacks the unsupported-key allowlists while the PR adds them and tests concrete rejected policy shapes. I did not run tests in this read-only review. Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land only with maintainer acceptance of the fail-closed policy strictness, keeping the validation local to the Policy plugin doctor/check path with the current focused docs and tests. Do we have a high-confidence way to reproduce the issue? Yes, from source: current main lacks the unsupported-key allowlists while the PR adds them and tests concrete rejected policy shapes. I did not run tests in this read-only review. Is this the best way to solve the issue? Yes, this is the right implementation boundary if maintainers accept the strictness: the change stays in Policy plugin validation and reuses the existing policy invalid/conformance invalid paths instead of adding runtime enforcement. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against a86a1de8499f. Label changesLabel justifications:
Evidence reviewedPR surface: Source +359, Tests +175, Docs +2. Total +536 across 3 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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 PR egg ✨ Hatched: 💎 rare Gilded Patch Peep Hatch commandComment Hatchability rules:
Rarity: 💎 rare. What is this egg doing here?
|
|
Maintainer review: no blocking findings. I reviewed the final stack commit Best-fix verdict: this is the right owner boundary for the current fix. Keeping validation in Compatibility note: this intentionally changes previously ignored policy keys into hard policy-file errors. That is the desired behavior here, but it should remain a maintainer-accepted config strictness change before merge. Proof read: Verification run against PR commit OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-pr-87074-vitest-cache OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/policy/src/doctor/register.test.ts -- --reporter=dot --testTimeout=30000Result: 253 tests passed. OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-pr-87074-vitest-cache-cli OPENCLAW_VITEST_MAX_WORKERS=1 node scripts/run-vitest.mjs extensions/policy/src/cli.test.ts -- --reporter=dot --testTimeout=30000Result: 28 tests passed. Live PR checks currently show |
c6b6696 to
b6edcc0
Compare
|
Updated this branch on top of the rebased data-handling branch ( @galiniliev I kept the unsupported-key behavior as the intentional config strictness change you called out in the compatibility note. No additional code change was needed beyond rebasing the stack. Fresh validation after the rebase:
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
b6edcc0 to
a54b155
Compare
|
Rebased #87074 over the cleaned data-handling branch after removing the release-owned changelog edit from the lower policy stack. Current signed head: Validation from the top-of-stack checkout after rebasing #87074 and #87081:
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
@clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. Re-review progress:
|
|
Refreshed #87074 after the lower policy stack landed and after #87056 was rebuilt. Current signed head: Branch cleanup:
Fresh validation on this rebuilt head:
No new public config or plugin surface was added by the refresh. The top commit tightens Policy validation by rejecting unsupported policy keys. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Rebuilt this stack entry on the refreshed data-handling policy head and force-pushed. Focused proof from the stack: policy doctor tests pass (256/256), oxfmt check passes for touched policy/docs files, and git diff --check passes. @clawsweeper re-review |
|
🦞👀 Command router queued. I will update this comment with the next step. |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Rebuilt this PR after #87056 merged. Current head: Scope after rebuild is back to the unsupported-policy-key change only:
Proof from
Codex-review note: I attempted the review closeout, but the local Codex reviewer is currently blocked by account/model mismatch: Maintainer boundary note: this still touches policy/config compatibility behavior, so please keep the compatibility/security-boundary review expectation on it. The rebuild did not add plugin surface or unrelated config surface changes. @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Refined the shape validator after reviewer concern about repeated section names. Current head: Change since prior proof:
Fresh proof from
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Addressed the ClawSweeper finding from https://github.com/openclaw/clawsweeper/actions/runs/26842794799. Current head: Change:
Behavior proof:
Validation:
Note: full @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Compatibility/security-boundary strictness decision: Maintainer decision: we accept this strictness for this PR. The keys now rejected are not documented policy spec fields and are not represented in the policy rule metadata/evaluation model, so this is fail-closed validation for unsupported policy shape rather than removal of a supported surface. Expected upgrade impact: an existing operator Merge note: the current allowlists are intended to cover the supported policy rules; unknown keys should fail closed for this policy/security-boundary surface. |
|
Merged via squash.
Thanks @giodl73-repo! |
Summary
Tightens policy validation so unsupported policy sections and rule keys are reported as
policy/policy-jsonc-invalidinstead of being silently ignored. This keepspolicy.jsoncstrict: if an operator writes a policy claim that OpenClaw does not understand or cannot evaluate, Policy reports that as invalid policy syntax rather than giving false confidence.Contract
Policy files remain config-conformance documents. This PR does not add runtime enforcement or new policy surfaces; it makes the existing surfaces stricter about unknown keys.
Examples that now produce
policy/policy-jsonc-invalidfindings include:{ "unknownSection": {}, "network": { "privateNetwork": { "allow": false, "unknownRule": true } }, "scopes": { "ops": { "agentIds": ["analyst"], "ingress": { "channels": { "denyOpenGroups": true } } } } }The scoped example is invalid because
ingress.channels.*requires achannelIdsselector, notagentIds. Every scoped policy section must be valid and enforceable for the selector it declares.Behavior
Unsupported keys are rejected across the policy namespaces already covered by the policy stack, including top-level sections, nested section keys, and scoped overlays. Known strictness metadata still controls allowed stricter overlays and
policy compare; this PR makes unknown fields fail fast before evaluation.Usage
Validation
policy/policy-jsonc-invalidinstead of being ignored.