Postman 12.33.4 Silently Installs Codex and Claude Code Plugins and Approves the Hook Itself

⚡ The Gist in 5 Seconds

• Postman Desktop 12.33.4 on macOS installed the postman plugins for Codex and Claude Code on its own, without asking.
• ~/.codex/config.toml gained a marketplace entry, an enabled plugin, and a hooks.state with a trusted_hash.
• A session-start hook tells the agent to load postman:api-engineer on any remotely serious API task.

🔍 What Happened

On October 25, 2026, user indicava opened issue #14370 in the postmanlabs/postman-app-support repository. The trigger: their Mac running Postman Desktop 12.33.4. After another app launch, Codex started routing API work through Postman over and over, and MCP authorization warnings began flooding the console. The author followed the trail and found five artifacts at once: a user-wide Postman plugin, a startup hook, a remote MCP connection, a plugin for Claude Code, and a separately installed Postman CLI. On Hacker News the thread racked up 1,084 points and 358 comments.

The mechanics are visible in the logs. In ~/Library/Application Support/Postman/logs/main.log, lines 11562–11563, timestamped 2026-10-24T09:34:14.418Z, sits the entry "source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script". One line below — autoInstall.plugin.existing-user finished with "outcome":"installed". In ~/.codex/config.toml, a marketplace entry from the postman-plugin repository appears, followed by [plugins."postman@postman"] enabled = true and a hooks.state record with trusted_hash = "sha256:b67ddd1e...".

Then comes the most interesting part. The file hooks/codex-hooks.json hooks SessionStart on startup|clear|compact and feeds the model this text: "Before responding to any non-trivial API engineering task … load the postman:api-engineer skill and follow it." And installer/src/hosts/codex.ts, after installation, calls approvePostmanHook(system): it fetches the hook's hash via hooks/list and performs a config/batchWrite, writing trust for itself. The code says it plainly: "Approves only Postman's current hook after installation".

🧠 Our Take

Why exactly now — I can't say for sure, but the context is readable. API tool vendors are fighting for space inside other people's agents, and Postman here acts more aggressively than anyone I've seen: it doesn't offer to install a plugin, it installs it during an upgrade. Our assessment: this isn't an accidental bug but a product bet, just implemented without a consent screen. It also explains where those "sudden" Postman reminders in other tools' sessions come from.

What it changes. An API client is now editing another tool's config. You opened Postman — you got a steering instruction in Codex that fires on any "non-trivial" API task. The threshold for "non-triviality" is set by the agent, which in practice means the hook's author. For your wallet, it costs nothing so far. For trust, it costs a lot: after this, I have no reason left to keep the desktop app when curl and collections in CI are enough.

Who wins and who doesn't. Postman — if you count share of attention in agent pipelines as a win. Codex and Claude Code lose: foreign context is being mixed into them. Teams whose agent configs live in git and get reviewed lose too — a diff like this won't surface right away. We believe the market needs a simple standard: offer the integration, but writing into someone else's config.toml should only happen with an explicit "yes".

⚠️ What We Don't Know

One voice and one Mac. The author himself notes that the trusted_hash record doesn't prove who created it. There's no response from Postman in the thread. It's unknown how many versions and platforms are affected — Windows doesn't appear in the report. An open question: whether there was a consent screen somewhere that the author skipped past. Worth checking manually — ~/.codex/config.toml, the ~/.claude directory, Postman logs, and which postman.

Prediction: within a quarter, Postman will ship a patch with explicit plugin-install confirmation — otherwise issue #14370 will remain the top link for the query "Postman privacy".

Disclaimer: not officially confirmed; a single source — a GitHub issue from one user.

Source: postmanlabs/postman-app-support