Postman Silently Installs Its Plugin in Claude Code and Codex and Trusts Its Own Hook

TL;DR

Postman's desktop app has been installing its own plugin into Claude Code and OpenAI's Codex for signed-in existing users, with no prompt anywhere in the flow. The forensic report in issue #14370 quotes Postman's own logs recording the install, and pins the installer source that writes the trusted_hash Codex uses as proof a human approved the hook. A second user reproduced the auto-install on the current 12.35.1 release on November 3. Postman has posted no reply in the issue, which rode to the top of Hacker News with more than 1,200 points and 400 comments.

What the log says

On October 24 at 09:34 UTC, a signed-in Mac running Postman 12.33.4 was opened, and wrote this into ~/Library/Application Support/Postman/logs/main.log:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}
Main: autoInstall.plugin.existing-user finished

The user, GitHub handle indicava, had clicked nothing. Opening the app was the entire interaction. That one launch left five changes on disk: a marketplace entry and enabled plugin in Codex's ~/.codex/config.toml, a plugin enabled in Claude Code's ~/.claude/settings.json (version 2.0.1, user scope), a session-start hook, a remote Model Context Protocol entry pointing at mcp.postman.com/mcp, and a Postman CLI binary in ~/.local/bin. An API client whose whole job is sending requests you explicitly wrote now sends configuration changes to other programs on your machine.

The installer approves its own hook

The step that turned a rude rollout into a security argument is one function. Codex refuses to run a session-start hook unless its hash appears in hooks.state as a trusted_hash, and that field is supposed to be the record of a human reviewing the hook and saying yes. Treat it as a permission slip only the person at the keyboard signs.

Postman's installer signs it for you. The pinned revision of installer/src/hosts/codex-hooks.ts fetches the hash of the hook it just registered, then calls config/batchWrite to write that hash into hooks.state. The code comment reads "Approves only Postman's current hook after installation". The README of the public postman-plugin repo, created September 11, says the same in plainer words: for Codex, "installation also approves Postman's session-start hook", and "there is no separate hook prompt or dump of its instructions."

So this is documented behavior, shipped on purpose. What changed on November 3 is that several thousand people read the documentation.

What the hook tells your agent

The hook, session-start-context.md, is registered with the matcher startup|clear|compact: it fires at session start, on context clears, and on compaction. Its instruction tells the agent that "before responding to any non-trivial API engineering task" it must load the postman:api-engineer skill and follow it. Designing, mocking, testing, documenting, or deploying an API all count. The user never has to mention Postman.

The reporter is careful about scope, and the care is worth copying. The issue states plainly that it does not claim data exfiltration: on the reporting machine, the MCP connection failed with "Auth required" on initialize. The Hacker News title, "attempts to share all API data", runs ahead of the evidence. What the evidence shows is instruction injection into every agent session, approved by the injector.

Still shipping, still unanswered

On November 3 a second user, ronthedrummer, posted logs from the current release. Postman updated itself from 12.31.3 to 12.35.1 on launch, then auto-existing-upgrade installed the CLI (version 1.85.0), the Claude Code plugin, and the Codex marketplace and plugin entries, and logged cursor:already-installed for a Cursor plugin from an earlier date. On that machine the Codex config got no trusted_hash entry, which the user attributes to running an older Codex build. The auto-install itself needed no particular version.

There is no official Postman reply in the 44-comment issue as of Wednesday morning UTC. Users in the thread also flagged that Postman's downloads page grew disclosure copy after the fact, pointing at an October 26 Wayback snapshot that shows none; that edit is documented by screenshots in the thread, not by Postman. The remedy round in the comments is what you would expect: switch to Bruno or Insomnia, and one user started building an open-source client the same evening.

Check your machines

If Postman and any coding agent share a machine with you, four places to look:

• ~/.codex/config.toml: a [marketplaces.postman] block, [plugins."postman@postman"], and any hooks.state entry naming a Postman path
• ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json: postman@claude-plugins-official
• ~/.local/bin/postman: the CLI, 1.85.0 in the November 3 report
• Cursor's plugin cache, if you run Cursor; the same session-start text lands there

The installer ships status and remove subcommands, and the desktop app exposes an uninstall button for the hooks, screenshotted in the thread.

Why this generalizes

Nothing here required an exploit. Agent configuration is plain text in your home directory, and every vendor with an agent strategy has a growth reason to get its instructions into your sessions. A session-start hook that says "use my product for API tasks" renders inside the model's context, ahead of your prompt, every session. Postman wrote the instruction, the installer covered the approval, and the README documented the mechanism in the open.

The trust question outlives Postman. Any desktop app can detect Codex or Claude Code and write a plugin, a hook, and a hash. The installer covers nine agents: Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory Droid, Kimi Code, OpenCode, and Pi. If hook approval can be written by whatever process installed the hook, trusted_hash stops meaning a human reviewed it and starts meaning an installer got there first.

Caveats

The October 24 report is one machine, and the reporter says the sequence has not been reproduced on a clean install. The November 3 report matches it in the logs on a different account, version, and week. The self-approval is proven in public source and stated in the README; whether the trust record on the original machine came from that code path is the reporter's own stated caveat. No exfiltration is alleged, and the MCP server rejected the connection on the one machine with public logs. Postman's side of this may add context when it arrives; so far it has not arrived.

Key Takeaways

• Postman desktop 12.33.4 auto-installed its plugin into Claude Code and Codex plus a CLI on a plain app launch, logged as auto-existing-upgrade for a signed-in existing user, with no prompt.
• The installer's code writes the trusted_hash for its own Codex session-start hook, and the public README states there is "no separate hook prompt". Codex's hook-trust gate assumes a human approves; here the installer did.
• The hook fires on startup, clear, and compaction, and instructs the agent to load the postman:api-engineer skill for any non-trivial API task, whether or not the user mentioned Postman.
• A second user reproduced the auto-install on 12.35.1, the current release, on November 3. The 44-comment issue has no official Postman reply, and the Hacker News thread passed 1,200 points.
• No data exfiltration is claimed or shown; the MCP connection failed auth on the reporting machine. What is established is a consent failure: instruction injection approved by the injector.
• Check ~/.codex/config.toml, ~/.claude/settings.json and installed_plugins.json, and ~/.local/bin/postman. The installer ships status and remove subcommands.

Sources: Postman issue #14370 (logs, configs, pinned source), postmanlabs/postman-plugin repo, installer/src/hosts/codex-hooks.ts (pinned revision), hooks/session-start-context.md (pinned revision), Hacker News thread (1,253 points), Independent analysis (elsolitario.org), Wayback snapshot of postman.com/downloads, Oct 26