openai / openai/codex

VS Code extension silently skips untrusted hooks without the documented review warning

Open
#42,959 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug extension hooks
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the IDE extension are you using?

openai.chatgpt-26.901.22334-win32-x64 (bundled Codex CLI/app server 0.153.0)

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.26200.0 x64

What issue are you seeing?

When an enabled hook needs review, the VS Code extension skips it silently. No startup warning, no notification, no status indicator, and nothing retained in the chat after streaming ends.

This is specifically a surfacing defect, not an execution defect. Trusted hooks run correctly in this version: a live hooks/list query returned all seven of my installed and enabled definitions as trusted, and they executed in 105 ms. The problem is only what happens when one of them is not trusted.

The documented behavior at https://learn.chatgpt.com/docs/hooks is that new or changed hooks are skipped until trusted, that startup should warn when review is required, and that systemMessage is surfaced as a UI warning or event-stream message. In the VS Code extension, no such warning appears.

The extension already holds the information needed to warn. The installed bundle calls hooks/list, compares current against trusted hashes, persists hook state, and renders a per-hook Trust UI in its Hooks settings route. I could not find any route from that known state to a startup or chat warning.

The practical consequence is silent, indefinite data loss for anyone using hooks as a recorder or audit mechanism. A hook definition stops running the moment it is edited, and nothing in the IDE says so. I only discovered it because a downstream artifact was missing; the session itself looked completely normal.

What steps can reproduce the bug?
  1. In an isolated project, add one harmless UserPromptSubmit command hook to .codex/hooks.json and leave it untrusted.
  2. Confirm the untrusted state machine-readably: hooks/list reports that handler as untrusted. (In my case all seven production handlers in the same environment remained trusted, so exactly one handler was pending review.)
  3. Open a fresh, separate VS Code window on that project.
  4. Send one prompt: Reply only READY.

Observed:

  • The chat returns an ordinary response and READY.
  • No startup hook-review warning appears at any point.
  • There is no retained streaming-detail dropdown or any other problem indicator once the turn completes.
  • The untrusted handler does not run, confirmed independently by the session record.
  • The VS Code extension log contains session events but no hook-review warning.

Then, for contrast, open the interactive CLI on the same project and run /hooks:

The CLI reports 1 hook needs review before it can run and names UserPromptSubmit.
So the pending review is known to the same app server that the extension is talking to, and is reported clearly on the CLI surface and not at all on the extension surface.

What is the expected behavior?

When an enabled hook needs review, the VS Code extension should show a durable warning with a direct route to its Hooks trust UI. Durable is the important part: it should remain visible after streaming ends, rather than existing only in transient turn output. A persistent notification, a status-bar badge, or a retained entry in the chat would all satisfy this.

At minimum the extension should not present a session as normal when it knows a configured hook was skipped.

Additional information

I could not find any user setting that suppresses this warning, so I do not believe this is local misconfiguration:

  • The configuration reference (https://learn.chatgpt.com/docs/config-file/config-reference) contains no hook-review-warning suppression setting. The nearby options affect reasoning display or experimental-feature warnings.
  • allow_managed_hooks_only would skip every non-managed hook, which does not match this reproduction — only the single untrusted handler was skipped, and the seven trusted ones ran.
  • The installed extension manifest declares no setting for hook trust-warning visibility.

Related issues:

  • #37362 and #35306 report the same class of defect on Codex Desktop (silently skipped hooks pending trust, no in-app review path). This report is the VS Code extension surface, which is still affected in 26.901.22334.
  • #33413 is a different defect on this surface: hooks not executing at all in extension threads despite being trusted. That is not what I am seeing — trusted hooks execute correctly here.

Worth noting that trust is per hook definition, and any edit to a definition invalidates its approval. That makes the missing warning easy to hit during ordinary iteration on a hook: the hook works, you tweak one line, and it silently stops running with no indication anywhere in the IDE.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior with an untrusted UserPromptSubmit hook, then trace the VS Code extension's handling of hooks/list state and the Hooks settings route. Compare the extension surface with the CLI's review warning; done means an untrusted enabled hook produces a durable warning with a route to trust it.

Written by the indexing model from the issue text.

Assessment

Tech stack
vscode
Domain
developer-experience, devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.