What did Postman's desktop app do?
On 24 October, a developer opened Postman desktop version 12.33.4 on a Mac. The app was already installed and the user was signed in. According to a GitHub report filed the next day, opening it triggered an installation the developer had not requested.
The Postman app's log recorded the event. It named a process called autoInstall.plugin.existing-user and listed two results: claude-code:installed and codex:installed. The source field read auto-existing-upgrade, which points to an update aimed at existing users.
The report is issue 14370 in Postman's public support tracker. It lists a Postman CLI in the user's local bin folder and a Claude Code plugin at version 2.0.1. It also found a new marketplace entry in Codex's config.toml and an MCP connection to mcp.postman.com.
The New Stack reported the findings on 3 November. It noted that the evidence covers one macOS machine and that the behavior has not been independently reproduced across other systems.
Other users added similar accounts. One said Postman updated from 12.31.3 to 12.35.1 on launch and then installed the CLI plus the Claude Code and Codex plugins. Another found Postman entries in GitHub Copilot's settings file.
Postman's documentation makes the capability explicit. Its installer configures every supported coding agent it detects. The list covers Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory Droid, Kimi Code, OpenCode and Pi.
The installer is published as the @postman/postman-plugin package on npm and requires Node.js. Its documented commands are install, status and remove. The --agent option limits an operation to one or more of the supported agents.
The plugin is a legitimate product, not a piece of hidden malware. Postman describes it as a way to bring API design, mocking, testing, documentation and monitoring into coding agents. Postman says every operation produces inspectable files or CLI commands.
That context is useful to teams that already keep collections in Postman. The plugin connects an agent to those collections and to Postman's Context Graph, which maps API dependencies and ownership. The dispute is about delivery, not whether the feature has value.
None of that explains why an existing installation would run the installer on launch. The report's log is the main evidence for that step. We found no published timeline from Postman for the rollout.
Why is the Codex hook the biggest concern?
The plugin does more than add a menu item. On Codex, it registers a session-start hook. That hook runs when a session starts, clears or compacts, and it prints instructions for the agent.
The instructions tell Codex to load a skill called postman:api-engineer before most API work. The stated trigger covers design, implementation, mocking, testing, monitoring, documentation and deployment. That is much broader than a user asking for Postman's help.
Codex normally asks the user to trust a hook before it runs. Postman's installer skips that step. The plugin README says the install "also approves Postman's session-start hook." It adds that there is no separate prompt for the hook.
The installer computes the hook's trusted hash and writes it into Codex's configuration. It checks that the hook has not changed before approving it. The result is a hook that runs with the user's blessing, even when the user never gave one.
Codex records a trusted hash so it can detect later changes to a hook. A human approval is supposed to happen before that record exists. The record is the security boundary, and the installer writes it on the user's behalf.
The Postman hook is narrower than that boundary suggests. It prints a text file with instructions. It does not, according to the report, run a remote script on every session. The effect is guidance rather than code execution.
Postman says the hook is optional in practice. Its documentation notes that the skills and MCP server work with or without it. The hook simply makes Codex reach for Postman's skills more reliably.
Critics say that defense misses the trust issue. A startup hook changes an agent's defaults on every session. Security researcher Frank Denis called the integrations "junk" and questioned the self-approval, according to The New Stack.
The concern is cumulative. A developer who opens several tools could end up with several startup hooks. Each one nudges the agent toward a different product, and none needs to be malicious to change the outcome.
Codex still follows the developer's direct instructions first, according to The New Stack. The hook shapes the default when a request is ambiguous. That is exactly the kind of influence a consent prompt is meant to expose.
A session-start hook is not inherently malicious. It can inject project conventions, safety rules or house style. The question is whether the person running the agent chose those instructions.
The hook is documented, not hidden. The disagreement is about who gets to decide when it runs.
Did Postman send API data to its servers?
A Hacker News submission on 3 November carried a stronger claim. Its title said Postman attempts to share all API data. That phrase spread quickly, but the underlying report does not support it.
The New Stack checked the issue and found no evidence that Postman collected or transmitted API data. The report documents configuration changes, a local CLI and a remote MCP connection. It does not show collections leaving the machine.
The MCP connection still deserves attention. It pointed Codex at the Postman-hosted MCP endpoint, which would let an agent query Postman's API context. On the reporter's machine, authentication failed repeatedly.
MCP stands for Model Context Protocol. It lets an agent call tools and read context from an external server. Postman markets its MCP server as a way to give agents API context, subject to the account and its permissions.
An MCP server can expose data if it is connected and authorized. That is different from a covert upload. No cited source shows Postman reading local collections or sending them anywhere.
A failed login is not a data transfer. The report shows authentication errors, which is consistent with a connection that never worked. It is also consistent with an agent that kept trying to use a server it could not reach.
The claim may have grown from the plugin's stated purpose. Postman says the plugin brings organization-wide API context to agents. Context sharing is the feature, not a bug, but it is also why the headline felt plausible.
The submission drew 1,363 points by 4 November and topped Hacker News. Virality also compressed a detailed report into a headline, and the data-sharing phrase traveled further than the correction.
Users should treat the data-theft claim as unproven. They should still review MCP entries, because a connected server can widen what an agent can reach. The honest summary is that the report proves configuration changes, not exfiltration.
What has Postman said?
The New Stack asked Postman about the automatic installs, the hook approval and user consent. The company had not responded when the article published on 3 November.
A reply appeared in the GitHub thread later that day. It was posted under the handle zecoquit and written in the company's voice. The reply said Postman bundles the CLI and agent plugins with the desktop app.
The reason given was setup friction. Many users struggled to install and wire the components separately, so bundling was meant to make setup easier. The reply said the components are mentioned on the download page and in the app update flow.
It also said users can uninstall the components inside the app. "We're going to make the opt-in clearer, especially for existing users," the reply added. It promised to review the hook approval and session-start behavior.
The account is not publicly listed as a member of Postman's GitHub organization. We therefore treat the reply as a company-voiced statement in the thread, not a verified press release. Postman's public documentation independently confirms the installer's behavior.
One detail remains disputed. Postman's download page currently presents the CLI and plugin as separate installs, with manual commands for Claude Code. That is not the same as installing them for existing users. Postman says the update flow discloses the bundle, a screen we could not verify from outside.
The documentation also lists separate install steps for each agent. Claude Code users are told to add Anthropic's marketplace and then install the Postman plugin. Codex users are told to install it through the Codex plugin directory.
Those instructions describe a deliberate choice. They do not describe a background install during a desktop update. Postman's docs present the installer as a tool a user runs, and they do not describe the desktop app invoking it.
No security advisory for the desktop app appears in the sources reviewed. The issue remains open, and the company's reply gave no version number or date for the opt-in change. That leaves administrators with a documentation gap rather than an incident report.
Who is affected, and what should you check?
The detailed report and the follow-up accounts we reviewed involve macOS. The installer supports nine agents, and users have reported changes to Codex, Claude Code and Copilot.
If you run Postman desktop alongside an AI coding agent, check that agent's configuration. Postman publishes a status command: npx @postman/postman-plugin status. It lists detected agents and whether the plugin is installed.
The status command is the quickest check. It reports which agents are present and whether Postman's plugin is installed in each. It does not tell you whether the hook was approved during an app update.
Removal is available through the installer. The documented command is npx @postman/postman-plugin remove, with an uninstall alias. The --agent flag limits it to one agent.
If you want to keep the plugin, you can. Postman says the hook is optional and the skills work without it. Postman's docs do not list a hook-only removal command, so the practical choice is the full plugin or none.
Removal may not clean everything. One commenter said the in-app uninstall menu did not remove Postman from Copilot's settings. They edited the file by hand. Treat the documented command and a manual check as separate steps.
The report's author asked for a rollback that covers agent configs, hook trust, marketplaces, caches, MCP connections and the CLI. The company's reply did not address each item. That is why a manual check still matters after any automated removal.
Enterprise teams should add agent configs to endpoint review. Home-directory files such as config.toml rarely appear in golden images or server baselines. A hook in one of those files can outlive the app that wrote it.
The files to inspect are small and readable.
- •Codex: inspect ~/.codex/config.toml for a Postman marketplace, an enabled postman@postman plugin, and a hooks.state entry.
- •Claude Code: check ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json.
- •GitHub Copilot: check ~/.copilot/settings.json for extraKnownMarketplaces and enabledPlugins.
- •CLI: look for a postman executable in ~/.local/bin.
- •MCP: search agent configs for mcp.postman.com.
Why this matters beyond Postman
The incident exposes a boundary that most agent tools have not secured. Codex, Claude Code and Copilot store plugin, hook and trust settings in plain files under the user's home directory. Any process running as that user can write to them.
That makes every desktop app a potential supply-chain path into the agent. The app does not need a vulnerability. It only needs the same file permissions the user already has.
Hooks are especially sensitive. They are persistent instructions, not one-off prompts. A hook can steer an agent toward a vendor's tools on every session, as Postman's does for API tasks.
Plugin marketplaces add another layer. The Codex entry points at a public Git repository, and Codex can refresh the plugin from the main branch. The README tells users to rerun the installer after the hook changes.
Local config files are hard to audit at scale. They live in home directories, change without a ticket, and rarely appear in endpoint dashboards. A security team may only learn about a hook when an agent starts behaving differently.
Similar debates have played out around package install scripts and browser extensions. The difference is the agent's reach. Coding agents hold repository access, cloud credentials and the ability to run commands.
The same property that makes plugins useful makes them risky. They let a vendor add capabilities to an agent without shipping a new agent version. That is convenient for updates and hard for users to track.
The fix is unlikely to come from one vendor. Agent hosts could require signed hooks, show a system-level consent prompt, or log every configuration write. Enterprises can restrict who writes to agent configs.
Bundling is also a design choice about defaults. When an app installs extra components for everyone, most people keep them. A clearer prompt matters more than a note buried in release notes.
None of the cited sources describes a legal finding against Postman. This is a product-design dispute, not an established breach. That distinction matters for anyone deciding how strongly to react.
What should happen next?
A reply in the issue thread promised a clearer opt-in for existing users. The next test is whether that arrives as a prompt before installation, or as another note after the fact.
Watch the release notes for three changes. A first-run consent screen would address the core complaint. Stopping automatic hook approval would restore the agent's own trust prompt. A complete uninstall would remove marketplace entries, hooks, MCP connections and the CLI.
Independent reproduction would strengthen the case. A second detailed log from a clean machine would help. Ideally it would come from Windows or Linux, to show whether the trigger is universal or tied to one upgrade path.
The agent vendors have their own decisions to make. OpenAI, Anthropic and GitHub could require explicit approval for any external process that writes hook state. They could also expose an audit trail of config changes.
If agents required a signed, user-visible approval for hooks, a desktop installer could not approve itself. That would move the decision back to the person running the agent, where the security model assumes it sits.
An advisory from Postman would also help administrators decide whether to block specific versions. No advisory appears in the sources reviewed, and the GitHub thread remains the main record of what happened.
For now, the practical advice is narrow. If you installed the Postman plugin deliberately, the hook is documented and optional. If you did not, run the status command and inspect the files above.
The larger lesson is about defaults. Opening an API client should not quietly change how a coding agent behaves. Once a desktop app can edit an agent's trust store, installation is no longer a neutral act.