Postman quietly installed itself into Codex and Claude Code, then tried to approve its own hook
Your API client now has opinions about how your coding agent should work. A GitHub issue against Postman's desktop app hit 831 points on Hacker News Tuesday, the top story of the day, and the evidence in it is unusually tidy.
The reporter opened Postman on a Mac and started seeing MCP auth warnings and Codex routing API work through Postman skills. Postman's own log has the line: source auto-existing-upgrade, results claude-code installed, codex installed. So existing users got it as an upgrade. The global Codex config gained a Postman marketplace, an enabled plugin and a trusted hash for a session-start hook. That hook tells the agent, before any non-trivial API task, to load a Postman skill and follow it. And the installer source in the public plugin repo has a routine that approves Postman's own hook, with a source comment saying it approves only Postman's current hook after installation.
Be careful with the viral version. The HN headline says Postman "attempts to share all API data". The issue does not say that, and the reporter writes that it does not claim to establish data exfiltration. It is one Mac on version 12.33.4, not yet reproduced on a clean machine. One commenter says Codex and Claude Code both raised alerts, so the self-approval may not have gone through; that is a comment, not a test. Another says Postman changed its web page afterward; we did not verify that. As of Tuesday night none of the 23 comments came from an account marked as a project member, and we found no Postman statement.
The consent question stands even on the narrow facts. An instruction hook is a prompt injection with a nice install path: text that runs at every session start and steers which tools your agent reaches for. Agent config files are becoming the most valuable real estate on a developer's machine, and a vendor with a desktop updater can walk right in. Hook trust exists to stop exactly that, so an installer writing its own trust record is the line to watch, whoever crosses it next.
A paper out the same day shows how little the framework protects you here. mcpvenom, accepted at AISec '26, tested tool poisoning across 9,720 combinations of 12 frameworks, 18 models and 45 scenarios. Overall success was 22.9%. Nine core frameworks cluster within 23 to 26%, while models range from 0.4% to 49.7%, so the model is doing the defending. The authors say no framework implements intentional defense and all five coordinated disclosures, across four vendors, were rejected.
Worth doing today if you run Postman: read ~/.codex/config.toml and your Claude Code settings, and look for anything you did not add.
Issue: https://github.com/postmanlabs/postman-app-support/issues/14370 Plugin repo: https://github.com/postmanlabs/postman-plugin mcpvenom: https://arxiv.org/abs/2611.03555
← Back to all articles
The reporter opened Postman on a Mac and started seeing MCP auth warnings and Codex routing API work through Postman skills. Postman's own log has the line: source auto-existing-upgrade, results claude-code installed, codex installed. So existing users got it as an upgrade. The global Codex config gained a Postman marketplace, an enabled plugin and a trusted hash for a session-start hook. That hook tells the agent, before any non-trivial API task, to load a Postman skill and follow it. And the installer source in the public plugin repo has a routine that approves Postman's own hook, with a source comment saying it approves only Postman's current hook after installation.
Be careful with the viral version. The HN headline says Postman "attempts to share all API data". The issue does not say that, and the reporter writes that it does not claim to establish data exfiltration. It is one Mac on version 12.33.4, not yet reproduced on a clean machine. One commenter says Codex and Claude Code both raised alerts, so the self-approval may not have gone through; that is a comment, not a test. Another says Postman changed its web page afterward; we did not verify that. As of Tuesday night none of the 23 comments came from an account marked as a project member, and we found no Postman statement.
The consent question stands even on the narrow facts. An instruction hook is a prompt injection with a nice install path: text that runs at every session start and steers which tools your agent reaches for. Agent config files are becoming the most valuable real estate on a developer's machine, and a vendor with a desktop updater can walk right in. Hook trust exists to stop exactly that, so an installer writing its own trust record is the line to watch, whoever crosses it next.
A paper out the same day shows how little the framework protects you here. mcpvenom, accepted at AISec '26, tested tool poisoning across 9,720 combinations of 12 frameworks, 18 models and 45 scenarios. Overall success was 22.9%. Nine core frameworks cluster within 23 to 26%, while models range from 0.4% to 49.7%, so the model is doing the defending. The authors say no framework implements intentional defense and all five coordinated disclosures, across four vendors, were rejected.
Worth doing today if you run Postman: read ~/.codex/config.toml and your Claude Code settings, and look for anything you did not add.
Issue: https://github.com/postmanlabs/postman-app-support/issues/14370 Plugin repo: https://github.com/postmanlabs/postman-plugin mcpvenom: https://arxiv.org/abs/2611.03555
Comments