AI AutomationWorkflow Design

Postman added itself to Claude Code. Here's the 4-file check.

·5 min read

If you use Claude Code or Codex and you also have Postman installed, this one is worth five minutes today.

A GitHub issue on Postman's tracker says the desktop app installed plugins into both coding agents without asking. The Hacker News thread about it passed 1,000 points on Nov 3, and the headline there made it sound worse than the issue itself. So here is the version with the sources attached.

What the issue says

The report is issue #14370 on postmanlabs/postman-app-support, opened on Oct 25, 2026 by a user called indicava. It is titled "[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook." It was written about Postman desktop 12.33.4 on a Mac.

The reporter noticed odd behavior in their coding agents: repeated MCP authentication warnings, and Codex steering API work toward Postman skills. They went looking and found this:

  1. Postman's own log says it installed the plugins. In main.log, timestamp 2026-10-24T09:34:14Z, the entry has "source":"auto-existing-upgrade" and results claude-code:installed and codex:installed.
  2. A Claude Code plugin (version 2.0.1) and a Codex plugin (1.1.0) were enabled, plus a separate Postman CLI in ~/.local/bin.
  3. A startup hook. The Codex plugin registers a SessionStart hook that prints an instruction telling the agent to load the postman:api-engineer skill and follow it before any non-trivial API engineering task.
  4. A self-approved hook. The installer source calls a function named approvePostmanHook, which writes a trusted_hash for the hook into ~/.codex/config.toml. The reporter is careful here: the source shows the approval attempt, but the trust record alone doesn't prove who created that specific record.
  5. A remote MCP entry pointing at https://mcp.postman.com/mcp, which logged "Auth required."

A later commenter posted a log with the same auto-existing-upgrade trigger on Nov 3, after updating from 12.31.3 to 12.35.1. The reporter says they have not reproduced it on a clean Mac, so treat the exact trigger as reported, not settled.

What it does not say

The Hacker News title says Postman "attempts to share all API data." The issue doesn't say that. Its own words: it "does not claim to establish data exfiltration." There is no evidence in the report that any API data was uploaded.

What the report does show is a different problem. An app you opened to send API requests changed the setup of two other tools, and one of those changes was an instruction your agent reads at the start of every session. That is a consent problem even if no data moved anywhere.

What Postman said

On Nov 3 a Postman representative replied in the thread that the company bundles the Postman CLI and the agent plugins with the desktop app. They said the opt-in will be made clearer, especially for existing users, and that the hook approval and session-start behavior are under review. They also said you can uninstall each component from inside the app.

RuntimeWire reports the same statement from Postman's head of product, Sarabmeet Kallar. Neither source gives a date for any change, and as of today the issue is still open.

The 4-file check

These are the locations named in the report. They are macOS paths from the reporter's machine, so on Windows or Linux the folders may differ. I haven't verified other platforms.

# 1. Claude Code settings: is the Postman plugin enabled?
grep -n postman ~/.claude/settings.json

# 2. Claude Code's plugin record: version, install time
grep -n -A4 postman ~/.claude/plugins/installed_plugins.json

# 3. Codex config: the plugin, plus any hook trust entry
grep -n postman ~/.codex/config.toml

# 4. The Postman CLI it installed
ls -l ~/.local/bin | grep -i postman

What to look for:

  • In file 1, an entry named postman@claude-plugins-official.
  • In file 2, the same name, with an installedAt date that matches a day you opened Postman and not a day you installed anything.
  • In file 3, a [plugins."postman@postman"] block, and a [hooks.state."postman@postman:..."] block with a trusted_hash.
  • In file 4, a postman executable you don't remember adding.

One more place, from the report: a commenter says a postman@postman entry also showed up in ~/.copilot/settings.json, and that uninstalling from inside Postman did not remove that one. Check it by hand if you use Copilot.

If you want to see when it happened, the reporter's log lives at ~/Library/Application Support/Postman/logs/main.log. Search it for auto-existing-upgrade.

How to remove it

The thread's own answer is to do it inside Postman: Help, then Postman CLI and Plugins, then Uninstall Postman Coding Agent Plugin. After that, run the four checks again. Anything still listed can be removed by hand, but back up the file first, because settings.json and config.toml hold your other settings too.

What to do this week

  • Run the four checks on every machine where you use Postman and a coding agent.
  • Add a habit to your agent setup: look at the plugin and hook list after you install or update any desktop developer tool, not only when you add a plugin yourself.
  • If a hook you didn't write is in your config, read what it tells your agent to do. A startup instruction is the part that changes behavior every session.
  • Keep the two claims apart when you talk about this. The auto-install is documented with logs and source links. Data sharing is not.

My own view: a tool that edits another tool's instructions should ask first, every time. That is the whole ask in the issue, and Postman has said it will make the opt-in clearer.

Which of the four files had something in it on your machine?

Sources