Summary
Codex on native Windows now appears to support hooks via .codex/hooks.json and [features].hooks = true, so RTK should consider enabling the Codex auto-rewriter path on Windows instead of keeping Windows on prompt-only AGENTS.md + RTK.md guidance.
Context
There is already related RTK work/discussion:
The Windows assumption seems worth revisiting. In current Codex builds, Windows can load hook entries from C:\Users\<user>\.codex\hooks.json, and the Codex settings UI shows lifecycle hooks such as PreToolUse, PostToolUse, SessionStart, UserPromptSubmit, and Stop.
I also tested another tool's Codex hook setup on native Windows. After removing one incompatible regex look-ahead from its matcher, Codex loaded and enabled its hooks. This suggests the remaining blocker is not "Windows has no hooks", but "hook config must use Codex-supported matcher syntax and Windows-safe commands".
Request
Please consider prioritizing Windows support for the Codex RTK auto-rewriter:
rtk init --codex should write/update .codex/hooks.json or $CODEX_HOME/hooks.json on Windows when hooks are enabled.- It should enable the current Codex feature flag, likely
[features].hooks = true.
- It should avoid regex features unsupported by Codex hook matchers.
- It should use Windows-safe command invocation for
rtk hook codex.
rtk init --show should report whether the Codex hook is installed and active on Windows.- If full input rewriting is still limited by Codex upstream behavior, a deny/retry or guidance hook would still be useful as an intermediate auto-rewriter path.
Why this matters
RTK's current Codex-on-Windows path is still prompt-level guidance through AGENTS.md + RTK.md. That works, but it is much less reliable than automatic tool interception. Since Codex Windows hooks now appear usable, RTK could provide the same kind of shell-output protection on Windows Codex that users already expect from hook-based integrations.
Summary
Codex on native Windows now appears to support hooks via
.codex/hooks.jsonand[features].hooks = true, so RTK should consider enabling the Codex auto-rewriter path on Windows instead of keeping Windows on prompt-onlyAGENTS.md + RTK.mdguidance.Context
There is already related RTK work/discussion:
rtk hook codexandrtk init --codexwriting hooks/config, but it has not landed yet.The Windows assumption seems worth revisiting. In current Codex builds, Windows can load hook entries from
C:\Users\<user>\.codex\hooks.json, and the Codex settings UI shows lifecycle hooks such asPreToolUse,PostToolUse,SessionStart,UserPromptSubmit, andStop.I also tested another tool's Codex hook setup on native Windows. After removing one incompatible regex look-ahead from its matcher, Codex loaded and enabled its hooks. This suggests the remaining blocker is not "Windows has no hooks", but "hook config must use Codex-supported matcher syntax and Windows-safe commands".
Request
Please consider prioritizing Windows support for the Codex RTK auto-rewriter:
rtk init --codexshould write/update.codex/hooks.jsonor$CODEX_HOME/hooks.jsonon Windows when hooks are enabled.[features].hooks = true.rtk hook codex.rtk init --showshould report whether the Codex hook is installed and active on Windows.Why this matters
RTK's current Codex-on-Windows path is still prompt-level guidance through
AGENTS.md + RTK.md. That works, but it is much less reliable than automatic tool interception. Since Codex Windows hooks now appear usable, RTK could provide the same kind of shell-output protection on Windows Codex that users already expect from hook-based integrations.