bug: Codex hooks (PreToolUse/PostToolUse) are largely ineffective — 91% skipped, PostToolUse HTTP never reaches daemon

[Maple0517]

Context

After #206 landed (implemented via #207, #209, #211, #212, #213, #215, #218, #230), I've been running Codex with the hooks enabled for a day. The hooks are well-implemented and fire correctly, but I'm seeing some gaps in how they interact with Codex's actual usage patterns. Wanted to share the observations in case they're useful.

What I observed

~/.gortex/cache/hook-decisions.jsonl (64 entries, all from Bash):

Decision	Count	%
skipped_non_symbol	58	91%
probed_miss	3	5%
probed_hit	2	3%
timed_out	1	2%

Meanwhile, query-log.jsonl shows 64 successful MCP tool calls (search_symbols: 15, smart_context: 15, search_text: 34) across 8 sessions. The agent is using graph tools effectively — it's just being guided by AGENTS.md rather than the hooks.

PreToolUse: Bash command classifier doesn't match Codex's search patterns

Codex wraps everything in Bash. The hook parses tool_input.command to detect grep/find/cat, then checks if the pattern looks like a symbol name via classifyGrepPattern. But Codex tends to use multi-keyword |-separated patterns:

grep -rn "ai-redesign|Phase 5|entity_links|world-map" .
grep -rn "place_edges|location_edge|normalize" .

These contain |, multi-word phrases, and non-identifier tokens, so classifyGrepPattern returns NonSymbol and the hook passes through silently. This is by design for Claude Code's dedicated Grep tool (where patterns are typically single identifiers), but Codex's usage pattern is quite different.

I'm not sure what the right fix is here — maybe splitting |-separated patterns and probing each segment? Or falling back to search_text for non-symbol patterns? The current classifyBashCommand → classifyGrepPattern pipeline is solid for its original use case; it just doesn't align well with how Codex uses Bash.

PostToolUse: daemon HTTP endpoint not available by default

posttooluse.go calls queryGortex(port, path) which hits http://localhost:{port}/api/graph/symbol-at etc. But the daemon only listens on a unix socket by default — the HTTP endpoint requires --http-addr. On my setup, port 8765 happens to be occupied by another process, so all PostToolUse graph lookups silently fail.

Looking at the daemon logs, I can see zero HTTP API requests from hooks, which confirms the calls never reach the daemon.

I wonder if it would make sense to have PostToolUse fall back to the unix socket (same as probeViaDaemon in probe.go) when HTTP isn't available, or perhaps add a reachability check before attempting the HTTP calls?

Side note: binary freshness

I noticed the Homebrew-installed v0.58.3 binary was built ~2 hours before #218 merged, so the MCP read PreToolUse matcher (^mcp__gortex__(read_file|get_editing_context)$) isn't in my running binary. Not a code issue — just a packaging timing thing. Thought worth mentioning for context.

Happy to help investigate or test any fixes. The hook infrastructure is solid — the gaps seem to be in Codex-specific pattern matching and daemon connectivity.

[Maple0517]

Closing temporarily while we discuss the findings internally. Will reopen with a concrete fix plan.

[zzet]

@Maple0517 I'm happy to join the conversation (feel free to invite me if it possible). The issues seem to overlap with an adoption benchmark I ran recently (and it's not related only to the hooks definition, but also to the tools description, intending to convince the coding agent to use the tool without a rely to *.md driven instructions).
The repository with the code used for the mentioned benchmark will be published soon (not fully ready)

[Maple0517]

@zzet
Thanks for jumping in! Unfortunately my other forks are overseas and needs VPN to access GitHub, but I'd love to discuss the details here or elsewhere if easier.

A few questions and observations:

1. Benchmark preliminary results?

Curious what you've seen so far — particularly whether there's a measurable difference in tool adoption rates between "AGENTS.md tells the agent to use X" vs "the tool description itself convinces the agent". My gut feeling from the query-log data is that AGENTS.md works well for deliberate sessions but gets forgotten in long-running ones.

2. Tools description alone, or skills packaging?

When you mention improving tool descriptions to drive adoption without *.md reliance — is the idea to just improve the MCP tool's description field, or would packaging as a skill make a difference? I recall that some agents (at least Claude Code and Codex) seem to prioritize injected context skills over MCP tool descriptions at discovery time. If that's the case, a skill entry might have more "convincing power" than a tool description alone. Curious if your benchmark touched on this.

3. Context length / deferred tool forgetting

One pattern I've been seeing with Codex (and I suspect it applies to other harnesses too): when the conversation context gets long, the agent tends to forget about MCP tools — especially deferred ones (tool_search discovery). This makes sense from a attention/position-bias perspective: the MCP tool descriptions live far from the current turn, while Bash is always right there in the tool list.

My current workaround is... not elegant: I inject gortex constraint text explicitly into another harness via a UserPromptSubmit py script, so the reminder lands at the top of each turn. It works but it's definitely not a long-term solution. Would love to hear if you've seen similar patterns or have thoughts on a more principled approach.

[Maple0517]

@zzet
One more thing worth mentioning — another Codex limitation that contributes to this:

Codex GUI doesn't (fully) support workspace/profile switching like other agents does. It's more of a half-baked implementation right now. So as users work across different projects, a growing number of MCP servers and skills accumulate and get injected into every new session.

In this scenario, I've observed that Gortex's tools get buried in the context — forgotten even at the very start of a session, despite having explicit "use Gortex" instructions in both the Codex-level and repo-level AGENTS.md. The agent simply ignores the instructions because the Gortex tools are lost in a sea of other MCP tools and skill entries.

This is actually the original motivation behind #206 — the hooks were an attempt to bring Gortex back to the agent's attention at the point of tool use, not just at session start via AGENTS.md.