Problem Solutions
Postman Installed Its AI Plugin Into Codex and Claude Code Without Asking: How to Check and Remove It
Opening Postman on a Mac did more than open Postman. According to GitHub issue 14370, filed against Postman's app-support tracker on October 25, the desktop app's own logs show an auto-existing-upgrade step that installed Postman components into two coding agents, Anthropic's Claude Code and OpenAI's Codex, without an explicit request. The story hit the Hacker News front page on November 5, passing 650 points and 200 comments in about three hours.
What makes the report hard to dismiss is the evidence. The reporter preserved Postman's own log lines, pinned the exact plugin revision, and read the installer source. The issue is careful about what it proves and what it does not, and that care is part of why it spread: this is a consent and trust-boundary failure, documented unusually well, not a rumor.
What the logs show
The reporter opened Postman 12.33.4 on macOS on October 24, after not using it for a while. Postman's own log, at ~/Library/Application Support/Postman/logs/main.log, recorded two lines at 09:34 UTC: PostmanAgentPluginService~install: script completed, with a result object reading source auto-existing-upgrade and results claude-code:installed and codex:installed, followed by Main: autoInstall.plugin.existing-user finished. The words that matter are auto-existing-upgrade. This was not a user clicking install plugin. It was an upgrade path for an existing desktop user, firing on open, that reached into two unrelated tools.
The changes listed in the report are specific. Codex's global ~/.codex/config.toml gained a marketplaces.postman git source and an enabled postman@postman plugin, plus a hooks state entry. Claude Code's ~/.claude/settings.json enabled postman@claude-plugins-official at version 2.0.1, at user scope. A Postman executable appeared in ~/.local/bin, and a remote MCP endpoint was configured at https://mcp.postman.com/mcp.
The hook that approved itself
The detail that earned the issue its SEVERE tag is the startup hook. The installed hook fires at session start and prints a context file instructing the agent that before any non-trivial API engineering task, it should load the postman:api-engineer skill and follow it. That instruction now sits in front of every API task the agent runs, whether or not the user asked for Postman.
Worse, the installer appears to approve its own hook. The installer source, at the exact revision the reporter pinned, exports a function called approvePostmanHook, which queries Codex's hooks/list, reads the installed session-start file to confirm it is present, then calls config/batchWrite to upsert hooks.state with the hook's trusted_hash. Postman's own plugin README states the quiet part plainly: for Codex, installation also approves Postman's session-start hook. A trust prompt the vendor answers for you is not a trust prompt.
What it does not show
What the evidence does not show is equally important. There is no confirmed proof in the thread that customer API data was exfiltrated. The remote MCP connection failed authentication, with Codex logging Auth required, and later comments in the thread say there was no evidence that data was uploaded. The reporter writes that the report establishes unwanted integration and instruction changes, and explicitly does not claim to establish data exfiltration. The Hacker News headline saying Postman attempts to share all API data overstates what the issue itself claims.
Three caveats also apply. This is a single reporter's machine, and the reporter is careful to say the sequence has not yet been reproduced on a clean Mac. The log shows a signed-in user, so whether a signed-out user would see the same behavior is untested. And a second user in the same issue reports the same behavior on an update from 12.31.3 to 12.35.1, with the fresh-install check logging skipped-not-fresh, so the newer version still runs it, while a comment notes a feature flag decides whether the automatic install fires.
What Postman said
On November 3, an account replying for Postman said the team would make the opt-in clearer, especially for existing users, and is reviewing the hook approval and session-start behavior. The company said bundling was meant to make the CLI and plugins easier to set up. As of November 5, the issue is open and Postman has published no switch for the auto-install.
How to check and remove it
Check first, before removing anything. Run grep -n -i postman ~/.codex/config.toml ~/.claude/settings.json ~/.claude.json and look for a marketplaces.postman section, an enabled postman plugin, and any trusted_hash record. Check ~/.local/bin for a Postman executable, and watch whether Codex keeps reporting that an MCP server needs sign-in or keeps loading Postman skills for API tasks.
To remove it, use the desktop app: Help, then Postman CLI and Plugins, then Uninstall Postman Coding Agent Plugin. Or run npx @postman/postman-plugin remove, which uninstalls the plugin from both agents. One trap, confirmed by a November 4 reproduction: the official removal command leaves the Codex marketplace entry and the trusted_hash record in config.toml. You have to remove those by hand. After removal, re-run the grep and confirm nothing Postman remains in either config, and check that no session-start hook still injects Postman's instructions into your agents.