openclaw - 💡(How to fix) Fix [Feature]: Expose machine-wide hook policies [1 participants]

Summary

Add an admin-managed, system-wide hook discovery tier whose entries always load, run before user-controlled hooks, and cannot be disabled by openclaw hooks disable.

Problem to solve

Enterprises self-deploying OpenClaw across their fleet need an admin governance surface, and today there isn't one. All four hook discovery tiers (bundled, plugin, managed ~/.openclaw/hooks/, workspace <workspace>/hooks/) are user-scoped or user-toggleable: any developer with a shell can run openclaw hooks disable <name>, set hooks.internal.enabled=false, edit ~/.openclaw/, or uninstall a hook pack and silently void whatever the security/platform team intended to enforce.

For an admin pushing OpenClaw to thousands of endpoints via MDM, Group Policy, or a config-management tool (Intune, Jamf, Ansible, Puppet), this means there is no way to:

⦁ Mandate a hook that must run on every session — e.g. a DLP/secret scanner on message:sent, an audit logger on command:*, a compliance gate on agent:bootstrap — with the guarantee that it loads first and cannot be bypassed by the end user. ⦁ Pin that hook to an admin-owned source of truth (a root-owned file or HKLM registry key) that survives ~/.openclaw/ resets, fresh user profiles, OS reimages, and "I'll just disable it for one debug session." ⦁ Prove to auditors that the control is in place: there's no machine-wide tier to point at, no precedence rule that places admin policy ahead of user config, and no inventory query that distinguishes "admin-mandated" from "user-installed" hooks.

The practical effect is that OpenClaw fails enterprise procurement/security review in any environment with mandatory egress scanning, data-handling regulations (HIPAA, PCI, SOC 2, GDPR Art. 32), or tamper-evident audit requirements. Teams either decline to adopt, deploy with documented policy gaps, fork the runtime, or wrap it in heavyweight external sandboxing — all of which push enterprise users away from the supported product.

This isn't a feature individual users can opt into themselves; it's specifically the gap between what an admin can deploy and what a user can undo. Closing it requires a tier the runtime treats as more authoritative than user-controlled discovery, with hardening (root-owned files, no symlinks, registry under HKLM\SOFTWARE\Policies...) so end users without administrator rights physically cannot edit it.

Proposed solution

Add a fifth discovery tier, policy hooks, with an admin-owned root and stronger semantics than any existing tier: •Source roots (read-only to non-root users, ignored if owned/writable by anyone other than root): - POSIX: /etc/openclaw/policy.d/*.json (alphabetical, conf.d-style ordering) - Windows: HKLM\SOFTWARE\Policies\OpenClaw\Hooks Policy value (REG_SZ JSON), plus enumerated subkeys •Discovery hardening: symlinks rejected; non-root-owned or group/world-writable files rejected; per-document size cap (e.g. 64 KiB) with an error logged when exceeded so admins can diagnose; oversized or malformed documents are skipped without disabling sibling documents. •Precedence: policy hooks run first for every event. A policy hook returning a block/deny decision short-circuits — bundled, plugin, managed, and workspace hooks for that event are not invoked. •Immunity: openclaw hooks disable, hooks.internal.enabled=false, and any user/workspace config flag is silently a no-op against policy-tagged hooks. openclaw hooks list shows them with a policy badge and a non-removable indicator. •CLI surface: openclaw hooks list --policy lists only policy hooks; openclaw hooks info <name> reports source: policy and the originating registry key / file path. •Failure mode: fail-open with an error-level log if a policy hook command is missing or crashes, so a misconfigured policy can't brick a fleet — but block decisions returned by a successfully running policy hook are honored unconditionally. •Schema: identical JSON shape to the existing config-file hook contract, so admins can reuse known event names (message:received, command:new, agent:bootstrap, etc.) and command/HTTP hook types.

Alternatives considered

No response

Impact

• Affected: regulated enterprise deployments (finance, healthcare, public-sector), security teams running OpenClaw across shared dev hosts and CI runners, anyone needing centralized DLP / audit / compliance enforcement.
• Severity: blocks workflow — without this, OpenClaw cannot be approved for use in environments with mandatory egress scanning or audit retention.
• Frequency: per-event (every inbound/outbound message, every command, every bootstrap). Affects 100% of sessions on affected fleets.
• Consequence: fleets either avoid adoption, ship with policy gaps that show up in audits, or invest in custom forks. Each declined deployment also blocks downstream tooling (plugins, hook packs) from reaching those users.

Evidence/examples

Alignment with top AI agents as Claude Code or OAI Codex - https://developers.openai.com/codex/hooks https://code.claude.com/docs/en/hooks

Additional information

No response