codex install registers `graphify hook-check`, which is not a command in 0.9.25 (silent no-op)

[Second-Summit-marketing]

Affected version

• graphifyy 0.9.25 (uv tool install)
• Windows 11, Codex CLI

Summary

graphify codex install registers a PreToolUse hook that invokes graphify hook-check. That subcommand does not exist in 0.9.25. The result is a silent no-op that costs a process spawn on every matching tool call, and gives the user a hook they believe is enforcing graph usage when it is doing nothing.

What gets written

~/.codex/hooks.json:

{
  "matcher": "Bash",
  "hooks": [
    { "type": "command", "command": "c:/users/<user>/.local/bin/graphify.EXE hook-check" }
  ]
}

Evidence it is not a real command

graphify --help lists the hook-related commands as:

hook install            install post-commit/post-checkout git hooks (all platforms)
hook uninstall          remove git hooks
hook status             check if git hooks are installed
check-update <path>     check needs_update flag and notify if semantic re-extraction is pending (cron-safe)

hook-check appears nowhere in --help. Invoking it directly, both outside and inside a repo with a valid graphify-out/graph.json:

$ graphify hook-check
$ echo $?
0

No output, exit 0 — indistinguishable from success, so nothing surfaces the misconfiguration.

Expected

Either:

1. the installer registers whatever the current equivalent is (check-update?), or
2. the hook entry is dropped if there is no longer a per-tool-call check, or
3. hook-check is restored as an alias.

In all cases an unrecognized subcommand should exit non-zero rather than 0, so a stale hook fails loudly instead of silently.

Impact

Low severity, but the failure mode is bad: the user is told "Codex will now check the knowledge graph before answering codebase questions" while the mechanism that would enforce it is inert. I only found it by grepping --help after the hook never appeared to do anything.

[Second-Summit-marketing]

Additional evidence: the Claude Code installer in the same version registers hook-guard, not hook-check, which looks like the command hook-check was renamed to and the Codex path was never updated.

Behavioural difference, run from a repo with a valid graphify-out/graph.json on 0.9.25:

graphify hook-guard read --strict  -> blocks waiting on stdin (killed at 25s)
graphify hook-guard search         -> blocks waiting on stdin (killed at 25s)
graphify hook-check                -> returns immediately, exit 0, 0 bytes stdout, 0 bytes stderr

hook-guard blocks because it is reading the hook payload from stdin, i.e. it is a real hook entry point doing real work. hook-check returns instantly and writes nothing, consistent with an unrecognized subcommand falling through to a no-op.

So graphify codex install produces a hook that can never fire, while graphify claude install produces a working one. Pointing the Codex installer at hook-guard would likely fix this.

Separately, note that the Codex hook entry is written without a timeout field. Since hook-guard blocks on stdin, an entry with no timeout is worth a second look for any client that might invoke it without providing stdin.

[safishamsi]

Resolved in v0.9.27 (#2185, thanks @Souptik96). hook-check is a real, intentional no-op command (Codex Desktop rejects additionalContext on PreToolUse, so graph guidance comes from AGENTS.md); this is now documented. https://github.com/Graphify-Labs/graphify/releases/tag/v0.9.27