Postman's MCP Plugin Installed Itself Into Claude Code and Codex: What the Audit Trail Actually Shows

A developer running Postman Desktop 12.33.4 on macOS noticed something odd in their main.log on October 24, 2026: two lines, timestamped 09:34, reading codex installed and claude code installed. They had not asked Postman to touch either tool. The install log attributed the change to a source string, auto existing upgrade, that does not appear anywhere in Postman's own public plugin repository. The developer filed a GitHub issue the next day, October 25. As of early November, it remains open, unassigned, with no reply from Postman staff.

The specifics matter here because this is not a vague complaint, it is a reproducible configuration diff. On the Claude Code side, settings.json came out enabling postman@claude plugins official at plugin version 2.0.1, installed at user scope, with a timestamp matching the log entry. The public main branch of Postman's plugin repository currently declares a newer version, 2.3.0, in its mcp.claude code.json manifest, which tells you this was not a one off fluke from an old build; the mechanism that produced it is still live in a version ahead of what got silently installed. On the Codex side, config.toml gained a new postman marketplace pointed at postmanlabs/postman plugin.git, enabled, plus a trusted hash keyed to the plugin's session start hook. That hash is the part worth sitting with for a second, because a trusted hash is normally how a tool records that a human explicitly approved a hook that runs automated code on every session start. The installer's own code path for Codex calls a function named approvePostmanHook that writes that trusted hash through a batch config write, with no separate prompt the README discloses. In plain terms, the install flow approves its own hook on your behalf as part of installing it.

Why the hook, not the install, is the part that should worry you

Plenty of developer tools add a background process or a small configuration tweak without much ceremony, and most of the time nobody cares, because the thing being added does not run code against every future session. This one does. The hook Postman's plugin registers matches on startup, clear, and compact, meaning it fires every time you start a Claude Code session, every time you run slash clear, and every time context gets compacted. Each time, it prints a file called session start context dot md, which instructs the agent to load Postman's api engineer skill before doing any nontrivial API work. That instruction sits silently in context on every session from then on, shaping what the agent reaches for without you choosing to add it to your own CLAUDE.md or AGENTS.md. The permission sandboxing that recent Claude Code releases have shipped exists specifically to make exactly this kind of distinction, autonomous versus reviewed, enforceable rather than left to whichever plugin got there first, and a hook that both installs itself and pre approves itself is working around precisely the control that sandboxing is meant to provide.

To be fair to Postman, the public repository does disclose that installing the plugin also approves its session start hook, and the README states there is no separate hook prompt by design. That is a defensible choice for a plugin a developer deliberately installed through the normal flow. It stops being defensible the moment the plugin installation itself happens without a visible prompt, which is what the reporter describes and what nobody, including Postman, has yet explained. The open questions in the GitHub issue are exactly the right ones: what does auto existing upgrade actually refer to, which release and which users were affected, and whether the app triggered install path also self approves the hook the same way the Codex installer's code does. None of those have answers yet.

The supply chain angle you should actually be watching for

This is not the first time an agentic coding tool's plugin or dependency surface has turned into an unexpected trust boundary. The Shai Hulud worm that moved through npm packages reachable by Claude Code earlier this year worked by exactly this kind of mechanism, a dependency that most developers trusted implicitly turning into a vector none of them had reviewed, and the lesson from that incident generalizes directly here. Every MCP server and every plugin marketplace your coding agents can reach is a piece of software that can write to your configuration, register hooks that run on every session, and inject instructions into context you never explicitly approved. The number of these connections has grown fast across the ecosystem precisely because they are useful, NetSuite's own AI Connector Service is a good example of an enterprise vendor building MCP access deliberately and with governance built in from the start, which is the right way to do this. A desktop app quietly rewriting your agent's config without a prompt is the wrong way, regardless of whether anything bad has actually happened yet in this specific case.

What should change on your end is not panic about Postman specifically, it is a habit. Treat your Claude Code settings.json, your Codex config.toml, and any equivalent files for other agentic tools you run as configuration you audit periodically, not configuration you set once and forget. A five minute diff against a known good baseline would have caught this immediately, because the change here was not subtle once you looked, it was two new plugin entries and a trusted hash that nobody remembers approving.

When this applies to your stack

If your organization runs Claude Code, Codex, or any MCP capable agent across a development team, build the audit habit now rather than after an incident forces it. Check settings.json and config.toml style files for plugins and marketplaces nobody on the team remembers installing. Treat any trusted hash or pre approved hook you did not explicitly review as a finding, not a formality. Ask every vendor whose desktop app sits near your development environment whether it can write to agent configuration files, and if the answer is yes, ask specifically whether that write requires a visible prompt. Teams building internal tooling or governance policy around which MCP servers and plugins are allowed to run against company codebases should treat this incident as the concrete case study it is, not a hypothetical.

FAQ

Did Postman's app actually steal any data through this MCP plugin? No breach is confirmed in the public record. The MCP server the plugin tried to reach failed authentication in the reported case, so no data is known to have reached it. The concern is the undisclosed install and self approval mechanism, not a proven exfiltration.

What exactly got changed on the affected machine? Claude Code's settings.json was updated to enable Postman's official plugin at version 2.0.1, user scope. Codex's config.toml gained a new marketplace entry for the same plugin plus a trusted hash approving its session start hook, all without a reported prompt.

Has Postman responded to the GitHub issue? Not as of this writing. Issue 14370 on postmanlabs/postman app support remains open, unassigned, and without a reply from Postman staff.

How can I check if this affected my own setup? Open your Claude Code settings.json and installed_plugins.json, and your Codex config.toml, and look for a Postman entry you do not remember installing, along with its install timestamp. Compare against a backup or a teammate's clean config if you have one.

Does this mean MCP plugins in general are unsafe? No. MCP is a useful, increasingly standard way to connect agents to real systems, and plenty of vendors implement it with clear consent and governance. The issue here is a specific implementation gap, an install and hook approval path with no visible prompt, not a flaw in the protocol itself.

Sources:

• Postman Agent Plugin in Codex and Claude Code: What the Code Shows
• Postman Desktop Silently Installs Plugins Into Codex, Claude Code