Postman Desktop Reportedly Auto-Installed Codex and Claude Code Plugins and Approved Its Own Hook

A user says that opening the Postman desktop app on a Mac was followed by unrequested changes to their coding agents. Postman's own log, they report, shows the app installing a Codex plugin and a Claude Code plugin by itself. The plugin's public README confirms one key detail: on Codex, the installer also approves Postman's session-start hook for the user.

The report is GitHub issue 14370 on postmanlabs/postman-app-support, opened on October 25, 2026. It reached the front page of Hacker News on November 3, 2026, with roughly 160 points and 40 comments when we checked. It is one user's evidence from one machine. We have not reproduced it, and we did not find a Postman reply on the pages we read. Treat the details below as a documented report, not a confirmed finding about every install.

TL;DR: what is reported and what is confirmed

Agents that act on your behalf need rules. See how explainx helps secure your agents →

What the issue author found

The author, posting as indicava, describes a chain of symptoms. Codex began repeating MCP authentication warnings. It also started routing API work through Postman skills. Investigation turned up a user-wide Postman plugin, a startup instruction hook, a remote MCP connection, a Claude Code plugin and a separately installed Postman CLI.

The evidence they list, all from one Mac:

• A Postman log line. In main.log, timestamped 2026-10-24 at 09:34 UTC, the app records a plugin install with the source auto-existing-upgrade and results claude-code:installed and codex:installed. A second line reports the outcome as installed, with the user signed in.
• A changed Codex config. The global ~/.codex/config.toml gained a postman marketplace pointing at the postmanlabs/postman-plugin Git repo, an enabled postman@postman plugin and a hook state entry with a trusted hash.
• A broad startup instruction. The hook registers a SessionStart command. It prints a context file telling the agent to load a Postman API skill "before responding to any non-trivial API engineering task". The author points out that this goes far beyond a user asking for Postman.
• A remote MCP server that cannot log in. The plugin points at https://mcp.postman.com/mcp. Codex logs show a startup failure with "Auth required", which explains the repeated warnings.
• Claude Code and a CLI too. ~/.claude/settings.json enabled postman@claude-plugins-official, and a Postman executable appeared in ~/.local/bin with matching timestamps.

The author is careful about one limit. The trust record in the Codex config does not by itself prove who created it, so they do not claim it as proof of a user action. They point at the installer source instead, which calls an approval step after install.

The part Postman's README confirms

The strongest independent detail is in the plugin repo. The README tells users to run npx @postman/postman-plugin, which "configures Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory Droid, Kimi Code, OpenCode and Pi" in one pass. It then states that for Codex, installation also approves the session-start hook, with "no separate hook prompt or dump of its instructions".

That is a design choice, stated openly. The README also says that if Codex later refreshes the plugin and the contents change, the user should run the installer again to approve the update. So the plugin is built around a trust step that the installer performs on the user's behalf.

This matters because a hook is not a passive file. Codex hooks run at defined events and can inject text into the agent's context. Our guide on skills versus hooks versus prompts explains why a hook is the strongest of the three: it fires without the model choosing to call it. Approval is the safety gate. When the installer approves the hook, the gate is still there, but the user never sees it.

The open question is not whether Postman can do this by running its own installer. The open question is whether the desktop app should run that installer for existing users on upgrade, with no clear opt-in. The issue author argues it should not. We cannot settle that from the evidence public today.

Why a startup hook is a trust boundary

Coding agents read a lot of text before they act: system prompts, project files, skills, tool descriptions and hook output. Any of it can steer behavior. The more tools that can write into those places, the more places an unwanted instruction can come from.

Three properties make the reported setup worth attention:

1. Scope. The instruction applies to "any non-trivial API engineering task", so it shapes many sessions, not only Postman ones.
2. Persistence. It sits in the user-wide config, so every project inherits it.
3. Remote reach. The plugin also wires in a hosted MCP endpoint. A connection to a remote server is a path for data to leave the machine once authentication succeeds. Our MCP explainer covers why each connection deserves a deliberate yes.

None of this requires bad intent. A vendor can ship a helpful plugin and still cross a line if users did not choose it. That is the author's argument: "installing plugins, adding remote connections, and trusting hooks in other applications each require a clear, specific opt-in in the affected application."

What the issue author asks Postman to do

The requests are specific and easy to verify later:

• Stop automatic agent-plugin and CLI installation for existing desktop users until they opt in.
• Remove the installer-side self-approval of hooks, so trust is decided in the agent host.
• Name the release or feature flag behind auto-existing-upgrade, and list which agents and files can change.
• Publish a full rollback path covering agent configs, hook trust, marketplaces, caches, MCP connections and the CLI, and respect removal without reinstalling.
• Narrow the startup instructions to explicit Postman requests.

The author says they removed the local Postman install and its integrations after saving evidence. Source links in the issue are pinned to the exact plugin revision they inspected, which makes the claims checkable.

What developers are saying

The Hacker News thread is large and mostly about Postman as a company, not the technical details. A fair summary: many commenters are angry, and few add new facts. Still, a few points are useful.

• Commenter pants2 argues the tool drifted after heavy funding, toward forced logins, data collection and AI features. That is an opinion about motive, not evidence about this incident.
• richwater says they now use Bruno, an open-source API client, and calls Postman "almost a virus". That is their opinion.
• Surac writes that "skills are just md files". It is a short remark. Read in context, it points at how little technical gate sits between a vendor's text and your agent's instructions.

We treat all of this as commenter opinion. No commenter in the portion we read produced a Postman statement.

How to check your own machine

Do this before you change anything, and keep a copy of what you find.

1. Codex. Open ~/.codex/config.toml. Look for a [marketplaces.postman] block, a [plugins."postman@postman"] block and a hooks.state entry that names postman.
2. Claude Code. Open ~/.claude/settings.json and look for postman@claude-plugins-official. Check ~/.claude/plugins/installed_plugins.json for the install time.
3. CLI. Run ls -l ~/.local/bin and look for a postman file with a date that matches your last Postman upgrade.
4. MCP. Check each agent's MCP list for mcp.postman.com.
5. Logs. On macOS, Postman keeps main.log under ~/Library/Application Support/Postman/logs/. Search it for autoInstall and auto-existing-upgrade.

If you find the plugin and did not want it, the README documents npx @postman/postman-plugin remove. The issue author asks for a more complete rollback, so after running it, re-check the files above and remove any leftover hook state, marketplace entry and cached copies yourself. If you want the plugin, nothing here says it is unsafe on its own. The point is that you should be the one who decided.

What to do if you run coding agents at work

Teams often give agents broad file access and long-lived credentials. A tool that edits agent config can change what every developer's agent does. Three habits help:

• Diff your agent config. Put ~/.codex/config.toml and ~/.claude/settings.json under change monitoring on shared machines, or at least review them after app upgrades.
• Allow only reviewed plugins. Where your agent supports an allow list for marketplaces and hooks, use it. See our walkthroughs of Codex plugins and the local proxy that blocks risky tool calls.
• Add a runtime guard. AgentBeam is the agent security platform from the explainx.ai team. It stops AI agents before they take dangerous actions, which covers cases where an instruction arrived through a source you did not choose. Our Beam CLI guide shows the open-source side.

Also see how a similar permission story played out with Apple's full disk access prompts for AI agents. The common thread is that agents get more reach every month, and consent has to keep up.

What is still open

• Whether Postman will change the upgrade behavior, and when.
• Which Postman releases carry the auto-existing-upgrade path, and whether it ran for all signed-in users or a feature-flag group.
• Whether the Codex hook approval is visible anywhere in Codex's own interface after install.
• How many people were affected. The issue has dozens of reactions, but reactions are not a count of installs.

We will update this post if Postman responds or the issue changes. If you have checked your own files and found something different from the author's logs, that is useful evidence, and the issue thread is the place Postman will read it.

Related reading

• Skills vs hooks vs prompts: when to use each
• What are agent skills? A complete guide
• What is MCP, the Model Context Protocol
• Codex plugins repository: Figma, Notion, iOS and web apps
• Hugging Face SafeAgents: block risky coding-agent tool calls
• Beam CLI: open-source agent security skills
• Claude Code commands reference

Details reflect the GitHub issue and plugin README as read on November 3, 2026. Versions, behavior and Postman's response may change.