Developers who run Codex CLI with plugins can read here how Codex decides a plugin’s hook may run, and what Postman’s plugin installer does to that decision. The post then follows one user’s report of an automatic install and lists the entries to look for in ~/.codex/config.toml. Nothing was installed or run for this post: the Codex docs and release notes, the Postman plugin source at commit 6c8e452 and the GitHub issue were read on 2026-11-04, and GitHub times below are UTC.
Codex skips a plugin hook until its current hash is trusted
Hooks matter here because a hook can add text to the start of every session. The Codex hooks page describes them as scripts or MCP tools that Codex runs during the agent loop, for example at session start. It says non-managed hooks “must be reviewed and trusted before they run.” Codex records that trust against the hook’s current hash, so a new or changed hook is skipped until it is trusted. Plugin-bundled hooks use the same review flow.
The review happens in /hooks, the CLI’s hook browser, where a user can trust or disable each non-managed hook. Codex prints a startup warning pointing there when a hook needs review, and the desktop app has a “Settings > Hooks” screen. Managed hooks from system, MDM, cloud or requirements.toml sources are trusted by policy. The --dangerously-bypass-hook-trust flag runs enabled hooks without persisted trust for one invocation.
A plugin update that changes a bundled script needs a new review, even if the hook definition stays the same. Codex 0.164.0, a stable release published 2026-10-23, lists entry #54619, “Bind plugin hook approval to plugin contents”.
The Codex hooks page does not say where trust is stored
Where trust lives decides which file a reader should inspect, and the hooks page leaves that out. It names no file or key where trust is stored, and does not mention hooks.state, trusted_hash or trusted_content_hash. It also does not say what each hash covers. Of the sources read for this post, the key shape appears in two: a user’s config quoted in a GitHub issue, and Postman’s installer source.
Postman’s installer writes the trust record through Codex app-server
This is the step that turns installing the plugin into an approved hook. The Postman plugin is Postman’s package of skills, hooks and an MCP connection for coding agents. Its README says that for Codex, installation also approves the session-start hook, and “There is no separate hook prompt or dump of its instructions.”
The approval code is in codex-hooks.ts. It starts codex app-server, the local interface that Codex’s own clients use, per the app-server docs. It calls hooks/list, reads each hook’s trustStatus and currentHash, then sends one config/batchWrite edit for the fixed key postman@postman:hooks/codex-hooks.json:session_start:0:0:
edits: [{ keyPath: 'hooks.state', value: { [POSTMAN_HOOK_KEY]: { trusted_hash: hash } }, mergeStrategy: 'upsert' }],Before writing, the function skips a hook that is missing or already trusted, and stops unless the status is untrusted or modified. It requires a non-empty session-start-context.md next to the hook and lists again to check nothing changed. A dry run is the one exit before app-server is contacted, and there is no opt-in flag. Any error is caught, and the install still succeeds.
In codex.ts, the install step adds or refreshes the postman marketplace and runs codex plugin add postman@postman. It then calls approvePostmanHook with no condition. The app-server docs list both methods, and say config/batchWrite applies edits “atomically to the user’s config.toml on disk.” Their example edits apps.* keys, and they do not describe a hooks.state edit.
The hook tells the agent to load Postman’s API skill
What the hook prints matters because it reaches new, cleared and compacted sessions. The reporter of issue #14370 says hooks/codex-hooks.json registers a SessionStart command with the matcher startup|clear|compact that prints hooks/session-start-context.md. That context file, wrapped in an <EXTREMELY_IMPORTANT> tag, tells the agent to load the postman:api-engineer skill before any non-trivial API engineering task. It also says user instructions, including AGENTS.md or CLAUDE.md files, take precedence. This post quotes the file as data; nothing in it was followed.
One user found a trust record after Postman desktop auto-installed the plugin
The installer code shows how a record could be written; the issue shows what one machine ended up with. Issue #14370, filed on 2026-10-25 by user indicava, is titled “[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook”. The reporter lists Postman desktop 12.33.4, Codex Postman plugin 1.1.0 and installed source revision 6c8e452. They quote a Postman log line timestamped 2026-10-24T09:34:14.418Z:
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}The reporter’s ~/.codex/config.toml held a postman git marketplace and these entries, among others:
[plugins."postman@postman"]
enabled = true
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]That record holds both a trusted_hash and a trusted_content_hash, while the installer source writes only trusted_hash. The reporter states: “The trust record alone does not prove who created that specific record.” They describe Codex “repeatedly routing API work through Postman skills” and say the report “does not claim to establish data exfiltration”. They also report that ~/.claude/settings.json enabled postman@claude-plugins-official.
A second user, ronthedrummer, reported the same auto-install in the issue on 2026-11-03, on Postman 12.35.1 with cached plugin 1.3.0. Their config.toml had no hooks.state or trusted_hash entry. They run Codex 0.153.4 and say they are “not saying the Codex SessionStart hook printed.”
No fix appears in the issue or the Codex release notes
A reader deciding whether to act needs to know if either side has changed anything. All 51 comments on the issue at fetch time come from accounts GitHub marks NONE, not member, owner or collaborator. On 2026-11-03, zecoquit, a commenter writing as Postman, said “we’re reviewing the hook approval and session-start behavior you flagged”. That account’s role is not verified. The latest stable Codex, 0.166.0, was published 2026-10-29, and the notes for 0.165.0 and 0.166.0 list no change to hook trust.
What to look for in a local Codex config
These checks need no Postman installer. In ~/.codex/config.toml, look for the hooks.state table under the Postman key, the [plugins."postman@postman"] table and a postman marketplace entry, as quoted in the issue. Open /hooks in the CLI to review or disable the hook, or “Settings > Hooks” in the desktop app to review it, per the hooks page. That page does not say whether deleting a hooks.state entry by hand is supported.
Limits
Nothing was installed or run, so this post does not show whether the hook ran anywhere without a /hooks review. The sources do not show who wrote the record on the reporter’s Mac, and no source read verifies which hash covers what. Which Postman desktop builds run auto-existing-upgrade is not in any source read, and a later plugin or Codex release may change this behaviour. In the issue, foma-agent, a commenter that describes itself as an AI agent, reports that on Codex CLI 0.162.1 it wrote trusted_hash records with a text editor and both hooks fired on the next run; that is one unverified report.