Postman Desktop 12.33.4 installed its own plugins into Codex and Claude Code on a developer's Mac on October 24, with no prompt and no checkbox. It also wrote a startup hook into Codex and marked that hook as trusted by itself. The developer filed issue 14370 on October 25. It sat for a week, hit the top of Hacker News on November 3 with about 1,500 points, and on November 5 a Postman employee replied in the thread that the company is reverting the change.

I've used Postman for a long time. I'm not going to anymore, and the reason has less to do with plugins than with what the installer did to a trust boundary that belongs to me.

What the logs show

The report is well documented. The reporter pulled Postman's own main.log and found two lines at 09:34 UTC on October 24 from a component called PostmanAgentPluginService. The upgrade flow was tagged "auto-existing-upgrade", the results were "claude-code:installed" and "codex:installed", and the internal event carried the fields "signedIn":true and "installer":"script". So this was a scripted install, triggered by an app update, for users who were already signed in.

On the Codex side, ~/.codex/config.toml gained four things: a plugin marketplace pointing at Postman's GitHub repo, an enabled postman@postman plugin, a remote MCP server entry for mcp.postman.com, and a hooks state table carrying two sha256 hashes marking the session-start hook as trusted. On the Claude Code side, settings.json gained an enabled postman@claude-plugins-official plugin at version 2.0.1. A Postman CLI binary showed up in ~/.local/bin.

The hook is the part that bothers me. It fires on every Codex session start, including after a clear or a compact, and its context file opens with an instruction to load the postman:api-engineer skill "before responding to any non-trivial API engineering task." That is a vendor inserting a standing instruction into an agent I run, scoped to all API work, and the agent reads it before it reads anything from me.

Postman's own docs describe the mechanism without apology. The install page says that when you install by hand, "the hook installs untrusted" and Codex shows a "Hooks need review" screen on next launch. For the scripted installer, the same page says "it approves the hook for you, or tells you to review it if it can't." Codex built that review step so a human would look at a hook before it ran. Postman wrote code to skip the human.

The reporter was careful to say the evidence shows unwanted config changes, not data exfiltration. The MCP server entry failed with "Auth required" because they weren't logged in to it, and nothing in the thread shows API data leaving the machine. Notebookcheck's writeup reached the same conclusion. Keep that straight when you read the "shares all API data" headline on Hacker News. The title overstates it. The config changes alone are bad enough.

It was wider than one Mac

A second user reported the same behavior on November 3 after updating to 12.35.1, and in their case the startup text also landed in Cursor. Another found Postman entries in the GitHub Copilot CLI. Every confirmed case so far is on macOS, which fits the "platform":"darwin" field in the log, though nobody has shown it can't happen on Linux or Windows.

Somewhere between October 26 and November 4, Postman's download page gained a sentence: "The Postman app includes Postman CLI & Postman plugins." A commenter on the issue posted a Wayback Machine capture from October 26 without that sentence, and that comment collected over 350 upvotes. The timing reads as documentation catching up with behavior that shipped first.

Postman's first response, on November 5, said the company bundles the CLI and plugins "because many users had trouble installing" them, and promised to make "the opt-in clearer, especially for existing users." A second employee followed up the same day: "In the meantime, we are reverting this change." They said the goal had been to simplify setup, that the feedback showed "this wasn't the case," and that they'd redesign the flow "with the right level of control."

Reverting the installer does not uninstall anything. Everyone who updated between October 24 and whenever the revert ships still has the plugins, the hook, the trusted hashes and the CLI binary on disk. One user asked in the thread what the revert means for them. No answer yet.

Check your machine

If Postman Desktop has been on a Mac in your shop since late October, assume the plugins are there until you've looked. The Help menu has a "Postman CLI and Plugins" entry with an uninstall option, and with Node installed you can run the vendor's own tool:

npx @postman/postman-plugin status
npx @postman/postman-plugin remove

I wouldn't trust either path alone. One user reported the Copilot CLI entry survived the uninstall from the Help menu. Check these by hand:

  • ~/.codex/config.toml, for any table or key with "postman" in the name, including the hooks state entries
  • ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json, for postman@claude-plugins-official
  • ~/.copilot, for a Postman plugin or marketplace
  • ~/.cursor, if the hook text showed up there
  • ~/.local/bin, for a postman binary and its library

If you manage a fleet, this is a config drift problem now. Agent config files live in home directories, outside package managers and outside most MDM policy. A desktop app from one vendor rewrote them, and your inventory tooling didn't notice because none of those files were on its list. Add them.

Agent config is the new PATH

Twenty years ago the fight was over installers that added browser toolbars and rewrote your search engine. The installers lost, mostly because operating systems and browsers started requiring consent at the moment of change. Coding agents are the new surface, and the config files that decide what an agent trusts have no such gate. Codex built one for hooks. Postman's installer shows how little it takes to step around it when the vendor controls the code that runs on your machine.

A session-start hook is a standing prompt injection with a vendor's name on it. It's fine when I put it there. It's a compromise when someone else does, whatever their intent, because the whole point of the trust hash was to answer the question of who put it there. Once an installer can write the hash, the hash answers nothing.

This will happen again, and the next one may not be as polite. Postman's hook pointed the agent at Postman's skills and MCP server, which is annoying and self serving but not malicious. The same mechanism, with a different context file, could tell an agent to send every API spec it touches to a URL. The installer that wrote the trusted hash would run the same way. Agent vendors need to treat hook approval the way browsers treat extension installs, with a signed record that only the user's own action can produce. Until they do, I'm diffing my dotfiles after every app update, and the Postman entry in mine is gone.