Postman desktop reportedly auto-installs Codex and Claude plugins and tries to approve its hooks

Silent installs recorded in Postman's own logs

A bug report on Postman's public GitHub issue tracker, which reached the front page of Hacker News on October 25, 2026, accuses the Postman desktop app of modifying other developer tools without permission. According to the report, simply opening Postman on macOS triggered the automatic installation of plugins for the Codex and Claude Code coding agents, changes to their global configuration files, a startup instruction that steers those agents toward Postman, and a separately installed Postman CLI.

The reporter, a signed-in user of Postman desktop 12.33.4, discovered the changes after noticing recurring MCP authentication warnings and Codex unexpectedly invoking Postman skills during ordinary API work. The investigation is dated October 25, 2026, with the underlying installation logged the previous day.

Central to the report is an excerpt from the Postman desktop main log. Two entries timestamped October 24, 2026 at 09:34 UTC describe a plugin installation triggered by an auto-existing-upgrade source, with results showing claude-code and codex as installed, followed by a line recording that an automatic install for an existing user had finished. On the Codex side, the report shows that the global config.toml gained a marketplace entry pointing at Postman's plugin repository, an enabled plugin reference, and a hook trust record containing approved hashes for Postman's hook.

A startup hook that redirects agent behaviour

The installed hook registers a session-start command, matched on startup, clear and compact events, that prints an instruction document into the agent's context. According to the report, that instruction tells the agent to load and follow Postman's api-engineer skill before handling essentially any non-trivial API task — designing, implementing, mocking, testing, monitoring, documenting or deploying an API or Postman Flow.

The reporter argues this goes far beyond a user explicitly asking an agent to use Postman: it makes Postman the default workflow for broad categories of API engineering inside unrelated tools, simply because the desktop app was opened.

Self-approval and a remote MCP endpoint

The report also examines the installer's source code, pinned to the exact revision found on the machine. According to the reporter, the Codex installer path invokes an approval routine after installing the plugin, and a companion module reads the hook's hash and writes a trusted hash entry into Codex's configuration — in effect, approving Postman's own hook on the user's behalf. A code comment describes the routine as approving only Postman's current hook after installation.

The reporter is careful with this claim: the presence of a trust record on the machine does not by itself prove who wrote it, so the code is presented as evidence of an approval attempt rather than proof of a specific interaction.

Additionally, a remote MCP connection pointing at Postman's MCP endpoint was enabled, but Codex logs show the server failing to start with an authentication-required error. Claude Code's settings were also modified to enable an official Postman plugin, version 2.0.1, with installation timestamps matching the same window, and a Postman executable appeared in the user's local bin directory with modification times consistent with the installation.

What the report does not claim

Despite the severity framing, the report explicitly declines to claim data exfiltration. The MCP connection failed authentication, and no evidence is presented that API data was sent anywhere. The claim is narrower but still significant: an API client altered the configuration, instruction context and trust state of other applications without an opt-in.

The reporter also notes the observed sequence has not yet been reproduced on a clean machine. The issue has drawn reactions from dozens of GitHub users, and the reporter has since removed the local installation after preserving evidence.

Requested remediation

The reporter asks Postman to treat the incident as a product consent and security-boundary issue rather than a documentation question, to halt automatic agent-plugin and CLI installation for existing desktop users until an explicit opt-in exists, to remove installer-side hook approval so trust decisions remain with the agent host, to disclose the release or feature flag behind the auto-install path and which other agents and files it can touch, to provide a complete rollback covering agent configs, hook trust, marketplaces, caches, MCP connections and the CLI, and to narrow the startup instruction so Postman skills load only when explicitly requested.

Why it matters

Trust mechanisms such as hook hashing exist precisely so that software cannot quietly inject instructions into coding agents. If an installer can write its own trusted hashes, that safeguard is largely decorative. The report also illustrates a broader risk as AI coding agents spread: any locally installed application can potentially make itself the invisible default in a developer's agent workflow, rerouting work and attaching remote endpoints without consent. Postman is among the most widely used API clients, and behaviour like this — even without proven data loss — erodes the trust desktop development tools depend on. Whether it was an intentional rollout or a misconfigured flag, the incident is a reminder to audit agent configuration files after installing or updating software that has no obvious business touching them.