Postman's Desktop App Installed Plugins Into Claude Code and Codex Without Asking. Here Is the Five-Minute Audit of Your Agent Config.
On October 25, a developer opened issue #14370 on Postman's public tracker with a title that starts with "[SEVERE]": the desktop app had installed plugins into Codex and Claude Code on its own, and the installer appeared to mark its own startup hook as trusted. The issue has since collected coverage and a reply from someone at Postman. If you use either agent and have Postman on the same machine, you can check your own setup in about five minutes.
What the issue reports
The reporter was running Postman Desktop 12.33.4 on a Mac. Postman's own log shows an install on October 24 at 09:34 UTC, with the source labeled "auto-existing-upgrade" and the results "claude-code:installed" and "codex:installed". From that, the reporter lists what changed on disk: a Codex marketplace entry pointing at the postmanlabs/postman-plugin repo, the Postman plugin enabled in ~/.codex/config.toml, trusted hash entries for a SessionStart hook, a remote MCP connection to mcp.postman.com, the Postman plugin enabled in Claude Code, and a Postman CLI binary in ~/.local/bin.
The hook is the part that matters. It runs at session start, on startup, clear and compact, and injects an instruction telling the agent to load a Postman API skill for "non-trivial API engineering tasks". That means a plugin you never chose gets to put text in front of your agent at the start of every session.
What the issue does not show
The reporter is careful here, and I want to be too. The issue does not document any user data leaving the machine. The only external endpoint named is the MCP server, and the Codex log shows it failing with "Auth required". The reporter also says the sequence was seen on one Mac and not yet reproduced on a clean machine, and notes that the trust record alone does not prove who created it.
Some headlines have been stronger than the issue. One aggregator title says Postman "attempts to share all API data". Nothing in the report supports that. What it does support is narrower and still worth your attention: an installed app wrote to your agent configuration without a prompt.
Postman's answer so far
A dev.to write-up says a reply was posted in the issue thread on November 3. It says the CLI and agent plugins are bundled to help users set them up, that Postman will make the opt-in clearer for existing users, that it is reviewing the hook approval and session-start behavior, and that components can be uninstalled from inside the app. The same write-up says the poster's profile lists no company, so I could not confirm that the reply is official. It also reports a commenter who saw the same install when updating from 12.31.3 to 12.35.1, which suggests it was not one build.
None of that says the auto-install stops. A promise of clearer opt-in is not the same thing as default off.
The five-minute audit
These are read-only. Run them on any machine where Postman desktop is installed.
grep -n -i postman ~/.codex/config.toml grep -n -i postman ~/.claude/settings.json claude plugin list ls -l ~/.local/bin | grep -i postman
If the first command shows a marketplace entry, a plugin block or hook hashes you did not add, you have the install the issue describes. In Claude Code, claude plugin disable postman@claude-plugins-official turns it off and claude plugin uninstall removes it. In Codex, /hooks inside a session lets you disable the SessionStart hook. Postman documents a remover, npx @postman/postman-plugin remove, but I have not run it and I could not tell whether it clears the Codex trust record, so run the grep again afterward. Removing the desktop app by itself may leave these entries behind.
What I'd actually do
I would run the audit today, and then put the two config files somewhere I can see changes. A plain git repo around ~/.codex and ~/.claude (minus anything secret) is enough: git diff after any app update tells you what that app touched. That habit costs nothing and works for the next app that does this, not just Postman.
I would also stop thinking of agent config as personal preferences. A hook that runs at session start has the same position as a shell profile. If a desktop app can edit it, so can anything that compromises that app. I keep API keys out of agent sessions where I can, and this is why.
Where I could be wrong
This is one reporter, one Mac, and a reply I could not verify. Postman may fix it quickly, and an opt-in prompt may already be on the way. It is also possible that the plugin is useful to many Postman users and the real failure is only the missing consent step. I would not uninstall Postman over this. I would uninstall the plugin if you did not ask for it.
Author
Lukas
@lukcombinator