A silent install, and a headline that outruns the evidence

On November 3, a Hacker News submission titled "Postman silently auto-installs AI plugins and attempts to share all API data" reached the front page and carried 1,109 points and 362 comments as of 04:19 UTC on November 4 [1]. The link under the discussion goes to a GitHub issue in Postman's own app-support tracker, titled "[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook" [2].

The two halves of that headline need different treatment. The installer behavior is documented. Postman's desktop app did install plugins into two coding agents, OpenAI's Codex and Anthropic's Claude Code, during an upgrade path its own log labels auto-existing-upgrade, and the installer approved its own startup hook, the code a coding agent runs when a session begins. Postman's own documentation confirms the self-approval. The data-sharing half is not documented: the reporter's log shows the configured remote endpoint failing authentication before any session completed [3][4]. What remains for enterprises to audit is a consent failure with an unusually complete paper trail, and that failure is the part worth acting on.

What the log establishes, and what it does not

The documented record runs through the issue's contents as relayed by two independent write-ups. Opening Postman desktop on October 24, 2026 at 09:34 UTC produced this line, on Postman desktop 12.33.4 [3]:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}

As the verification write-up puts it, "The words that matter are auto-existing-upgrade." [3] The install came from the app's own upgrade path, not from a user answering an install prompt. On macOS the run touched ~/.codex/config.toml, ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json, and placed a Postman executable in ~/.local/bin [4]. A developer posting as indicava filed the issue on October 25; the installed pieces were Codex plugin 1.1.0 and Claude plugin 2.0.1 [4].

Documented in the record Not established
Plugins installed into Codex and Claude Code by the desktop app's upgrade path on October 24, 2026 [3] Any API data leaving the machine; the endpoint connection failed authentication [3]
Agent config files modified; a remote Postman MCP endpoint written into the Codex config [4] Whether the same run reproduces on a clean machine [3]
The installer wrote the hook's trust record itself, per both the write-ups and Postman's own docs [4] Which agents beyond the two in the log were affected in practice [4]

Three consent decisions the installer made for you

Read together, the log and Postman's own documentation describe three decisions the installer executed without waiting for an answer.

The first decision was which tools to enter. The log's results field names the two agents it installed into [3]. Postman's documentation describes the installer's scope: "Install the plugin into every detected agent at once, or add it to a single agent using that agent's own method." [5] The plugin repository carries a pull request titled "feat(installer): add npx @postman/postman-plugin to install into every agent" [6]. The log shows an installer run executing during an app upgrade on one machine; whether that run covered every agent detected on the machine, and whether it used the npx installer the pull request describes, is not in the documented record.

The second decision was where agent work would flow. The config written into Codex pointed at https://mcp.postman.com/mcp, a Postman-run MCP server, the interface through which coding agents call external tools [4]. Postman's overview page describes the intended path once connected: "It sends your agent's requests to the Postman CLI whenever the Postman CLI can complete them, and falls back to the Postman MCP Server only for tasks the Postman CLI doesn't support." [5] By that description, the tasks a local CLI cannot handle would go to a Postman-operated server. In the documented run the connection never authenticated [4].

The third decision was whose approval the hook needs. The hook added to Codex opens with a startup instruction, quoted in the AI Weekly write-up: "Before responding to any non-trivial API engineering task...load the postman:api-engineer skill." [4] That routes any non-trivial API task to Postman's skill whether or not the user asked for Postman. The same write-up describes a function in the installer called approvePostmanHook, which writes the hook's trusted_hash into the host application's trust store; in its wording, "Codex's hook-approval prompt, designed to stop a third party from silently running code inside the agent, is answered by the installer." [4]

Postman's documentation confirms the behavior in the vendor's own voice: "On Codex, the plugin adds a session-start hook that guides Codex to Postman's skills. The installer approves the hook for you." [7] It also notes the hook is not functionally required: "Postman's skills and MCP server work either way, with or without the hook. The hook makes Codex reach for Postman's skills more reliably." [7]

AI Weekly further relays, from the plugin repository, that a commit message on pull request #124 reads "Hooks can run outside the sandbox," and that Copilot's security review on that pull request flagged auto-granting persistent trust to hooks running outside the sandbox as warranting human review [4].

What one machine cannot prove, and where the record stops

The documented run covers two agents on one reporter's machine. Postman's documentation lists nine supported agent ids, among them cursor, copilot and opencode [7]. The pull request speaks of "every agent" [6], and AI Weekly characterizes it as aimed at five agents at once [4]. What happens on other agents, other versions, or a clean machine sits outside the record; the reporter's stated limit is that it was "not reproduced on a clean Mac" [3].

On intent, the record supports a narrower claim than AI Weekly's editorial does. Its judgment is that the installer "deliberately bypassed the trust-approval prompts that Claude Code and Codex use to gate third-party hooks," and that "any desktop tool with installer privileges on a developer's machine can now replicate this pattern across an entire AI toolchain in one upgrade event" [4]. The documentation supports the narrower half: the self-approval is intentional, documented behavior presented as convenience. Whether it was designed to evade scrutiny is the critic's characterization; the documented pages do not settle it.

At least one community claim has run further than the record. A separate Hacker News post, filed on November 4, is titled "Tell HN: Don't use Postman, they proxy your info without your permission" [8]. That is the poster's wording; nothing in the documented record covers request proxying. One adjacent data point: Microsoft's Security Blog published an October 30 postmortem titled "Inside a malicious Claude Code-branded extension and its persistent SSH backdoor" [9]. As of publication, no public statement from Postman was found.

Four local checks, and three questions for any SaaS vendor

The documented run leaves files and settings on the machine, which makes it auditable. Four checks cover the places it touched:

  1. Read the agent configuration the installer writes: ~/.codex/config.toml, ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json. A Postman entry, or an MCP server block pointing at https://mcp.postman.com/mcp, is the documented footprint of the installer [4].
  2. Look for the trust record. The documented installer wrote the hook's trusted_hash into the host application's trust store; a Postman hook marked trusted with no human approval behind it is the signature of this run [4].
  3. Use the vendor's own tooling. The installer ships as the npm package @postman/postman-plugin, with status and remove commands and a --dry-run flag alongside the default install [7].
  4. Check ~/.local/bin for a Postman executable placed outside the app bundle [4].

None of these checks answers what triggers the upgrade path, so the moment to repeat them is right after the next Postman desktop update. Enterprises that standardize on coding agents can also put three questions to any vendor whose desktop app ships an installer, and check the answers against behavior:

  • Whether installer-driven changes to other tools are opt-in by default, and what happens when a user declines.
  • Whether any installer step writes trust records into another application's trust store; an approval prompt the installer itself answers is not an approval gate.
  • Whether a hook fires on every task in a category or only on tasks that name the product, when Postman's own documentation says the skills and the MCP server work with or without the hook [7].

The record in this case ends at a checkable place: two agents installed, config files modified, a hook trusted by its own installer, a remote endpoint that never authenticated. No documented span shows API data leaving the machine [3]. The precedent will outlast this incident: a desktop application that updates itself can restructure a developer's AI toolchain without a single dialog box, and the audit surface worth writing into SaaS policy is the one between installers and the tools they touch.