AI systems · source review
Postman's installer treats hook approval as installation
A 150 word startup instruction is small. Letting its installer approve that instruction inside another application is the consequential part.
Postman's Codex installer checks which hook it is about to trust, checks that its instruction file exists, and checks that the hash has not changed. What it does not do in that approval path is ask the person running Codex to review the instruction. Its README says this plainly: “There is no separate hook prompt or dump of its instructions.”
That is a narrower, more useful finding than saying the installer has no consent anywhere. It does have a general installation confirmation. The design choice is to treat agreement to install a plugin as sufficient authority to approve its startup instructions too. Version integrity and informed approval have become the same operation, even though they answer different questions.
The incident report and the code are different evidence
In Postman desktop issue #14370, a user reports that opening an existing Mac installation was followed by unexpected Codex and Claude Code integrations. The report identifies desktop version 12.33.4, a Codex plugin revision, changes to user configuration, and desktop log entries containing auto-existing-upgrade. It also records authentication errors from the remote Postman MCP server.
Those logs are the reporter's evidence, not a clean Mac experiment we repeated. The report itself makes an important distinction: a trust record in a configuration file does not establish who wrote that particular record. It explicitly does not claim to establish data exfiltration. Neither should a writeup of it.
The public plugin repository supplies a different kind of evidence. At the exact revision linked in the report, the installer has an explicit path for attempting hook approval. Reading that path establishes the intended behavior of that source revision. It does not establish which desktop release ran it, how many machines received it, or whether every approval attempt succeeded.
The approval operation is part of the install operation
In the Codex adapter, installation adds or updates the plugin, removes duplicate installations, then calls approvePostmanHook(system). This is not an instruction asking the model to persuade a user. It is ordinary installer code talking to Codex's application server.
The approval function requests hooks/list, selects a specific Postman hook key, and accepts only the expected untrusted or modified states with a usable hash. Already trusted hooks are left alone. It reads the installed session-start-context.md and requires that the file contain something other than whitespace.
It then obtains another hook listing. If the hash or state changed during inspection, it skips approval. Otherwise it sends this configuration edit, with the hook key abbreviated here for readability:
method: config/batchWrite
edits:
keyPath: hooks.state
value: { [POSTMAN_HOOK_KEY]: { trusted_hash: hook.currentHash } }
mergeStrategy: upsert
reloadUserConfig: true
There is also a third listing after the write, to see whether Codex reports that exact hash as trusted. Calling this merely “two hash checks” loses the useful distinction: the function checks stability before writing and checks the reported outcome afterward. It can report that Codex accepted a write without confirming trust. Missing APIs and failed writes produce a note rather than necessarily failing the plugin installation.
The general confirmation is real
This is where the strongest version of the accusation becomes inaccurate. The outer installer runner does ask whether to install or update Postman in the detected agent hosts when run interactively without --yes. In a noninteractive session without that flag, it refuses to make the installation changes.
With --yes, the general confirmation is skipped. The Codex adapter then performs its hook approval procedure without an additional hook review. The README discloses this, and the repository includes a test named “unattended installs approve the hook without any extra flag or prompt.” That is a test using a fake host, not proof of a live Codex reproduction; it does make the intended contract unusually explicit.
The right criticism is therefore not “there is no human confirmation in this installer.” It is that the installer collapses several decisions into one: add a plugin, add its integrations, and trust its startup instruction. A user can reasonably want the plugin available without wanting its default instructions admitted into every relevant session.
The closed desktop application's choice to invoke an installer is another boundary. The public runner alone does not tell us which arguments the desktop used, what the update interface displayed, or what an existing user had previously agreed to. Inferring those details from a field named exposed would turn an investigation into a guess.
What the 150 words ask the agent to do
The startup instruction contains 150 whitespace separated words, including its wrapper tags, and names 12 distinct postman: skills. Its central instruction is broad:
“Before responding to any non-trivial API engineering task — designing, implementing, mocking, testing, monitoring, documenting, or deploying an API or Postman Flow — load the
postman:api-engineerskill and follow it.”
This is not just metadata telling the agent which tools exist. It supplies a default workflow for seven categories of engineering work, including work where the user did not explicitly request Postman. The entry skill can route to more specific skills; a sufficiently specific request may enter one directly.
The limitations matter too. Pure questions and trivial edits are exempt. Dispatched subagents are told to ignore this block because the orchestrating session already shaped their task. The instruction explicitly says that project instructions and direct user requests take precedence. Omitting those sentences would falsely turn a broad default into a claim that Postman instructs agents to override their users.
Even with those qualifications, admission to startup context matters. A workflow default can steer tool selection before a user has asked to use a particular vendor. Whether it actually changes an agent's behavior depends on the host, the task, and the rest of the instructions. Source text is evidence of the requested behavior, not a measurement of compliance.
| Observable in this revision | Scope of the number |
|---|---|
| 150 words | Whitespace split of the startup file, including wrapper tags. |
| 12 skill names | Distinct names in that file, not 12 automatic tool calls. |
| 9 supported hosts | Installer coverage in the README, not 9 verified trust failures. |
| 3 hook listings | Inspection, stability check, and outcome check on the successful write path. |
A hash can identify a version without authorizing it
The prewrite recheck is useful. Its comment explains that application startup can refresh marketplaces; a different hash needs another check rather than approval of a version different from the one inspected. That guards against a change during this particular procedure. It does not make the instruction harmless, and it does not show that a person reviewed its meaning.
The README's Codex commands track main. It says that a manual install requires hook review inside Codex, while rerunning the npx installer also approves the hook after an install or update. A later source revision can therefore become a new approval candidate when the installer runs again.
That does not mean an upstream change automatically executes under the old hash. Nor does it make the race check useless. It means that the policy for approving a new version is still implemented by the installer itself. Pinning a revision and separating approval are complementary controls: one identifies what you reviewed; the other records whose decision the review represents.
Nine host adapters are not nine identical incidents
The README names Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory Droid, Kimi Code, OpenCode and Pi. That is a meaningful distribution surface, but their integration mechanisms differ. The verified self approval path discussed here is the Codex adapter, not a universal protocol shared by all nine.
Pi is a useful counterexample. Its extension source registers MCP configuration when the host supports that API, and adds the startup mandate during before_agent_start only when the entry skill is loaded. That is an extension and prompt assembly mechanism. The existence of mcp.pi.json does not establish a Codex style hash approval bypass in Pi.
Reports across versions also deserve restraint. A later commenter describes a desktop upgrade that installed integrations but left no Codex hook trust record, and subsequently clarified that they had not observed the Codex hook executing. Installation, a trust write, and an executing startup hook are three distinct observations.
A separate Codex issue about trust invalidation reports hooks requiring review again after ordering or environment changes. That is not evidence that distrust was bypassed. Another commenter describes locally minting trust records, but we have not reproduced that experiment. Neither claim is needed to establish the installer behavior visible in this revision.
The control to separate
For a team running coding agents, the immediate question is who can alter the files that admit tools, plugins and startup instructions. Preserve configuration history, inspect what changed, and distinguish an enabled plugin from a trusted and executing hook. Do not delete an entire agent configuration to remove one integration, or assume removing a desktop application necessarily reverses changes in other applications.
For host and plugin authors, keep the decisions separate. Show the instruction and its scope before approval, make unattended approval an explicit policy rather than a side effect of a broad install flag, and record provenance that distinguishes host review from installer automation. None of this claims a same user configuration file can defend against every process already executing with that user's permissions. It makes ordinary product consent inspectable instead of ambiguous.
Sources and verification limits
- Desktop incident report and comments, read on November 4, 2026. Desktop observations are attributed to their reporters. Comments include a response speaking on behalf of the product; repository association metadata alone does not authenticate employment or establish the absence of an official response.
- Plugin source. Counts and control flow above refer to the version linked in the incident report, not a claim about all past or future releases.
- Installer tests document intended fake host behavior. This review did not execute the Postman installer, modify agent configuration, or reproduce desktop installation, live hook approval, data upload, or offline trust minting.