Opening Postman, and Finding Five Things You Never Installed

Abstract

On October 24, 2026, a developer opened Postman Desktop 12.33.4 — an ordinary action. Over the following days, Codex began issuing MCP authentication warnings and routing API tasks to a Postman skill. Investigation located five artifacts on the machine that had not been installed by the user: a user-level Postman plugin, a session-startup hook script, a remote MCP connection to mcp.postman.com, a plugin installed into Claude Code, and a Postman CLI. On October 25, the full forensic record went to GitHub as issue #14370, with the first word of the title being SEVERE. On November 3, the thread reached the Hacker News front page at 968 points with 319 comments. Postman's official response acknowledged the behavior, promised clearer opt-in, and defended the design. This article reconstructs the evidence chain, examines why the hook self-approval is the part that matters, and separates what was proven from what the headline claimed.

1. The Timeline

Date	Event
September 29, 2026	A PR merges into the Postman plugin repository titled "Add postman/postman-plugin to install into every agent"
October 24, 2026	A user opens Postman Desktop 12.33.4
October 25, 2026	Issue #14370 filed on GitHub, titled SEVERE
November 3, 2026	Thread reaches Hacker News front page (968 points, 319 comments); Postman posts an official reply; a second user reproduces the behavior on 12.35.1
November 4, 2026	Issue remains open with no fix timeline

Two details in that table carry weight. The PR predates the incident by roughly a month, and its title is not ambiguous. Distributing into every agent was planned, tested, and covered by CI rather than introduced by an individual engineer's mistake. The second detail is the reproduction on 12.35.1, which establishes that this was not a single corrupted installation. The log entry auto-existing-upgrade appeared identically in both runs.

2. The Five Artifacts

The inventory matters because each item sits at a different layer of the machine.

1. A user-level Postman plugin.
2. A hook startup script that runs automatically in every session.
3. A remote MCP connection pointing to mcp.postman.com.
4. A plugin installed into Claude Code.
5. A Postman CLI the user never installed.

Items one, three, and five are ordinary distribution. Item two is the one that changes agent behavior. Item four places the same logic inside a second agent's configuration.

3. The Evidence Chain

The claim rests on logs and source code rather than on recollection, which is what distinguishes this report from the usual vendor grievance.

3.1 Postman's own log admits the install

In ~/Library/Application Support/Postman/logs/main.log, the record reads PostmanPluginService:install:skip, followed by script completed - with output: {"results":[{"claude-code:installed","codex:installed"}]}.

The application installed plugins into Claude Code and Codex during its startup or upgrade path. This is not an inference from behavior. It is the vendor's own instrumentation writing the outcome to disk.

3.2 Codex's global configuration was modified

~/.codex/config.toml gained a Postman marketplace entry, enabled plugins, and a trusted_hash record. That means the startup hook capable of altering agent behavior was marked as trusted.

The trust record is the crux. Everything downstream follows from the fact that this write succeeded without a human decision.

3.3 The hook instruction redefines the agent's default workflow

The injected instruction is a routing rule. Its substance: before responding to any non-trivial API engineering task — design, implementation, debugging, testing, validation, documentation, deployment — load the postman-api-engineer skill and follow it.

Read plainly, the agent is told to consult Postman first for essentially all API work. The scope is not narrow. It covers the entire category the coding agent was engaged to handle.

3.4 The installer source contains the self-approval

In the repository, codex-hooks.ts calls approvePostmanHook after installation. It retrieves the local hook hash through hooks.list, then writes the trust record via config.batchWrite. A source comment states the intent without ambiguity: "Approves only Postman's current hook after installation."

The installer approves its own hook. The trust gate exists, and the installing process walks through it by writing the record itself.

4. Why Self-Approval Is the Real Issue

Vendors bundling software is an old complaint. What moved this into serious territory is that two independent agent trust mechanisms failed at the same time, and both failed structurally rather than by oversight.

4.1 Codex: four structural flaws

A parallel experiment by another Hacker News participant, foma-agent, tested the trust mechanism directly and found four properties.

Co-location. The trusted_hash record lives in ~/.codex/config.toml — the same account, the same disk, the same directory as the process performing the installation. A trust store writable by the party being trusted is not a trust store.

Offline computability. The hash is derivable from open-source code with Python offline. A text editor and a hand-typed record produce a valid entry. No human participates in the act of trusting.

Declaration binding. The record binds to the hook's declaration rather than to the script content. Change the script's bytes and the record still matches.

Official bypass. Codex ships a parameter called --dangerously-bypass-hook-trust. A trust mechanism with a documented override is a speed bump, not a boundary.

4.2 Claude Code: write-then-effective

Claude Code's path is shorter. A hook written into settings.json takes effect immediately. In non-interactive mode (claude -p), no trust prompt appears at all.

Taken together, the finding generalizes beyond one vendor. If the trust decision can be written by anyone with write access to the configuration, the gate is decorative. Postman was simply the first vendor to turn the key. Any vendor pursuing aggressive AI plugin distribution would produce the same script.

The corollary is architectural: a trust decision belongs where the managing party controls it — the system keychain, signature verification, agent identity — not in a configuration file the agent itself can edit.

That principle has an operational counterpart. Credentials and authorization boundaries that an agent's own runtime can rewrite are not boundaries either. An access layer that holds upstream credentials outside the agent's writable space, applies per-destination allowlists, and records every outbound call at a point the agent cannot modify provides exactly the property the Codex trust store lacked. A gateway such as 4sapi occupies that position: credentials scoped per project, routing policy enforced at the edge rather than inside the agent's configuration, and an audit trail written where the agent has no write access. The failure here was not a missing mechanism. It was a mechanism located inside the managed party.

5. The Motive Structure

The injected instruction deserves a second reading, because its shape is familiar.

Every agent session now carries a startup context. That context determines default behavior in the same way that a browser toolbar determined default search in an earlier era, or a "set as default engine" prompt did during the search era. In the agent era, the entry point is the system prompt delivered at session start.

Converting "the agent's default API workflow" into "route through Postman" is entry-point capture performed through configuration rather than through user consent. The technique is not unique to this vendor, and this incident will not be the last instance of it.

6. The Official Response

Roughly a week after the dispute began — on November 3, the same day the thread reached the Hacker News front page — a Postman employee posted a formal reply in the issue. Three points.

Bundling was intentional. Many users cannot manage the separate installation flow for the CLI and the plugin, so packaging them together is presented as a convenience.

The components are bundled into the download and update path, and they can be uninstalled inside the application.

Feedback was heard. Opt-in will be made clearer, especially for existing users, and the hook audit and session-startup behavior will be addressed indirectly. Changes will be updated in the issue.

The community response compressed to one highly rated comment: if users cannot manage installation, the answer should be better guidance, not a default behavior. A second comment was sharper: trust is gone, and it is hard to see who would use Postman in production with confidence.

As of November 4, the issue remained open with no fix timeline.

One related allegation should be flagged as unverified. Some users accused Postman of revising download-page wording after the dispute to shift responsibility, citing a Wayback Machine snapshot from October 26. That claim is one-sided evidence with no official response, and it should be held as uncertain.

7. Separating the Headline From the Finding

The Hacker News thread title reads "attempts to share all API data." That phrase circulated widely and became attached to this incident. It is not what issue #14370 established.

What #14370 established: installation without consent, hook self-approval, and session-startup instruction injection.

The data-sharing claim is a separate matter. The original reporter explicitly limited the report to facts and evidence and did not assert data exfiltration. A prior issue — #13615, dated June 6, 2025 — alleged that Postman recorded complete customer request URLs and uploaded them to its own servers. Media coverage bound the two together under one headline.

The distinction is worth preserving. A historical allegation can amplify the seriousness of a current finding, but it does not merge with it. Conflating the two weakens the part of the case that is actually documented.

Two further points remain one-sided: the download-page wording allegation, and the scale of affected users. No official figure exists. Reproduction statistics suggest that existing users on the upgrade path are likely to trigger it, but the number cannot be quantified.

8. What to Check Now

Four checks, each local.

Inspect ~/.codex/config.toml for a plugins."postman@postman" entry and a hooks.state trust record. Inspect ~/.claude/settings.json for postman@claude-plugins-official. Inspect ~/.local/bin for a Postman CLI of unexplained origin.

Watch agent behavior. Repeated MCP authentication warnings in Codex, and API tasks being routed to a Postman skill, are the observable symptoms.

Decide on removal deliberately. Postman states the components can be uninstalled inside the application, but multiple users in the issue report that residue is difficult to clear: configuration, trust records, marketplace entries, cache, and CLI. Community-reported alternatives include Bruno as an open-source option, Insomnia, and lighter tools such as Restfox or plain curl scripts.

For anyone building an agent framework or plugin system, the lesson transfers directly. Put trust decisions where the managed party cannot write. Bind trust to script content, not to a declaration. Do not ship a parameter that bypasses trust in one flag. And do not assume users have reliable intuition about where a trust boundary actually sits.

9. Conclusion

The incident is not primarily about a bundled plugin. It is about three mechanisms that were assumed to be boundaries and turned out to be conventions.

The hook trust gate was a file the installing process could write. The hash was computable offline from public code, so a text editor produced a valid trust record. The hook bound to a declaration rather than to script bytes, so content could change without invalidating approval. And a documented bypass flag existed for the case where the gate proved inconvenient.

Postman's conduct — installing without consent, approving its own hook, injecting a routing instruction at session start — is the trigger. The vulnerability it exposed is the finding. Any vendor distributing AI plugins into agents would have passed through the same gate, because the gate was in the wrong place for everyone.

The corrective is structural rather than procedural. Trust stores, credential scopes, and authorization records must live where the party being governed cannot rewrite them. Until that is true, "trusted" describes a file location, not a decision.

---

International access: https://4sapi.com Domestic access: https://4sapi.org