Postman Silently Rewrites Codex and Claude Code Configs: Six Evidence Chains From a SEVERE Issue
A tool holding production API credentials demonstrably rewrites other vendors' agent configurations without consent, breaking the trust boundary developer tools rely on. With agents gaining broader permissions, a silent auto-install like this turns every API key on the machine into a potential remote-routing liability.
A SEVERE issue on postmanlabs/postman-app-support documents a macOS investigation where a single open of Postman desktop v12.33.4 modified both Codex and Claude Code without any user interaction. Postman's own main.log records an "auto-existing-upgrade" event that installed plugins into both agents, rewrote global config files, added a standalone CLI to ~/.local/bin, and configured a remote MCP connection to mcp.postman.com. The installer even writes its own trusted_hash into the hook trust configuration, defeating the user-approval gate.
The evidence chain is unusually strong: file timestamps all fall within the same minute as the client launch, and the log lines come from Postman's own process. The issue author is careful to separate confirmed facts — installation, config rewrites, hook injection, self-approval code path — from unproven fears. The remote MCP failed authentication in this instance, so no data exfiltration is established. Still, a client holding real API credentials that silently rewrites other vendors' agents raises a supply chain question: once a vendor demonstrates it will override consent boundaries, every credential on that machine sits one auth step away from a remote server.
Writing your own trusted_hash into a hook trust mechanism annuls the user's approval gate; the gate only works if the installer cannot fill it in.
Open plugin systems assume installers respect user authorization flows; a vendor exploiting that assumption turns an extension point into a silent supply chain vector.
The strongest part of the evidence is that it comes from Postman's own log and file system timestamps, not from third-party monitoring, making the factual basis nearly irrefutable.
Separating confirmed changes from unproven data leakage is what keeps the report credible; overclaiming would hand the vendor an easy counterattack.