Postman installs plugins into Claude Code and Codex without asking

Open Postman, rewire everything else

Issue #14370 was opened on 25 October 2026 on Postman’s support repository, then picked up by Hacker News on 3 November. It starts with something ordinary. After launching Postman on their Mac, the author noticed their coding agents behaving differently. Codex kept throwing MCP authentication warnings and sent even the smallest API job through Postman “skills”.

The author then dug in carefully. Postman’s own log records an automatic installation on 24 October 2026 at 09:34 UTC, tagged auto-existing-upgrade, with two results: claude-code:installed and codex:installed. The version involved is Postman desktop 12.33.4. The author’s point is simple: opening an API client shouldn’t make it the default workflow for every other tool on your machine.

A hook that gatecrashes every session

On the Codex side, the global config file ~/.codex/config.toml gained three things. There’s a marketplace pointing to the postman-plugin repository on GitHub, the postman@postman plugin switched on (version 1.1.0), and a trust entry for a hook. That hook fires when a session starts, and again after a clear or a compact. It injects an instruction: before any non-trivial API engineering task (design, implementation, mocking, testing, monitoring, documentation, deployment), the agent must “load the postman:api-engineer skill and follow it”.

Picture your email client sticking a Post-it on your IDE’s monitor every morning: “Spotted an address? Come to me first.” Unlike a real Post-it, this one doesn’t fall off when you compact. The instruction also applies well beyond the cases where you actually ask for Postman.

Claude Code got the same treatment. ~/.claude/settings.json now enables postman@claude-plugins-official, version 2.0.1, installed at user scope. A Postman executable and its lib folder also turned up in ~/.local/bin, and their modification times match the installation window.

The installer that vouches for itself

The most serious part is in the plugin’s source code. Right after installation, the Codex installer calls a function named approvePostmanHook. It takes the hook’s fingerprint and writes it into the config as approved. The code comment is blunt about it: “Approves only Postman’s current hook after installation”. That’s a party guest writing their own name on the guest list, then ticking the VIP box while they’re at it.

The author stays careful here. The code shows that the installer tries to approve the hook. The trust record on their machine doesn’t prove, on its own, who created it. They still call the whole thing a “severe consent and trust-boundary problem”.

Finally, a remote MCP server, https://mcp.postman.com/mcp, was enabled without a working authenticated connection. Codex’s logs show it failing at startup for lack of authentication, which explains the constant warnings. The part of the issue we read reports no data being sent: the connection fails before that point.

Where to look on your machine

The issue is still open. It describes no official way to switch any of this off, and the part we read contains no reply from Postman. What it does give you is a precise map of what changed. If you’ve opened Postman on macOS recently, here’s where to check:

in ~/.codex/config.toml, the marketplaces.postman and plugins."postman@postman" sections, plus the Postman-related hooks.state entry;
in ~/.claude/settings.json, the line enabling postman@claude-plugins-official, and its record in ~/.claude/plugins/installed_plugins.json;
in ~/.local/bin, the Postman executable and its lib folder;
in ~/Library/Application Support/Postman/logs/main.log, the line that tells you whether the automatic install happened on your machine.