Skip to content

fix(install): say when Codex will not load the hooks it just registered - #22

Merged
yuema137 merged 1 commit into
mainfrom
fix/codex-trust-diagnostic
Sep 10, 2026
Merged

yuema137 merged 1 commit into
mainfrom
fix/codex-trust-diagnostic

Conversation

@yuema137

Copy link
Copy Markdown
Owner

The demonstrated problem

--check-hooks on a Codex project that had never been trusted:

Installed presets: standards. Skill version 0.1.0. Registration and runtime
files match (codex 0.153.4). Commands are portable across machines. …

At that same moment, hooks/list through the Codex app-server returned zero hooks.

Everything the message says is true — the registration is byte-perfect and the runtime files match — and none of it is what the user needs to know. The message did carry a general caveat about verifying trust through /hooks, but a reader who has just been told their registration matches has no reason to go looking, and the failure is silent on the host side too.

What changed

doctor looks for a [projects."<path>"] entry in the config under CODEX_HOME. When it is absent it says so and names the file to add it to. Claude Code has no equivalent level and is never told this.

… Codex has not been told to trust /path/to/project: add a
[projects."/path/to/project"] entry with trust_level to ~/.codex/config.toml,
or trust it through the host. Until then it loads no project-local hooks at all.

It reports; it changes nothing

No trust is granted, no configuration is written, nothing is blocked. That is the only shape appropriate here: the user stays free to trust the project however they prefer, through the host or the file, or not at all. Anything this repository does should remain something the user can work around.

Validation

Ran 168 tests ... OK (skipped=1); --check PASS on all five checks.

Mutation check: removing the notice fails the test that asserts it appears while untrusted and disappears once trusted, and that Claude Code never receives it.

Related, verified separately

PostToolUse delivery — listed as unverified in the 0.1.0 notes — is now observed on Claude Code with a real agent-run commit:

{"event": "PostToolUse", "tool": "Bash",
 "command": "git commit --allow-empty -m probe",
 "argv": ["event", "--host", "claude-code", "--project", "", "--event", "post-commit"]}

The release notes will be corrected.

🤖 Generated with Claude Code

https://claude.ai/code/session_016cCs5DdUjLDkP8V3Z5x6XH

--check-hooks reported "Registration and runtime files match" on a Codex project
that had never been trusted, while Codex was loading zero hooks. Demonstrated:
the registration is byte-perfect, the runtime files match, and hooks/list returns
nothing at all.

The message did carry a general caveat about verifying trust through /hooks, but
a reader who has just been told their registration matches has no reason to go
looking, and the failure is silent on the host side too.

doctor now looks for a [projects."<path>"] entry in the config under CODEX_HOME
and, when it is absent, says so and names the file to add it to. Claude Code has
no equivalent level and is never told this.

It reports and changes nothing. It grants no trust, writes no configuration, and
blocks nothing, which is the only shape appropriate here: the user must stay able
to trust the project however they prefer, or not at all.

Mutation check: removing the notice fails the test that asserts it appears while
untrusted and disappears once trusted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016cCs5DdUjLDkP8V3Z5x6XH
@yuema137
yuema137 merged commit 83ff7ce into main Sep 10, 2026
4 checks passed
@yuema137
yuema137 deleted the fix/codex-trust-diagnostic branch September 10, 2026 17:55
@yuema137 yuema137 mentioned this pull request Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant