Postman’s AI plugin controversy is really about consent: what it installed, what it touched, and what it did not prove

Opening Postman on a Mac appears to have done more than open Postman. In a detailed GitHub issue filed against the company’s app-support tracker, a user said the desktop app’s own logs showed an auto-existing-upgrade step that installed Postman components into two coding agents — Anthropic’s Claude Code and OpenAI’s Codex — without an explicit request. The same report says the installer also wrote trust material for a startup hook, set up a remote MCP connection, and dropped a Postman CLI on the machine. Postman later said it would make the opt-in clearer, especially for existing users, and that it was reviewing the hook-approval behavior. GitHub issue #14370, RuntimeWire

What the evidence does not show is equally important: there is no confirmed proof in the thread that customer API data was exfiltrated. The issue describes a consent and trust-boundary failure, not a documented breach. The reporter wrote that the remote MCP connection at mcp.postman.com failed authentication, and later comments in the thread say there was “no evidence that data was uploaded.” GitHub issue #14370

What was installed

The core allegation is not that Postman silently read every request and shipped it to a server. It is that the app altered other tools on the user’s machine by default.

The reporter says Postman’s own main.log recorded:

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

That matters because the log label says the path was for an “existing user,” and the report frames the install as something that happened when the user opened the app, not after they clicked through a separate plugin prompt. The issue also says the machine picked up a Postman plugin marketplace entry in Codex’s config, an enabled Postman plugin in Claude Code, a separate Postman CLI in ~/.local/bin, and a remote MCP endpoint. GitHub issue #14370

A later independent write-up that reviewed the pinned plugin revision reached the same broad conclusion: the installation landed in Codex and Claude Code, the hook was set up to fire at session start, and the MCP connection existed but failed authentication. That secondary report also emphasized that the issue did not establish data exfiltration. DEV Community

Why the hook matters more than the plugin

The sharpest technical concern in the issue is not the plugin itself but the startup hook attached to it. In the reporter’s account, the Postman plugin added a session-start instruction that would load Postman’s API-engineering guidance before non-trivial API work, including designing, implementing, mocking, testing, monitoring, documenting or deploying APIs. That kind of hook changes the behavior of an AI agent on every session, not just when a user explicitly invokes Postman.

The issue says Postman’s installer then went a step further and approved that hook on the user’s behalf. In other words, the vendor’s installer appears to have written the trust decision that the host application normally expects a human to make.

That distinction matters operationally. In agent tools, hook trust is the control that prevents arbitrary code or instructions from becoming automatic on every future session. If an installer can mint that trust record for its own hook, the approval model becomes much weaker than users may expect.

A secondary analysis of the pinned plugin source described the same behavior: the installer calls an approvePostmanHook path after installation, and the hook text tells the agent to load Postman’s API skill for non-trivial API work. The report’s point was not that Postman had proven data theft, but that it had crossed a consent boundary inside another application’s configuration. DEV Community

What Postman said

Postman’s response, as quoted in the GitHub thread, was essentially that the integrations are bundled to make setup easier for users who had trouble wiring them up separately. The company said it mentions the bundle on the download page and in the app update flow, and that users can uninstall the components from inside the app. It also said it would make the opt-in clearer for existing users and review the hook approval and session-start behavior.

That answer narrows the dispute but does not erase it. If the product experience makes the integrations easy to remove but defaults them on for existing desktop users, the real question is not whether there is a removal path. It is whether the first-run or upgrade path gave users a meaningful choice before changing other tools’ settings.

Here is the practical version for teams that manage API tokens, schemas and internal endpoints: a desktop utility update can now change the behavior of an AI coding agent, not just its own UI. That means your security review for “an API tool update” should include the tools it can reach through local config files, agent hooks, and any bundled CLI that lands in the path.

What teams should check

For Postman users who also run Codex or Claude Code on the same machine, the issue points to a small set of places to inspect:

# Codex config
cat ~/.codex/config.toml

# Claude Code settings
cat ~/.claude/settings.json

# Postman CLI and other binaries
ls -l ~/.local/bin | grep -i postman

Look for:

• a Postman marketplace or plugin entry in Codex
• a Postman plugin enabled in Claude Code
• any session-start hook mentioning Postman
• trust records such as trusted_hash or trusted_content_hash
• a Postman CLI or other binaries that arrived alongside the desktop app
• any MCP connection pointing at mcp.postman.com

The reporter’s recommendation was more specific: stop automatic agent-plugin installation for existing desktop users until they explicitly opt in, remove installer-side hook self-approval, and narrow the startup instruction so it applies only when a user explicitly asks for Postman. That is the right scope because it addresses the three separate actions involved here: installing components, attempting to extend trust, and telling the agent how to behave on future sessions. GitHub issue #14370

What remains unproven

There are still open questions that the issue does not answer cleanly:

• Which exact release or feature flag gates the auto-existing-upgrade behavior?
• Does the same path affect all supported agent hosts, or only Codex and Claude Code on the reporter’s machine?
• Do signed-out users see the same behavior?
• Does the MCP connection ever transmit data in any real-world configuration, or did it simply fail to authenticate in this case?

Those gaps matter, but they do not change the basic story already established by the logs and the source review: Postman appears to have installed agent integrations into other tools by default on an existing user’s machine, and the reporter says the installer pre-approved its own hook. That is a trust problem even before anyone proves data left the machine.

The bigger lesson for AI toolmakers

AI agents and developer tools are increasingly built out of hooks, plugins and background integrations. That makes consent more important, not less. When an installer can write to another app’s config and pre-trust its own instructions, the line between “helpful onboarding” and “unasked-for behavioral change” becomes very thin.

For teams using API clients in production-adjacent workflows, the takeaway is straightforward: treat desktop updaters as privileged software. Audit what they can install, what they can register, and what trust records they can create in adjacent tools. If a vendor says the feature is easy to uninstall, also ask whether it was ever supposed to install in the first place.

Sources: GitHub issue #14370; Hacker News discussion; RuntimeWire report; DEV Community source review