Postman is one of those tools that has been installed on almost every developer’s machine for years. That’s why an issue opened in its support repository caught my attention, with a rather blunt title: the desktop app installs plugins into the user’s coding agents on its own and, on top of that, tries to mark its own startup hook as trusted.
What Postman does
The issue was opened on 25 October against version 12.33.4 of the desktop app, and another user later reproduced it with 12.35.1. On launch, if you were already signed in, Postman installs a CLI at ~/.local/bin/postman and registers plugins in the agents it finds on the machine. According to the author and other users in the comments:
| Agent | What changes |
|---|---|
| Claude Code | Enables the postman@claude-plugins-official plugin in ~/.claude/settings.json |
| Codex | Adds a marketplace and the postman@postman plugin in ~/.codex/config.toml, with an MCP server at mcp.postman.com |
| Copilot | Enables postman@postman in ~/.copilot/settings.json |
| Cursor | Installs the plugin and configures the same MCP server |
So far this could look like a somewhat aggressive integration, but two details make it more delicate.
The first is the session-start hook. The plugin ships a session-start-context.md file that is injected into the agent’s context on startup, on clear and on compaction. The text begins with “Before responding to any non-trivial API engineering task” and ends by asking the agent to load the postman:api-engineer skill and follow it. In other words, it doesn’t kick in only when you ask for something Postman-related, but on any reasonably serious API task.
The second is that, according to the author, the installer tries to approve its own hook. In Codex, hooks need a user confirmation that is stored as a trusted_hash in the configuration. The installer code calls an approvePostmanHook function, with a comment saying it approves only Postman’s current hook after installation. The author is careful here: this shows the attempt, but doesn’t prove who created the specific record found on their machine. And some commenters say recent Codex versions don’t run a hook without that record, so the real impact depends on the version.
What the issue doesn’t say
The headline going around says Postman tries to share all your API data, and that’s an exaggeration. None of the people reporting the problem claim any data was uploaded; the author explicitly says they have no evidence of it. In fact, the MCP server kept failing to authenticate.
The problem is a different one: an application that isn’t an agent has modified your agents’ configuration, without asking clearly, and added instructions that change how they work.
Postman’s response
Someone from Postman replied yesterday. They explain that the CLI and plugins are bundled with the app because many users had trouble installing them, that this is mentioned on the download page and in the update flow, and that they can be uninstalled from inside the app. They add that they will make the opt-in clearer, especially for existing users, and that they are reviewing the hook approval and the session-start behaviour.
The reply gives no dates or concrete changes, and it doesn’t address what another user reported: after using Help → Postman CLI and Plugins → Uninstall Postman Coding Agent Plugin, the plugin was still enabled in Copilot.
How to check
If you have Postman installed, just look for its entries in each agent’s configuration:
grep -ns postman ~/.claude/settings.json ~/.claude/plugins/installed_plugins.json \
~/.codex/config.toml ~/.copilot/settings.json
ls -la ~/.local/bin/postman 2>/dev/null
In Claude Code you can also see it with /plugin, which lists installed plugins and lets you disable them. If it shows up and you don’t want it, the safest route is to uninstall it from Postman and then check those files by hand, since the uninstaller apparently doesn’t clean all of them.
My takeaway
A few days ago I wrote about the backdoor in the Claude Code extension on the Cursor marketplace. The Postman case isn’t comparable, because there’s no malware and no data theft, but it touches the same point: agent configuration has become a very valuable place. A session-start hook or a skill that always loads decides what the agent reads before you type anything, and on many machines that agent has access to the code, the terminal and the credentials.
That’s why I think nobody but the user should touch those files. A tool can offer its plugin, and plenty of people will probably find it useful, but it should ask explicitly and not approve on its own the mechanisms the agent uses to ask for confirmation. In the meantime, it’s worth adding ~/.claude, ~/.codex and friends to the list of things to check after updating any development application.
Source: Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook, issue #14370 on postmanlabs/postman-app-support.
