Postman desktop auto-installed Claude Code and Codex plugins, a user's logs show

A Postman desktop user says the app quietly installed Postman’s plugin into Claude Code and Codex, added a session-start hook that steers Codex toward Postman for API work, enabled Postman’s remote MCP server and put a Postman CLI in ~/.local/bin. The report is issue #14370 in Postman’s support tracker, opened on 25 October by GitHub user indicava and widely shared on 3 November. Everything below comes from that user’s logs and from Postman’s public source code. We have not reproduced it.

What the reporter’s logs show

The reporter was on Postman desktop 12.33.4 on macOS, signed in. They quote two lines from Postman’s own log (~/Library/Application Support/Postman/logs/main.log), timestamped 24 October:

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

A second line records autoInstall.plugin.existing-user finished with outcome installed. According to the issue, the following changes were in place afterwards:

• Codex: ~/.codex/config.toml gained a [marketplaces.postman] entry pointing at postmanlabs/postman-plugin, an enabled [plugins."postman@postman"] block, and a hooks.state entry for Postman’s session-start hook with a trusted_hash.
• Claude Code: ~/.claude/settings.json enabled postman@claude-plugins-official, and ~/.claude/plugins/installed_plugins.json recorded version 2.0.1 at user scope.
• MCP: the plugin’s Codex config points at https://mcp.postman.com/mcp, and Codex logged “Auth required” startup failures for it.
• CLI: a Postman executable and its lib directory appeared in ~/.local/bin in the same time window.

The reporter’s sequence was opening an existing Postman install after a while away. They say they have not reproduced it on a clean Mac, and they state that the report does not claim data exfiltration.

The hook, and who trusts it

The hook runs on Codex startup|clear|compact and prints a context file. At the reporter’s pinned plugin revision, that file tells the agent: “Before responding to any non-trivial API engineering task … load the postman:api-engineer skill and follow it.”

Codex normally leaves that approval to the user. Postman’s own docs say of the Codex plugin: “If you install Codex with its own method instead, you review and approve the hook yourself.” Postman’s installer source at that revision includes a function documented as “Approves only Postman’s current hook after installation”, which writes the hook’s hash into hooks.state through Codex’s config/batchWrite. This is documented behavior for Postman’s manual npx installer: the README on main still says “installation also approves Postman’s session-start hook” and “There is no separate hook prompt.” The reporter’s point is that, by their logs, the desktop app ran that installer without them asking. They add that the trust record alone does not prove which process wrote it.

Postman’s response

As of about 21:15 IST (UTC+2) on 3 November, Postman had not replied in the issue thread. All the comments there are from other users. We found no statement on Postman’s blog or the @getpostman account on X, and Postman’s plugin docs do not mention installs triggered by the desktop app.

How to check your machine

These are the locations the reporter names:

• In ~/.codex/config.toml, look for [marketplaces.postman], [plugins."postman@postman"] and any hooks.state key starting with postman@postman.
• In ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json, look for postman@claude-plugins-official.
• Check ~/.local/bin for a postman executable you did not install.
• On a Mac, search Postman’s main.log for auto-existing-upgrade.

Postman’s installer docs list npx @postman/postman-plugin status to see what is installed and npx @postman/postman-plugin remove to remove the plugin from every detected agent. If you want to keep the plugin, read the hook text before leaving it trusted.

Why this matters

Startup hooks and instruction files shape what an agent does before you type anything, which is why an AGENTS.md left in a Downloads folder could hijack Codex and Claude Code. Here the reported change came from a vendor’s own app rather than an attacker, but it went through the same config files and by the reporter’s account skipped the hook approval step that exists to catch it. Treat your ~/.codex and ~/.claude folders as something to audit, the way NVIDIA’s SkillSpector treats skills: check what is installed before trusting it.