Postman Desktop Auto-Installed Claude Code and Codex Plugins, and Its Installer Code Attempted to Trust Its Own Startup Hook

Opening the Postman desktop app on an existing Mac installation was enough to change how two unrelated coding agents behaved. According to a developer’s writeup filed as GitHub issue #14370 on Oct. 25, Postman desktop 12.33.4 silently installed a Claude Code plugin, a Codex plugin, a remote MCP connection, and a separate Postman CLI — and the installer code attempts to approve its own Codex startup hook by writing its own trust record. The issue has drawn hundreds of reactions and dozens of comments through Nov. 4. On Nov. 3, Postman’s head of product, Sarabmeet Kallar, told RuntimeWire the company will “make the opt-in clearer, especially for existing users.” A separate reply posted in the GitHub thread that same day said Postman is reviewing the hook-approval and session-start behavior flagged in the issue.

What the install log actually shows

The reporter pulled this from Postman’s own ~/Library/Application Support/Postman/logs/main.log:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}
Main: autoInstall.plugin.existing-user finished
{"outcome":"installed","platform":"darwin","exposed":true,"signedIn":true,"flagTimedOut":false,"useScript":true,"installer":"script","scriptResults":"claude-code:installed,codex:installed"}

The trigger name, auto-existing-upgrade, is the giveaway: this ran on an existing, already-installed desktop app, not a fresh setup wizard. It then wrote into both agents’ global config. Codex’s ~/.codex/config.toml got a new marketplace entry, an enabled Postman plugin, and a hook trust record. Claude Code’s ~/.claude/settings.json had postman@claude-plugins-official enabled, with the install recorded in ~/.claude/plugins/installed_plugins.json. A Postman CLI binary appeared in ~/.local/bin.

File	What changed
~/.codex/config.toml	Added [marketplaces.postman], enabled postman@postman plugin, wrote hooks.state trust hash
~/.claude/settings.json	Enabled postman@claude-plugins-official
~/.claude/plugins/installed_plugins.json	Recorded Claude plugin v2.0.1 install timestamp
mcp.codex.json	Pointed at https://mcp.postman.com/mcp (failed auth on startup)
~/.local/bin	New Postman CLI binary and lib directory

The installed Codex hook, a SessionStart command matching startup|clear|compact, prints a context file instructing the agent: “Before responding to any non-trivial API engineering task… load the postman:api-engineer skill and follow it.” That fires on every new, cleared, or compacted session — not only when a developer asks for Postman specifically. If you’re writing or reviewing your own agent skills, our Codex Skills setup guide covers where Codex actually looks for a SKILL.md and how to keep a startup-triggered skill list from growing without your notice.

An installer that attempts to trust its own hook

Codex treats hooks as code a user must explicitly vouch for. Its documentation states that before a non-managed hook can run, Codex requires the user to review and trust the exact hook definition, storing that trust against a content hash. The issue traces how Postman’s installer sidesteps that: installer/src/hosts/codex.ts calls a function named approvePostmanHook, which reads the hook’s hash via hooks/list and writes it into Codex’s hooks.state through config/batchWrite. The source comment reads, “Approves only Postman’s current hook after installation.” A dev.to writeup by Gabriel Anhaia notes the change wasn’t accidental: pull request #124, titled “feat(installer): auto-approve Postman’s Codex hook,” was merged Oct. 21, and GitHub Copilot’s automated review on that PR had already flagged it, writing that “automatically granting persistent trust to hooks that can execute outside the sandbox warrants human security review.”

Claude Code has no per-hook trust prompt to route around; there the open question is simply whether the plugin itself was ever something the user agreed to. The reporter is careful to note the trust record alone doesn’t prove exactly who triggered it on their machine — only that the installer code is designed to write it. This is the same category of problem our piece on unauthored agent hooks covers: a hook that persists across sessions needs to be removed and verified gone, not just disabled once.

No data exfiltration was demonstrated. The bundled MCP connection to https://mcp.postman.com/mcp failed with an authentication error on startup in the reported case, and the sequence hasn’t yet been reproduced on a clean machine.

What’s actually opt-in, and what Postman says

Postman does offer a legitimate, documented opt-in path: its plugin install docs cover nine agents, from Claude Code and Codex to Cursor and OpenCode, and a single npx installer that detects and installs into whichever agents are present. That’s the flow a developer who wants Postman inside their agent would reasonably choose. The complaint in #14370 is narrower and sharper: the same install path ran automatically for existing desktop users who never ran that command, and the installer code attempts to create the trust record Codex’s review prompt exists to require. Our marketplace hygiene checklist walks through why reviewing and pinning a plugin source matters even when the install itself is legitimate.

A reply posted in the GitHub thread on Nov. 3 — not a confirmed official Postman statement, since the poster lists no company affiliation and dev.to says to treat it as Postman’s position only once Postman confirms it — said the company bundles the CLI and agent plugins with the desktop app because users had trouble setting them up separately, that the components can be removed from inside the app, and that it is “reviewing the hook approval and session-start behavior” flagged in the issue. Separately, Kallar’s on-record quote to RuntimeWire the same day addressed only the opt-in clarity commitment.

What to check on your own machine

If Claude Code or Codex shares a machine with Postman desktop, these commands are read-only and only report what’s already there:

grep -n -i postman ~/.codex/config.toml
claude plugin list
grep -n -i postman ~/.claude/settings.json
ls -l ~/.local/bin | grep -i postman

To remove the Claude Code plugin: claude plugin disable postman@claude-plugins-official, then claude plugin uninstall postman@claude-plugins-official. If you also want to confirm which MCP scope picked up the Postman connection, our Claude Code MCP setup guide explains how to list servers by scope and remove one cleanly. In Codex, run /hooks inside a session to inspect, review, and disable the SessionStart hook individually. Postman also ships its own remover, npx @postman/postman-plugin remove, though the dev.to writeup flags that it’s unclear whether that clears the Codex trust record on its own — worth re-running the grep afterward either way.

The broader lesson outlasts this one app: any desktop program with file access to your home directory can edit ~/.claude/settings.json or ~/.codex/config.toml, the files that decide what instructions an agent loads before your first prompt, and can point an agent at a remote MCP endpoint you never chose. Our MCP security hardening guide covers the broader pattern of unreviewed remote MCP connections landing in agent configs. Keeping those files under version control, so an unexpected git diff surfaces a change you didn’t make, is now a reasonable baseline for anyone running coding agents alongside other desktop software.