[Windows][VS Code][Hooks] Case-distinct trust keys correlate with chat-lifecycle-dependent hook execution

What version of the IDE extension are you using?

26.5818.61809

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Visual Studio Code

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

On one Windows machine, trusting the same project-local UserPromptSubmit hook through the Codex VS Code hook review UI and through Codex CLI /hooks created two separate [hooks.state] entries.

The entries differ only in the case of the drive letter (C: versus c:) and contain the same hook hash. Hook execution then varied depending on which trust entry existed, whether the chat already existed, and whether VS Code had been restarted.

I am reporting an observed correlation, not claiming that the case-distinct keys are the underlying cause. This has only been tested on one Windows machine.

Environment

• Codex runtime: 0.149.0-alpha.4.1
• Session metadata: originator=codex_vscode, source=vscode
• Hook source: <repo>\.codex\hooks.json
• Hook event: UserPromptSubmit

Trust entries observed

Trusting through the VS Code hook review UI produced a lowercase-drive key:

[hooks.state.'c:\Users\<user>\Desktop\<repo>\.codex\hooks.json:user_prompt_submit:0:0']
trusted_hash = "sha256:07e09519b403f2959f681ccb38283ad92c62d72ad752eff2f09a9000073ad75a"

Trusting the same hook through CLI /hooks produced an uppercase-drive key:

[hooks.state.'C:\Users\<user>\Desktop\<repo>\.codex\hooks.json:user_prompt_submit:0:0']
trusted_hash = "sha256:07e09519b403f2959f681ccb38283ad92c62d72ad752eff2f09a9000073ad75a"

The entries were created through the two review interfaces rather than manually duplicated.

What steps can reproduce the bug?

For each trust state, I tested hook execution in:

1. A chat that already existed before the trust-state change.
2. A newly created chat.
3. Both cases without restarting VS Code.
4. Both cases after restarting VS Code.

The hook emits recognizable additional developer context. Results were verified by inspecting the session JSONL for the actual injected developer message rather than relying on the assistant's response.

Definitions:

• Old chat: a chat already open before changing the trust state.
• New chat: a chat created after changing the trust state.
• Restart: close and reopen VS Code before sending the test prompt.

State	Stored trust entries	No restart, old chat	No restart, new chat	After restart, old chat	After restart, new chat
S0	None	No	No	No	No
S1	Lowercase c: only	No	Yes	No	Yes
S2	Uppercase C: only	No	No	Yes	No
S3	Both C: and c:	Yes	Yes	Yes	Yes

What is the expected behavior?

No response

Additional information

Additional no-restart observation

I also tested changing the trust entries without restarting VS Code:

1. Starting with both trust entries present, I deleted both entries without restarting.
2. The old chat still received the hook injection for one additional turn.
3. On the following turn, injection stopped.
4. A new chat did not receive the hook injection.
5. I then trusted the same hook through both review paths again, still without restarting VS Code.
6. Once both entries existed, both the old and new chats immediately received the hook injection.

This suggests that some trust or hook state may be retained or refreshed at different points in the chat lifecycle, but I did not investigate the underlying implementation.

Temporary workaround observed on this machine

The following workaround has been reliable on the affected machine:

1. Review and trust the project hook from the Codex hook review UI in VS Code.
2. Open Codex CLI in the same project and use /hooks to review and trust the same hook.
3. Confirm that both uppercase-drive and lowercase-drive [hooks.state] entries exist for the same hook hash.

With both entries present, the hook executed in every tested combination of existing/new chat and restart/no restart.

This is only a temporary workaround observed on one machine. It has not been validated across other Windows installations. If the hook definition changes and its hash changes, both trust paths may need to be reviewed again.

The Hooks documentation states that non-managed command hooks must be reviewed and that trust is recorded against the hook's current hash:

https://developers.openai.com/codex/hooks#review-and-trust-hooks

Related issues

• https://github.com/openai/codex/issues/33413
• https://github.com/openai/codex/issues/19281
• https://github.com/openai/codex/issues/38591
• https://github.com/openai/codex/issues/40247
• https://github.com/openai/codex/issues/32491
• https://github.com/openai/codex/issues/21901
• https://github.com/openai/codex/issues/37362

Start with the VS Code hook review UI and CLI /hooks flow, then compare how each records the [hooks.state] key for .codex/hooks.json on Windows. Use the S0-S3 table across old and new chats and restart states as regression coverage; done means one logical trust state behaves consistently without requiring duplicate case-variant entries.