Introduction
I open Postman the way most developers do: without thinking about it. It is a tool I trust, a tool that has sat on my dock for years, a tool I open to test an endpoint and then forget about. This week, that habit turned into a story that shot to the top of Hacker News, and it is worth your attention even if you have never touched an AI coding agent.
Here is the short version. A developer opened Postman desktop on a Mac, and Postman's own logs show that the app's upgrade path installed Postman plugins into two other tools on that machine — Anthropic's Claude Code and OpenAI's Codex — without the user clicking install. The installer also wrote a trust record approving its own startup hook, dropped a Postman CLI onto the machine, and pointed the agents at a remote Postman server. Postman has since said it will make the opt-in clearer, especially for existing users.
The longer version matters more, because the viral headline gets one big thing wrong. The popular version of this story says Postman "attempted to share all API data." The evidence in the GitHub thread does not support that claim. The remote connection never authenticated on the reporter's machine, and the reporter explicitly does not claim any data was exfiltrated. What the evidence does support is narrower, and honestly more useful: a desktop app edited other tools' global settings, added a standing instruction to every agent session, and approved its own trust record — the one decision that is supposed to be yours.
What happened, step by step
The story starts with a GitHub issue filed on October 25, 2026, against Postman's app-support tracker (postmanlabs/postman-app-support #14370). The reporter, posting as indicava, ran Postman desktop version 12.33.4 on a Mac. When the app opened, Postman's own main.log recorded an entry at 2026-10-24T09:34:14Z with the source labelled auto-existing-upgrade and the results claude-code:installed and codex:installed.
That wording is important. This was not a user clicking "install plugin" in a marketplace. It was an existing-user upgrade path, firing on open, that reached into unrelated tools. On that machine, the install touched several places at once. The Codex configuration file, ~/.codex/config.toml, gained a Postman git marketplace entry plus an enabled postman@postman plugin, along with a hooks.state entry carrying a trusted_hash for Postman's SessionStart hook. Claude Code received postman@claude-plugins-official at user scope. A Postman CLI landed in ~/.local/bin. The installed plugin revision was pinned at 6c8e452e0f4237f4bcc0901cb1ac442dec707e49.
A second reporter, posting as ronthedrummer, reproduced the same log pattern on November 3 after upgrading from version 12.31.3 to 12.35.1: the CLI, the Claude Code plugin, and the Codex plugin installed, with Cursor recorded as already installed.
The story reached the top of Hacker News on November 3, gathering over 1,200 points and hundreds of comments, and posts about it on X jumped from around 70 on November 3 to 435 by 9 AM Eastern on November 4.
The hook is the part you should actually worry about
Of everything the installer did, the startup hook is the piece I keep coming back to. Modern coding agents support hooks: small instructions that run automatically at certain points, such as the start of a session. Because a hook can run code and shape what the agent does, agents protect them with a trust step. OpenAI's own documentation for Codex explains the idea plainly: Codex records trust against a hook's current hash, so a new or changed hook is marked for review and skipped until it is trusted.
Postman's installer answered that review itself. In the public plugin repository, a file called codex-hooks.ts contains a function named approvePostmanHook. It asks Codex for its hook list, finds Postman's hook, and writes the hook's hash into hooks.state as trusted. The function arrived in a commit on October 21 titled "feat(installer): auto-approve Postman's Codex hook (#124)" — three days before the logged install on the reporter's machine. This was not a shipping accident or a race condition. It was intentional design, written down in a commit message.
And the hook itself is not decorative. It tells the coding agent, in effect: before responding to any non-trivial API engineering task, load the postman:api-engineer skill. That means every agent session on that machine now carries a standing instruction, installed by another app, to route API work through Postman's skill. You did not write that instruction. You did not approve it. It is simply there, running at the start of every session, until you remove it.
There is one more detail that widens the story: an analysis of the installer's source code found that its host list covers nine coding agents, not just the two named in the original report, and the result names in both desktop logs — claude-code, codex, and cursor — match the identifiers that installer uses.
What the evidence does not prove — and why that correction matters
I want to be precise here, because precision is the whole point of this story. The viral headline says Postman "attempts to share all API data." That goes further than the evidence, and repeating it without the correction would make this article part of the problem.
The plugin configures a remote MCP connection at https://mcp.postman.com/mcp. MCP, the Model Context Protocol, is the standard way AI tools connect to external servers and tools. On the reporter's machine, the Codex log shows the connection attempt ending with "Auth required" — the connection failed. The reporter explicitly does not claim data exfiltration, and the second reporter wrote that he had no evidence data was uploaded. Multiple independent write-ups that reviewed the thread reached the same conclusion: the consent and trust-boundary failure is well documented, while data exfiltration is not proven.
That distinction does not let Postman off the hook. It changes what the offence is. This is not a documented breach. It is a consent failure with a security shape: software that modifies other tools' global configuration, approves its own trust record, and sets up a remote connection, all without clear user action. The fact that authentication failed on these machines is luck, not design.
One honest caveat: as of the first write-ups, the behaviour had not been reproduced on a clean system by an independent party. Treat this as a well-documented incident report, not a court verdict, and check your own machine rather than taking anyone's word for it — including mine.
What Postman said
Postman responded in the GitHub issue. A representative posting as zecoquit said the company bundles the CLI and agent plugins to ease setup, that they are mentioned on the download page and in the update flow, and that they can be uninstalled from inside the app. Crucially, the same response said Postman will "make the opt-in clearer, especially for existing users" and is reviewing the hook-approval and session-start behaviour.
That response concedes the core complaint in practice: if the opt-in needs to be made clearer for existing users, then it was not clear enough. Bundling a CLI to ease setup is reasonable; silently writing trust records for your own hook in another company's tool is not the same decision, and reviewing it is the right move — but it should have happened before the installer shipped, not after Hacker News noticed.
What to check on your own machine tonight
If you have opened Postman desktop recently, spend ten minutes checking. First, look at your agent configs. On Codex, check ~/.codex/config.toml for a Postman marketplace entry or an enabled postman@postman plugin, and check hooks.state for a trusted Postman SessionStart hook. On Claude Code, check ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json for postman@claude-plugins-official. If you use Cursor, check whether a Postman plugin is listed there too.
Second, look for the CLI. Check ~/.local/bin for a Postman executable you did not deliberately install. If you find one and do not want it, remove it along with the plugins.
Third, decide what you actually want. There is nothing wrong with using Postman's agent plugins on purpose. If the plugin genuinely helps your API workflow, keep it — but install it deliberately, through the plugin's own install path, after reading what the hook does.
Fourth, check the MCP connection. Look for a remote server entry pointing at mcp.postman.com in your agent config. If it is there and you did not add it, remove it. If you want the integration, add it back yourself, with authentication you control.
Finally, treat this as a reason to audit agent trust more broadly. Your coding agent's config files are now security-sensitive in the same way your SSH config is: any app with permission to write to your home directory can, in principle, edit them. Re-check them after every major tool update.
Why this story matters beyond Postman
Zoom out, and this incident is a preview of a much bigger argument. AI coding agents are becoming the place where development actually happens: they read your repositories, run your tests, and touch your infrastructure. Every vendor in the toolchain wants to be the default skill, plugin, or MCP server inside that agent, and that competition will be fought in installers, upgrade paths, and default settings — exactly the places users stop reading.
That is why the trust-record detail matters more than the plugin itself. Plugins are visible; you can list them and remove them. Trust records are invisible infrastructure. When an installer can approve its own hook, the review step that protects you becomes theatre. If that pattern spreads, your agent's behaviour will be decided by whichever installer ran most recently, not by you.
The fix is boring, and that is a compliment. Visible opt-ins, especially for existing users. No self-approval of trust records, ever. Uninstall paths that remove everything the installer added. And changelogs that say, in plain language, "this update touches your other tools."
Conclusion
Postman's plugin incident is not a data-breach story, and saying so clearly matters. No evidence has been shown that API data was uploaded, and the remote connection on the reporter's machine failed authentication. What it is, instead, is a consent story with real security teeth: a desktop app installed plugins into Claude Code and Codex through an existing-user upgrade path, approved its own startup hook through a function literally named approvePostmanHook, and wired in a remote server — all without an explicit install click from the user.
Postman has promised a clearer opt-in and a review of the hook behaviour. That is a good response to a bad design, and developers should hold the company to it. In the meantime, the practical move is simple: check your agent configs, remove what you did not choose, and reinstall deliberately anything you actually want.
Frequently asked questions
What exactly did Postman install without asking?
According to GitHub issue #14370, opening Postman desktop 12.33.4 triggered an auto-existing-upgrade step that installed Postman plugins into Claude Code and Codex, added a Postman CLI in ~/.local/bin, and set up a Postman SessionStart hook with its own trust record. A second user reproduced the same pattern upgrading from 12.31.3 to 12.35.1.
Did Postman steal or upload API data?
No evidence of data exfiltration has been shown. The plugin configured a remote MCP server at mcp.postman.com, but on the reporter's machine the connection failed with "Auth required," and both reporters said they had no evidence data was uploaded.
What is the approvePostmanHook function?
It is a function in Postman's public plugin installer, in codex-hooks.ts, that finds Postman's Codex startup hook and writes its hash into hooks.state as trusted — bypassing the review step that is supposed to be the user's decision. It arrived in a commit on October 21 titled "feat(installer): auto-approve Postman's Codex hook (#124)."
How do I check whether I am affected?
Check ~/.codex/config.toml and hooks.state for Postman entries, ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json for the Postman plugin, and ~/.local/bin for an unexpected Postman CLI. Remove anything you did not deliberately install, including any mcp.postman.com remote server entry.
What has Postman said it will do?
Postman said it bundles the plugins to ease setup and that they are uninstallable in-app, and it promised to "make the opt-in clearer, especially for existing users" while reviewing the hook-approval and session-start behaviour.
Should I stop using Postman or AI coding agents?
No. The sensible response is not to abandon the tools but to audit them: remove what you did not choose, reinstall deliberately what you want, and re-check agent configs after major tool updates. Your agent's startup instructions should come from you, not from another app's installer.
