Postman Desktop Added Itself to Claude Code and Codex. Its Installer Trusts Its Own Hook

• Book: AI Agents Pocket Guide
• The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

A developer opened the Postman desktop app, version 12.33.4, on a Mac on October 24. According to the GitHub issue they filed the next day, Postman's own log then recorded this:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade",
 "results":["claude-code:installed","codex:installed"],
 "installer":"script"}
Main: autoInstall.plugin.existing-user finished

The reporter describes the changes as unexpected: "the integrations were installed automatically." The trigger name says why it ran: auto-existing-upgrade, an install pushed to an existing desktop user. The issue is titled "[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook". On November 3 it was picked up by AI Weekly and a write-up here on dev.to, and The New Stack has covered it too. That same day, a reply in the thread written in Postman's voice said the opt-in will get clearer.

If you run Claude Code or Codex on a machine that also has Postman, this is worth five minutes.

What the installer changed

The issue lists the files the install touched on macOS. In ~/.codex/config.toml it added a [marketplaces.postman] table, a [plugins."postman@postman"] table with enabled = true, and records under [hooks.state]. In ~/.claude/settings.json it enabled postman@claude-plugins-official, and it recorded that install in ~/.claude/plugins/installed_plugins.json (issue #14370).

It also dropped the Postman CLI into ~/.local/bin, and the Codex plugin's MCP config points at https://mcp.postman.com/mcp. The versions in the report were Codex plugin 1.1.0 and Claude Code plugin 2.0.1. A later commenter in the same thread reports the auto-install on a desktop app that updated from 12.31.3 to 12.35.1, so this isn't pinned to one build.

What the reporter did not show is data leaving the machine. The dev.to write-up notes the MCP connection failed with an auth error, and that the reporter says the sequence hasn't yet been reproduced on a clean Mac.

One desktop update, two coding agents changed: the reported install wrote to both Codex's and Claude Code's config.

The hook that approves itself

The Codex half is the part that drew the "SEVERE" label. Codex treats hooks as code you must vouch for. Its hooks docs say: "Before a non-managed hook can run, Codex requires you to review and trust the exact hook definition." Trust is stored against a hash, so a changed hook needs a fresh review.

Postman's plugin ships a SessionStart hook with the matcher startup|clear|compact. Per the issue, it prints a context file telling 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, whether or not you mentioned Postman.

The installer then calls a function named approvePostmanHook, whose source comment reads "Approves only Postman's current hook after installation" (issue #14370). It writes a trusted_hash into Codex's [hooks.state], which is the record Codex's review prompt exists to create. The reporter is careful here: the code shows the approval attempt, not proof of who wrote the record on their machine.

This was not an accident in the plugin repo. PR #124, "feat(installer): auto-approve Postman's Codex hook", was merged on October 21. Its description says "Hooks can run outside the sandbox." GitHub Copilot's automated review on that PR flagged it: "Automatically granting persistent trust to hooks that can execute outside the sandbox warrants human security review." Postman's install docs say it plainly too: "The installer approves the hook for you."

Claude Code has no per-hook trust prompt to skip. Its plugin docs say an enabled plugin "is part of every session" and "what the plugin runs, it runs as you." There, the question is whether you agreed to the plugin at all.

What Postman says

To be fair to the plugin: installing it on purpose is a documented, opt-in path. Postman's docs cover nine agents, from Claude Code and Codex to Cursor and OpenCode, and PR #45 added a single npx installer that finds the supported agents on your machine and installs into each one. For a developer who wants Postman inside their agents, that's one command instead of a setup per agent.

The complaint is the auto-install for existing desktop users. The issue asks Postman to stop it "pending explicit opt-in" and to "Remove installer-side self-approval of hooks."

On November 3, a reply in the thread said "we bundle the Postman CLI and the agent plugins with the desktop app", because users had trouble setting them up separately. It added: "we're going to make the opt-in clearer, especially for existing users" and "we're reviewing the hook approval and session-start behavior you flagged." It also said the components can be uninstalled from inside the app. The account that posted it lists no company on its GitHub profile, so treat it as Postman's position once it shows up in Postman's own release notes.

The three places to look: Codex's config.toml, Claude Code's settings.json, and ~/.local/bin.

Check your machine

These are read-only. They print any Postman entries in each agent's config and any Postman binary in ~/.local/bin:

# Codex: marketplace, plugin and hook-trust entries
grep -n -i postman ~/.codex/config.toml

# Claude Code: enabled plugins
claude plugin list
grep -n -i postman ~/.claude/settings.json

# A CLI you may not have installed
ls -l ~/.local/bin | grep -i postman

If you didn't want the Claude Code plugin, the documented shell commands turn it off or remove it:

claude plugin disable postman@claude-plugins-official
claude plugin uninstall postman@claude-plugins-official

In Codex, run /hooks in a session. The docs say it lets you "inspect hook sources, review new or changed hooks, trust hooks, or disable individual non-managed hooks." Disable the Postman SessionStart hook there. Postman's own remover is npx @postman/postman-plugin remove, per its install docs. I haven't run it, and the docs don't say whether it clears the Codex trust record, so re-run the grep afterwards. The dev.to write-up also warns that removing the desktop app may not remove these agent integrations.

Your agent config is an install target now

The lesson travels past Postman. ~/.claude/settings.json and ~/.codex/config.toml decide what instructions your agent reads before your first prompt and which commands run as you. Any app with an installer and file access to your home directory can edit them. Postman's installer already supports nine agents.

Two habits make this kind of change visible. Keep those files in a dotfiles repo, so a git diff shows any edit you didn't make. And read the session-start context your agent loads now and then. Postman's hook tells the agent to load its skill "Before responding to any non-trivial API engineering task", and that instruction lands in every session the hook starts.

Would you want desktop apps to install agent plugins with a clear prompt, or never at all? Tell me in the comments.

If this was useful

Hooks, skills and startup context are how you steer an agent before it does anything, and also how someone else can. The AI Agents Pocket Guide covers those guardrails: what an agent should be allowed to load, run and decide on its own. It's one of 8 short books in the Pocket Guides for Developers series, on agents, RAG, prompts, observability, events, databases and system design.

I also build Hermes IDE, a free, source-available console that runs Claude Code, Codex and other agents side by side, each in its own terminal and worktree, with your own sign-ins (GitHub).