Intermittent Native hook relay unavailable blocks all tool calls
What happened
During a Codex/OpenClaw session on macOS, tool calls intermittently failed before execution with:
Command blocked by PreToolUse hook: Native hook relay unavailable.
This was not limited to one command. During the bad window, the hook blocked unrelated operations including:
python3 scripts/lobster_send.py ...curl ...rg ...apply_patch
A few minutes later, the same workspace and same session recovered without a restart: pwd, rg, apply_patch, gh, and other commands worked again. That intermittent behavior makes it feel like a relay / hook availability bug rather than a command-specific policy denial.
Expected behavior
If the hook relay is temporarily unavailable, Codex should either recover/retry gracefully or surface a clearer actionable error. It should not block every unrelated tool call with the same pre-execution failure and then recover silently later.
Actual behavior
All attempted tool calls were rejected by the PreToolUse hook with Native hook relay unavailable, including simple file search/read and patch operations.
Environment
- OS: macOS Darwin 25.5.0 arm64
- Global npm package:
@openai/codex@0.114.0 - Time observed: 2026-06-28 around 20:24-20:52 AEST
- Integration context: Codex running inside OpenClaw with native hook/tool relay enabled
Additional note
After recovery, running codex --version from the shell failed with a separate-looking ENOENT for the packaged vendor binary:
spawn /opt/homebrew/lib/node_modules/@openai/codex/node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex ENOENT
I am not sure whether that is related to the hook relay failure, but I am including it as an environment clue.
Impact
When this happens, the agent cannot send messages through local scripts, cannot use curl, cannot inspect files with ripgrep, and cannot persist memory with apply_patch. The session can still sometimes reply through the platform message tool, so the failure appears scoped to native tool/hook execution rather than the whole conversation runtime.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗