Postman Accused of Silently Installing AI Plugins
A detailed bug report is causing concern among API developers: Postman, one of the most widely used API development platforms, allegedly installs AI-related plugins and reroutes API workflows on its own, without asking the user first. The report was filed on GitHub and quickly picked up in developer communities, where it gathered significant attention and debate.
What the report actually describes
The GitHub issue starts with a fairly ordinary situation: a developer noticed unexpected behavior in their coding agents after simply opening Postman on a Mac. Digging into it, they found a string of changes they never approved. A user-wide Postman plugin had appeared, a startup instruction hook had been injected into a separate tool called Codex, and a remote MCP connection, the Model Context Protocol that lets AI agents talk to external tools, was pointing to a server owned by Postman. On top of that, a Claude Code plugin had been installed separately, along with a standalone Postman CLI binary.
The report backs this up with log excerpts and file paths. These show a session-start hook registered to make Codex load a "postman:api-engineer" skill before handling any API-related task. The author also traced installer code that appears to approve Postman's own hook automatically right after installation, instead of waiting for explicit user confirmation. To the author's credit, the report is careful here: the self-approval code path exists, but it does not prove with certainty that this exact mechanism triggered the behavior they observed on their own machine. *
Why this matters for developer trust
The complaint isn't really about one plugin. It's about consent, and about what a developer tool is allowed to do to other tools on the same machine without asking. Installing software, opening remote connections, and letting automation hooks run inside unrelated applications are the kind of actions that normally require a visible opt-in inside the tool being changed. According to the report, Postman's installer made these changes across other tools on its own.
The author was careful to separate two different claims. The investigation shows "unwanted integration and instruction changes," but it does not show that any API data was actually sent out or exfiltrated. Unauthorized configuration changes and unauthorized data transfer sit at very different severity levels, and only the first one has direct evidence behind it in this report.
Reactions in the discussion were largely critical. Several commenters compared the behavior to bundled adware tactics seen in other popular desktop software over the years, and some recommended switching to open-source alternatives such as Insomnia. One comment referenced an archived snapshot of Postman's download page, suggesting the wording may have changed after the issue was raised, though this particular detail isn't independently confirmed in the source material.
Who is affected, and how
Two groups carry most of the exposure here. Individual developers and freelancers who use Postman for quick API testing may never notice the plugin or configuration changes at all, since the behavior reportedly happens quietly during normal use or right after an update. For this group, the main risk is unknown background processes and coding agents that suddenly start routing tasks through a Postman "skill" they never asked for.
Corporate and enterprise teams face a sharper version of the same problem. API clients in these environments routinely handle internal endpoints, authentication tokens, and proprietary service definitions. If a desktop tool can quietly modify another application's trust settings without a visible approval step, it breaks the assumption IT and security teams rely on when they approve software for company laptops in the first place. One commenter in the thread put it plainly: "This is unacceptable, even creating risk in corporate environment."*
What is sensible to do right now
At this point, everything rests on a single detailed user report. There is no official statement from Postman confirming or denying the behavior, and it's not yet clear whether the company will respond publicly, patch the installer, or push back on the findings. Teams using Postman should treat this as a reason to check their setup carefully, not as a reason to panic or rip the tool out immediately.
A practical first step is checking company machines for any MCP connections, Codex hooks, or Claude Code plugins tied to Postman, and confirming whether those were explicitly approved by the user or by IT. Teams managing shared developer environments may want to hold off on Postman updates for a short while, at least until there's more clarity on what changed and why. Anyone running a security review on third-party developer tools should take this as a reminder to look at default plugin behavior and remote connection permissions directly, rather than relying only on the vendor's published privacy policy.
For teams reassessing their broader software supply chain and integration risk, incidents like this are a useful trigger to revisit how internal tools get vetted before developers install them freely on work machines. We regularly help companies through our software consulting services set up exactly this kind of review process, ideally before an incident forces a reactive scramble rather than after.
A few signals are worth watching from here: whether Postman issues an official statement, whether the GitHub issue gets a maintainer response or an actual fix, and whether independent security researchers manage to reproduce the installation behavior on a clean machine. The original reporter noted they hadn't done that reproduction step yet themselves.
If your team is weighing a broader review of the developer tools and AI integrations running across your organization, our contact page is a good starting point to talk through what that review should cover.
