The log records the installation
Most silent-install stories rest on a user’s suspicion. This one rests on the vendor’s own bookkeeping. Postman’s main.log records a service completing a scripted install with the source auto-existing-upgrade and both target agents listed as installed, followed by a second line naming the flow autoInstall.plugin.existing-user. The user was signed in. Nothing in the recorded flow is an opt-in screen.
What landed is itemized in the issue. Codex’s global configuration gained a Postman marketplace entry, an enabled Postman plugin, and a hook trust record carrying a hash. Claude Code’s settings enabled the Postman plugin at user scope, with install timestamps matching the same minute. A Postman command-line tool appeared in ~/.local/bin. One app opened; its installation flow changed configuration in two other applications, placed a command-line tool on the machine, and recorded the operation in Postman’s own log.
The hook is the point
A plugin install can be undone in a minute. The startup hook is the part worth reading slowly. The Codex SessionStart hook is configured to run on startup, clear and compact events. It prints an instruction: before responding to a non-trivial API engineering task, load Postman’s API-engineer skill and follow it.
That is not an integration waiting for a user to invoke it. It is a standing instruction to a general-purpose agent to make one vendor the default route for an entire category of work, installed by an app the user opened for something else. Then comes the step that turned a packaging complaint into a security-tagged issue. The installer source contains a function named approvePostmanHook that reads the hook’s hash and attempts to add it to Codex’s trust store. Its accompanying comment says it “approves only Postman’s current hook after installation.” The issue’s author explicitly cautions that the trust record alone does not establish which process created that particular entry. Hook trust exists so the user decides which instructions an agent obeys at startup. An installer answering that question for itself makes the prompt decorative.
What the headline gets wrong
The story reached the top of Hacker News under a headline claiming Postman “attempts to share all API data”. The report does not show that, and its author took care to say so. The remote connection the plugin configured, to Postman’s MCP server, failed authentication in the reporter’s logs. A second user who reproduced the auto-install on November 3, upgrading to version 12.35.1, also reported no evidence that data was uploaded. What is documented is the wiring: a remote endpoint configured before a working login existed, and an instruction directing API-related agent work toward Postman’s tools. That establishes a change in the machine’s configuration, not a successful transfer of API data. Anyone repeating the stronger claim is ahead of the evidence.
Postman’s answer, so far
A Postman staffer, in a response reported in the issue thread on November 3, said the CLI and agent plugins are bundled to ease setup, are mentioned on the download page and in the update flow, and can be uninstalled inside the app. The staffer said Postman would make the opt-in clearer, especially for existing users, and was reviewing the hook-approval and session-start behavior. That answers the presentation question. It does not yet answer the reporter’s six requests, which include naming the feature flag behind auto-existing-upgrade, listing every agent and file the flow can touch, and publishing a complete rollback that a removal cannot silently undo. The existing-user wording matters: the flow that fired here was built for people who already had the app, the group least likely to be reading a download page.
Four places worth checking
If Postman desktop is installed on a machine that also runs coding agents, four locations are worth inspecting. They cover the artifacts documented in the two reported Codex and Claude Code cases; they are not a complete inventory of every possible integration or installation path. Postman’s own log, under its application support folder, will show auto-existing-upgrade or autoInstall lines if the flow ran. Codex’s ~/.codex/config.toml should have no Postman marketplace, plugin or hooks.state entry you did not add. Claude Code’s ~/.claude/settings.json and its installed-plugins record should show no Postman plugin at user scope. And ~/.local/bin should not hold a Postman executable you never installed. A later commenter in the same thread also reported Postman entries in Copilot’s settings file. These reports suggest that other agent integrations may also be affected, although the additional cases have not been independently verified by ALFW. Removing the desktop app, on the evidence in the thread, is not the same as removing what it installed.
Sources
- [1] GitHub issue #14370, postmanlabs/postman-app-support, “Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook”, filed by indicava (primary source; read first-hand in full at Gate 1 — Postman desktop 12.33.4; the main.log lines timestamped 2026-10-24T09:34:14.418Z recording source auto-existing-upgrade with results claude-code:installed and codex:installed, and the flow name autoInstall.plugin.existing-user, for a signed-in existing user; the ~/.codex/config.toml additions — a Postman marketplace entry, the enabled postman@postman plugin, and a hooks.state trust record; the SessionStart hook and its startup|clear|compact matcher; the installer’s approvePostmanHook step and the author’s caution that the trust record alone does not prove who created that specific record; the remote connection https://mcp.postman.com/mcp failing with “Auth required”; the Claude Code plugin 2.0.1 at user scope, installedAt 2026-10-24T09:34:02.610Z; the Postman CLI in ~/.local/bin; the closing statement that the report “does not claim to establish data exfiltration”; and the reporter’s six requests, including the feature flag, the full file list and a complete rollback)Read source
- [2] Postman plugin source at the installed revision 6c8e452e0f4237f4bcc0901cb1ac442dec707e49, postmanlabs/postman-plugin (linked from the issue — hooks/session-start-context.md, and the installer hook-approval code in installer/src/hosts/codex-hooks.ts, whose comment says it “Approves only Postman’s current hook after installation”)Read source
- [3] MODEL, “Postman desktop auto-installs Codex/Claude plugins — without clear consent”, November 3, 2026 (read first-hand at Gate 1 — the second reproduction, by user ronthedrummer on the November 3 upgrade from 12.31.3 to 12.35.1: CLI, Claude Code and Codex installed, Cursor recorded as already-installed, no hooks.state entry on his Codex, and no evidence data was uploaded; the later commenter who found Postman entries in Copilot’s ~/.copilot/settings.json; and Postman’s response as reported — staffer zecoquit in the issue thread: the CLI and agent plugins are bundled to ease setup, are mentioned on the download page and in the update flow, and can be uninstalled inside the app; Postman will “make the opt-in clearer, especially for existing users” and is reviewing hook approval and session-start behavior; RuntimeWire attributes the same commitment to Head of Product Sarabmeet Kallar, via Offleash PR, November 3)Read source
- [4] DEV Community (slabb), “Postman silently installed itself into Claude Code and Codex: the log lines, the self-approving hook, and the 4-point audit”, November 4, 2026 (read first-hand at Gate 1 — the four-check audit assembled from the issue evidence, and the issue’s 299 reactions and 38 comments; this analysis describes the issue thread as having no Postman staff reply, which conflicts with MODEL’s November 3 account above — the article attributes the response to the reporting and does not resolve which account is current)Read source
- [5] Hacker News discussion, item 50354960, November 3, 2026 (title verified first-hand at Gate 1: “Postman silently auto-installs AI plugins and attempts to share all API data” — the headline the article corrects; no points count is used)Read source