Postman installed itself into Claude Code and Codex. Who else can?

On 24 October, a developer opened the Postman desktop app on their Mac. Without a prompt, it installed a Postman plugin into both Codex and Claude Code, dropped a Postman command line tool into ~/.local/bin, and pointed the agents at Postman's MCP server. The developer found it in Postman's own log, which recorded the trigger as auto-existing-upgrade, and filed a GitHub issue marked “SEVERE” the next day.

Nothing in the reports suggests stolen data. But the story is worth ten minutes of any team lead's time, because it shows how easily a normal desktop app can change what your coding agents do, and how few people would notice.

What was changed

According to the issue, Postman 12.33.4 made these changes in the user's home directory:

• Codex: a Postman plugin marketplace and an enabled postman@postman plugin in ~/.codex/config.toml.
• Claude Code: the Postman plugin enabled in ~/.claude/settings.json and recorded in ~/.claude/plugins/installed_plugins.json.
• A startup hook that tells the agent, before “any non-trivial API engineering task”, to load Postman's api-engineer skill. That covers most API work, not only requests that mention Postman.

Later comments in the thread report the same behavior on newer versions, and find Postman plugins in Cursor and GitHub Copilot's settings too. One commenter says the uninstall option in Postman's Help menu did not remove it from Copilot.

The most serious claim is about trust. Codex asks the user to approve third-party hooks before they run. The reporter points to a function in Postman's installer, approvePostmanHook, that writes the hook's trusted hash into Codex's state right after installing it, which would answer that prompt on the user's behalf. The reporter is careful to say the source code shows the attempt but does not prove what created the trust record on their machine, and another commenter reports that their Codex version still required consent. So treat this part as alleged, not established.

Postman's response

There is no official reply in the GitHub thread. Postman's head of product told RuntimeWire on 3 November that the company will make the opt-in for its AI coding agent plugins clearer, especially for existing users, and that it is reviewing the hook approval and session-start behavior. No timeline was given. Developer Frank Chu notes that no independent party has yet reproduced the behavior on a clean machine.

Why this matters more than one vendor

Coding agents read their configuration from a handful of plain files in your home directory. Any program you run as yourself can edit them. What those files control is powerful: which tools the agent can call, which servers it talks to, and which instructions it reads before every task. A line added there changes the behavior of every future session, quietly, and survives long after the app that wrote it is closed.

Postman is a well-known company with a plausible reason to integrate with agents. The next app to do this may not be. And because the change lives in config rather than code, it never shows up in a pull request, a dependency scan or a code review.

Check your machines

1. Look for Postman entries. On macOS or Linux:

   grep -il postman ~/.codex/config.toml ~/.claude/settings.json \
     ~/.claude/plugins/installed_plugins.json ~/.copilot/settings.json 2>/dev/null
   ls ~/.local/bin | grep -i postman

   If you didn't choose to install it, remove the plugin with each agent's own plugin commands and delete the entries that remain.
2. List every plugin, hook and MCP server. Open those files and read them once. For each entry, ask whether someone on the team chose it. Most people will find at least one surprise.
3. Check hook trust. If you use Codex, look for trusted_hash entries in ~/.codex/config.toml that you don't remember approving.

Make agent config something you review

• Put the team's setup in the repository. Project-level config, such as a committed .mcp.json or project settings file, goes through review like code. Keep personal config for personal preferences.
• Treat agent config like a shell profile. A line added to ~/.zshrc by an installer would worry you. A line added to ~/.claude/settings.json deserves the same reaction.
• Watch the files. Endpoint tools and even a simple file-integrity check can alert when an agent's config changes outside a known update.
• Prefer explicit opt-in. When choosing tools, favor vendors whose agent integrations you turn on yourself, and say so when you give feedback.

The takeaway

This week it was a popular API tool with a product reason and, as far as anyone knows, no bad intent. The lesson stands either way: the files that steer your coding agents are now part of your attack surface and your team's working agreements. Read them, keep the shared parts in the repo, and notice when something else writes to them.

Sources: postmanlabs/postman-app-support issue #14370 (opened 25 October 2026), RuntimeWire (3 November 2026), Frank Chu on dev.to (3 November 2026).