feat(hook): add Codex PreToolUse integration

[dergachoff]

Closes #367.

Problem

Codex installs only got tokf guidance skills, so output filtering depended on Codex remembering to run tokf run .... Claude Code already gets a real hook that rewrites matching commands before execution.

Root cause

tokf had no Codex PreToolUse hook integration. Newer Codex supports updatedInput, but older builds parse it without applying it, so unconditional transparent rewrites would fail open.

Fix

Add first-class Codex hook support:

• tokf hook handle --format codex
• tokf hook install --tool codex writes .codex/hooks.json / ~/.codex/hooks.json
• install-time codex --version selects the generated shim mode:
  • Codex 0.131.0+: transparent updatedInput rewrite
  • older or unknown Codex: deny with Run with tokf: ...
• bare --format codex defaults to the conservative deny-rerun mode
• Codex skills remain installed as fallback/discovery guidance
• docs cover the version split and rerunning install after a Codex upgrade

Codex still has no native ask flow, so ask decisions stay conservative.

Validation

bash scripts/generate-readme.sh --check
cargo fmt --all -- --check
cargo clippy -p tokf --all-targets -- -D warnings
cargo test -p tokf --test cli_hook_handle
cargo test -p tokf

[mpecan]

@dergachoff I am looking into this. Will report back soon.

[repository-butler]

Filter Verification Report

Changed Filters

No filter files changed in this PR.

All Filters Summary

✅ 143/143 test cases passed across 51 filters

---

_{Generated by tokf verify}

[dergachoff]

@mpecan I refactored the shared hook install helpers into a separate module so crates/tokf-cli/src/hook/mod.rs stays under the CI file-size/line-count gate. And also updated pr body with the local validation I ran

[mpecan]

Hey, @dergachoff, looks good overall, but I had a couple of questions:

• about the hook, why is it that we add --no-cache to the codex hook without the user requiring it explicitly? Am I missing something? Could you explain the reasoning?
• supports_skill: false → true for Codex at setup/detect.rs:12 triggers "Installing Claude Code filter-authoring skill..." in setup_cmd.rs:82 if a user picks only Codex
• CodexHookResponse::rewrite drops the engine reason (_reason: Option is unused). Likely intentional — the rerun hint is more important than the engine reason — but a one-line // drop engine reason; the rerun hint is what Codex needs would lock the choice in.

[dergachoff]

Thanks @mpecan, all fair points!

--no-cache was a leak from my local setup while I was testing codex hook heavily. Cache races were very noisy there, and the underlying issue is now fixed in #375. I removed it so codex uses the same cache behavior as the other hook integrations.

I also set codex back to supports_skill: false for setup detection. Codex still gets its own skills through tokf hook install --tool codex, but supports_skill currently controls the separate tokf skill install setup step, which is claude-specific.

Finally, I added a short comment documenting that codex rewrite responses intentionally drop the engine reason in favor of the exact rerun hint. In my personal testing this was enough to get intended result from codex. "Why spend many tokens when few do trick" :)

[dergachoff]

@mpecan Noticed that codex 0.131.0 alpha has updatedInput enabled: openai/codex#20527
So if you want we can wait for 0.131.0 release and I can update PR with proper support – on par with CC.

[mpecan]

@dergachoff I think the value proposition is higher with an actual updatedInput function and will land better + drive better outcomes.

[dergachoff]

@mpecan codex 0.131.0 finally landed so I've updated PR with updatedInput. Old versions get deny/rerun fallback. Mode is pinned on install time, decided that checking version on each hook run would be too cumbersome and weird. But users can reinstall hook when they update codex and get new behavior.