Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

A PreToolUse hook relay failure can block trusted callback commands before the intended ingress handler starts. When the relay is unavailable, the hook returns a denial such as Native hook relay unavailable, even for narrowly scoped callback commands that are already part of the product workflow.

This creates a failure mode where the user action is valid, but the workflow never reaches its owned handler. Downstream code cannot acknowledge, publish, reject, retry, or record a terminal state because the command process is stopped before execution.

The issue is not specific to one approval object. It is a generic reliability gap in the hook relay path: trusted callback ingress should have a narrow, fail-closed fallback when the relay itself is unavailable.

Steps to reproduce

1. Configure a workflow that uses a PreToolUse hook relay to approve or deny command execution.
2. Register a trusted callback command that is expected to start a workflow-owned ingress handler.
3. Trigger the callback while the native hook relay is unavailable, stale, or unreachable.
4. Observe that the PreToolUse hook denies the command before the workflow-owned ingress handler starts.
5. Retry after a service restart if applicable.
6. Observe that the failure persists if the fallback is implemented in a different bundle or code path than the one used by the active PreToolUse hook runner.

Example callback shape:

approve:<id>
reject:<id>
skip:<id>

Example denial:

Native hook relay unavailable

Expected behavior

Trusted workflow callback commands should be allowed to reach their owned ingress handler when all of the following are true:

• The command matches an exact canonical ingress shape.
• The callback action is explicitly allowlisted.
• The callback ID matches the expected format.
• The command does not use shell composition, relative paths, command injection, or arbitrary executable paths.

All non-canonical commands should continue to fail closed.

The fallback should be applied in the actual PreToolUse hook runner path, not in an adjacent or later runtime bundle that is never reached when the relay failure occurs.

Actual behavior

When the native hook relay is unavailable, the PreToolUse hook denies execution before the trusted ingress handler starts.

The workflow sees no normal callback processing because the command process is never launched. This can leave the workflow in a pending state even though the user action was valid.

A patch in the wrong runtime layer may appear to pass isolated checks but still fail in production because the denial occurs earlier in the hook runner path.

OpenClaw version

2026.5.26

Operating system

macOS 26.5

Install method

npm global

Model

openai/gpt-5.5

Provider / routing chain

openclaw->codex->openai/gpt-5.5

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Severity: High

Impact:

• Valid user actions can be blocked before workflow processing begins.
• Workflows can remain stuck in pending states despite valid approval or rejection input.
• Operators can misdiagnose the issue as a restart/cache problem if the actual hook-runner path is not verified.
• A patch can appear successful while not affecting the live denial path.
• Callback reliability depends on relay availability even for tightly scoped trusted ingress commands.

Security requirement:

The fix must not become a general command-execution bypass. The fallback should only allow exact canonical callback ingress commands with strictly validated actions and IDs, and everything else must remain fail-closed.

Additional information

Environment

• Runtime uses PreToolUse hooks to validate command execution.
• Callback workflows rely on command-based ingress handlers.
• Native hook relay can be temporarily unavailable, stale, or unreachable.
• The failing path occurs before the workflow-owned handler starts.
• The affected behavior is independent of the specific approval item or callback ID.

Logs, screenshots, and evidence

Representative denied command shape:

<runtime> <canonical-ingress-handler> "approve:<id>"

Representative hook denial:

Native hook relay unavailable

Important diagnostic evidence:

• The denial happens before the ingress handler starts.
• Restarting the surrounding service is not sufficient proof that the correct path was patched.
• The actual loaded PreToolUse hook runner must be identified and patched directly.
• A fallback in a later app/runtime bundle does not help if the hook runner denies the command first.
• The fallback must be tested against the active hook-runner path, not only against helper functions or adjacent bundles.

Recommended verification coverage:

• Valid trusted callback command is allowed when relay is unavailable.
• Invalid callback ID is denied.
• Relative paths are denied.
• Shell injection is denied.
• Wrong ingress handler is denied.
• Non-callback commands are denied.
• Patch/check helper targets only the actual hook-runner bundle.