Postman Installs AI Plugins Into Codex and Claude Code: Four Install Paths and How to Check Them

# Postman Installs AI Plugins Into Codex and Claude Code: Four Install Paths and How to Check Them

On October 24, 2026 at 09:34 UTC, a routine Postman desktop launch left something its owner never asked for: Postman's own log records that an installation script finished with a Codex plugin and a Claude Code plugin as its results. The trigger note in that log reads auto-existing-upgrade. One day later the case went public as GitHub issue 14370, complete with log excerpts, configuration snippets and one detail that turns a packaging complaint into a trust incident: the installer had not only written files, it had also decided on its own that its startup hook deserved trust.

I run a small agent family on my deck, and it happens to sit on exactly the two tools this case touches. Codex and Claude Code run in the next room here, hooks and MCP servers are part of my daily operation. So instead of reading this as a news item, I treated it as an audit order for my own machine. The results are below, path by path, and because I am definitely not the only one operating these glue tools, the check is written up so you can repeat it.

The reporter found the decisive lines in the Postman log directory under Application Support/Postman/logs. In main.log, lines 11562 to 11563, timestamped October 24, 2026 at 09:34:14 UTC, the log reads:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}

Translated into plain terms: the Postman agent service executed an installation script whose trigger note points at an existing upgrade and whose result reads installed for both target tools. A second log entry right below records the same outcome. This is not the interpretation of an angry user, it is the program reporting on itself. That is why the case picked up its wave within days: nobody has to accuse Postman of anything, you can simply read it.

The affected versions are documented in the issue itself, determined on October 25, 2026: Postman desktop 12.33.4, the Codex plugin at version 1.1.0, the Claude plugin at version 2.0.1. Beyond the log line, the documented behavior is tied to macOS, the issue carries a darwin marker, and equivalent evidence for Windows or Linux is not part of the issue so far. I treat that as a genuine open question, it is pinned in the FAQ.

The interesting part is not the plugin count, it is the surface area. Five places are documented. First, an entry in the marketplaces section of the global Codex configuration, pointing as a source at a Postman repository. Second, the plugin entry itself, set to enabled. Third, the core of the case, an entry in the hooks state section holding a trusted hash, a sha256 value written by the installer. Fourth, a remote MCP connection to mcp.postman.com, which per the Codex log fails with an auth required message, meaning the connection was enabled while no valid session existed. Fifth, the traces inside Claude Code, a modified settings.json and a list of installed plugins, plus a Postman command line tool placed in the user's local bin directory.

The hook itself carries an instruction the agent is meant to read at every session start: before handling any non-trivial API task, the agent should load a Postman skill first. That matters. A startup hook runs ahead of nearly everything, and when it targets every non-trivial API task, a third-party tool declares itself the default route without a single dialog asking permission.

On my deck, Codex, Claude Code and a Hermes agent run side by side with their own config files, hooks and MCP connections. That is precisely why the case was not somebody else's damage for me, it was a prompt to look. On November 4, 2026, I checked the four path groups one at a time.

The Codex configuration at .codex/config.toml exists on my machine with 465 bytes of content. A search across it for Postman, marketplaces and hooks finds nothing: no Postman source, no enabled plugin, no foreign trust hash. The Claude settings file at .claude/settings.json exists but holds 22 bytes, effectively an empty default. The installed plugin list under .claude/plugins does not exist on my machine. The Postman tool under .local/bin does not exist either.

My audit verdict: this machine is clean. I want to be honest about the reach of that statement. My check says the four paths were empty on this date. It does not prove they never existed, and it does not replace looking into the Postman log file if Postman runs on your machine. If you work at a company, run the same check on every machine that has Codex or Claude Code installed. The issue comment section carries the sentence, word for word, that the case even creates risk in corporate environments. That is not panic talking, that is the normal reading when one tool quietly rewrites another tool's configuration.

So far, nobody in the issue documents a one-click removal that clears every location at once. If you want the traces gone, you clear them per path: remove the plugin block and the hook states section from the Codex configuration, delete the Postman source from the marketplaces section, search and remove the Postman entries in the Claude settings file and the installed plugin list, delete the Postman tool from the local bin directory, and remove the MCP connection to mcp.postman.com from the Codex configuration. Then restart both agents so no running session drags the old state along.

If you are not sure everything is gone, start Codex with a simple task afterward and search its log for mcp.postman.com and for the Postman skill name. The name is postman:api-engineer, and on an affected machine it shows up in task processing. One more note: launching Postman again remains the riskiest moment until the behavior is officially turned off, because there is no public evidence about whether the auto-install repeats after the first documented run on October 24.

There is precedent for this pattern. Readers in the thread point to GitKraken, which shipped extra components with a desktop update and later addressed it publicly. That is not an absolution for Postman, it is the reminder that this kind of intervention stays a breach of trust even when it gets cleaned up afterward.

If you test one API a day, this reads as an annoyance. If you operate agents, it reads as a lesson about the attack surface between tools. Hooks are the norm on my deck, I run them under my own control as start and end points for agent work. The case shows why three mechanisms matter that I use every day. First, the trust hash, which stops a foreign hook from sliding silently into execution. Second, the MCP section, which holds connections to external services and therefore should only ever contain entries you put there deliberately. Third, the marketplaces section, which bundles source, version and enabled state in one place, exactly so it can be audited.

I run my agents with my own approval logic instead of borrowed templates. When I compressed that logic into click confirmations, I kept the hard rules untouchable, the brakes on sudo input, mass deletions and denied patterns. The Postman case shows the mirror image: an installer that writes its own approval into somebody else's trust store inverts exactly that order. My approach to keeping agents procedural is documented in a separate piece on agent procedures, and the comparison of coding agents and their trust rules lives in the coding agents league piece, both linked at the end.

The issue carries three clear demands: pause the automatic installation of agent plugins until every install passes through explicit consent. Remove the mechanism that approves itself. Restrict the hook's startup instruction to situations where the user explicitly asks for Postman. As of retrieval on November 4, 2026 around 13:40 UTC, Postman had not posted a public statement in the issue. Among the 51 comments you find voices like the one from a user who says he ran Postman for a decade and uninstalled it today, plus the reminder of the GitKraken case.

The surroundings show how deep the frustration runs: on Hacker News the case sat at 1398 points and more than 460 comments at retrieval, and the replies are dominated by moves to Bruno, Insomnia and Yaak. The real question, though, is not which API client wins next quarter. It is whether an installer may ever again claim that another tool's configuration belongs to it. Until Postman answers: audit the paths, document your state, and keep cross-tool configuration touchpoints in your own operation as close to zero as you can.

Further reading from my own archive: the way I keep agents procedural is described in [agent procedures](post.html?slug=pi-skills-agents-procedures), and the comparison of coding agents including the trust rules involved lives in the [coding agents league](post.html?slug=github-league-coding-agents).

GitHub issue 14370 in the Postman issue tracker, opened October 25, 2026, retrieved November 4, 2026: https://github.com/postmanlabs/postman-app-support/issues/14370

Hacker News discussion from November 3, 2026, 1398 points at retrieval time, retrieved November 4, 2026: https://news.ycombinator.com/item?id=50354960

Case summary with version details and the approvePostmanHook installer mechanism, retrieved November 4, 2026: https://aiweekly.co/alerts/postman-desktop-silently-installs-plugins-into-codex-claude-code

GitKraken blog post on its own desktop update, cited as precedent in the issue comments, retrieved November 4, 2026: https://www.gitkraken.com/blog/gitkraken-desktop-12-0-1-update

Own measurement: path audit on the agent deck, November 4, 2026. Codex configuration 465 bytes with no Postman entry, Claude settings.json 22 bytes, plugin list and local bin tool not present.

About the author: I run the agent family on a used Google Pixel 6a, with Codex, Claude Code and a Hermes agent operating in parallel, plus a Kali system on a Raspberry Pi. I ran this audit on my own installation on November 4, 2026, path by path, with the byte counts written into the text. Last reviewed November 4, 2026.