The report
An OpenClaw issue reports that a policy plugin returned block: true from before_tool_call, and the native hook relay converted that decision into a permissionDecision: deny response. Under a tested Code Mode configuration, the reporter says shell or MCP calls still proceeded after the native hook had returned. The stated configuration includes OpenClaw 2026.7.1-2 and specific Codex builds; this is an issue report, not an independently reproduced production compromise. Inspect the issue and version context.
The difference between notification and enforcement is precise. A visible deny record proves that a hook delivered a decision; it does not prove the tool executor treated the decision as binding. The reported path uses a nested Code Mode call rather than the ordinary route the policy plugin expected. The Case dossier describes the boundary without generalizing to every Codex or OpenClaw deployment.
The test that would settle it
For each candidate tool invocation, the relevant evidence is the policy decision and the downstream side effect under the same correlation identity. A denial followed by a successful harmless file marker or synthetic MCP mutation establishes an enforcement failure in that configuration. A denial followed by a blocked call does not. The source does not supply sufficient independently checked traces to infer how often the condition occurs or whether an external attacker can trigger it.
Until those outcomes are reconciled, a user should not interpret the presence of an approval hook as a universal guard for nested tool calls. The host execution layer must make authorization effective regardless of which model-side syntax or route proposed the operation.