Glonce

Postman app auto-installed plugins into Codex and Claude Code, user reports

securityThe Glonce editorsHacker News🔥80Glonce rating80Impact62Novelty70Relevance85Surprise80Players55Credibility75
Postman app auto-installed plugins into Codex and Claude Code, user reports

A user of the Postman desktop app has filed a GitHub issue in the postmanlabs/postman-app-support tracker describing what they call a severe consent and trust-boundary problem. After opening Postman on a Mac (macOS, signed-in account, Postman 12.33.4) following a period of not using it, the author noticed recurring MCP authentication warnings in their coding agents and Codex repeatedly routing API work through Postman skills. Investigating on October 25, 2026, they found 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 starts with Postman's own log. In /Library/Application Support/Postman/logs/main.log, lines 11562-11563, at 2026-10-24T09:34:14.418Z, the entry reads PostmanAgentPluginServiceinstall: script completed, with source "auto-existing-upgrade" and results "claude-code:installed" and "codex:installed". A following line, autoInstall.plugin.existing-user finished, records outcome "installed", platform darwin, signedIn true and installer "script".

Codex's global ~/.codex/config.toml was changed. It now contains a marketplace entry for postman pointing at https://github.com/postmanlabs/postman-plugin.git, an enabled plugin entry "postman@postman", and a hooks.state entry with a trusted_hash and a trusted_content_hash for a session_start hook. The installed hooks/codex-hooks.json registers a SessionStart command (matcher startup|clear|compact) that prints hooks/session-start-context.md. That file tells the agent to load the postman:api-engineer skill before any non-trivial API engineering task, a list that covers designing, implementing, mocking, testing, monitoring, documenting or deploying an API or Postman Flow. The author says this explains the repeated skill announcements and is far broader than a user explicitly asking for Postman.

The author then read the installer source, pinned to revision 6c8e452e0f4237f4bcc0901cb1ac442dec707e49 of the Codex plugin. installer/src/hosts/codex.ts calls approvePostmanHook(system) after installing the plugin. installer/src/hosts/codex-hooks.ts gets the hook hash through hooks/list and calls config/batchWrite to write trusted_hash into hooks.state; a source comment says "Approves only Postman's current hook after installation". The author is careful here: the source establishes the approval attempt, but the trust record alone does not prove who created that specific record, so they do not present it as proof of a particular user interaction.

The remote MCP connection, mcp.codex.json pointing at https://mcp.postman.com/mcp, was enabled without a working authenticated connection. Codex logs show "MCP server startup failed" for server_name "postman" with the error "Auth required, when send initialize request". On the Claude Code side, ~/.claude/settings.json enabled postman@claude-plugins-official, and ~/.claude/plugins/installed_plugins.json recorded version 2.0.1 at user scope, with installedAt and lastUpdated both 2026-10-24T09:34:02.610Z. A Postman executable and its lib directory also sat in ~/.local/bin, with modification times matching the installation window.

The author says private paths, unrelated logs, account identifiers and credentials were left out, and that the report establishes unwanted integration and instruction changes but does not claim to establish data exfiltration. The sequence has not yet been reproduced on a clean Mac. The expected behaviour, in the author's words, is that installing plugins, adding remote connections and trusting hooks in other applications each require a clear, specific opt-in in the affected application.

The issue asks Postman to: treat this as a severe consent and security-boundary incident; stop automatic agent-plugin and CLI installation for existing desktop users pending explicit opt-in; remove installer-side self-approval of hooks; identify the release or feature flag and consent flow behind auto-existing-upgrade, including which other agents and files can be changed; provide a complete rollback path covering agent configs, hook trust, marketplaces, caches, MCP connections and the CLI, and respect removal without reinstalling; and narrow the startup skill instructions to explicit Postman requests. The author has since removed their local Postman installation and integrations after preserving the evidence, and asks for maintainer triage at severe priority.

The thread beneath the issue is heated, with many angry reactions. One commenter says they asked Postman about it on Discord and it did not seem to take the matter seriously. Another claims Postman changed its downloads page after the fact and points to a Wayback Machine snapshot from 2026-10-26 as showing no disclosure; that is a commenter's claim, not part of the report. A further commenter tested Codex and Claude Code hook-trust mechanisms in scratch config homes (Codex CLI 0.162.1, Claude Code 2.1.302). They report that Codex skips an untrusted hook by default, but that the trust record is a hash anyone with account access can compute and write, and that Codex also ships a --dangerously-bypass-hook-trust flag. The retrieved text of that comment is cut off.

Key facts

  • Postman's main.log (lines 11562-11563, 2026-10-24T09:34:14.418Z) records source "auto-existing-upgrade" with claude-code and codex both "installed" on Postman 12.33.4 for a signed-in Mac user.
  • Codex's ~/.codex/config.toml gained a postman marketplace, an enabled plugin and a SessionStart hook that tells the agent to load the postman:api-engineer skill before any non-trivial API engineering task.
  • The installer source calls approvePostmanHook after installing, using hooks/list and config/batchWrite to write a trusted_hash; the author says this shows an approval attempt, not who made the stored record.
  • The remote MCP connection to https://mcp.postman.com/mcp fails in Codex with "Auth required"; a Claude Code plugin (version 2.0.1) and a Postman CLI in ~/.local/bin were also installed.
  • The author does not claim data exfiltration and has not reproduced the sequence on a clean Mac; the issue asks Postman to stop auto-installs pending opt-in, drop hook self-approval and publish a rollback path.

Why it matters

Coding agents such as Codex and Claude Code run with broad access to a developer's files and tools, and their startup hooks can shape every session. The report describes a separate desktop application reaching into those agents' user-wide configuration on its own, adding an instruction that steers general API work toward Postman, and trying to mark that instruction as trusted. The author's argument is that an API client should not make itself the default workflow in other tools just because it was opened. Whether or not the details hold up across other machines, the case sits right on the line between a vendor's integration push and a user's consent over their own agent setup.

Who it affects

On the evidence given, the affected person is an existing Postman desktop user on macOS who is signed in and also has Codex or Claude Code installed. The report covers one machine on Postman 12.33.4. The source does not say how many users were affected, or which Postman versions or feature flag are behind auto-existing-upgrade; the author asks Postman to identify them. Developers and security teams who run coding agents next to Postman have the most reason to check.

How to use it

This is a bug report, not a product, but the author's evidence list doubles as a checklist. On a machine with Postman and a coding agent, look in Postman's main.log for "auto-existing-upgrade" and "autoInstall.plugin.existing-user". Check ~/.codex/config.toml for a postman marketplace, a "postman@postman" plugin and a hooks.state entry. Check ~/.claude/settings.json for postman@claude-plugins-official and ~/.claude/plugins/installed_plugins.json for the plugin record. Look for a Postman executable and lib directory in ~/.local/bin. The author asks Postman for an official rollback path covering agent configs, hook trust, marketplaces, caches, MCP connections and the CLI; the source does not describe one.

How solid is it

The issue is detailed and quotes primary artefacts: log lines with timestamps, config sections, hook text and installer source pinned to a specific revision. The author is explicit about limits: the trust record does not prove who created it, the sequence is not yet reproduced on a clean Mac, and no data exfiltration is claimed. It rests on one user's machine, and the author removed the installation after preserving the evidence. No Postman response, statement or maintainer reply is visible in the source text. Claims in the comment thread, such as the Wayback Machine point or the Discord exchange, are commenters' statements and are not verified here.

Risks and caveats

Do not read this as a confirmed data leak: the author says the report does not establish exfiltration, and the remote MCP connection failed on authentication in the author's Codex logs. The approval attempt is established by the installer source, not by proof that it produced the trust record on this Mac. The headline-level framing in some discussions of the story goes further than the issue text does. Separately, a commenter's tests suggest Codex hook trust is a stored hash that other processes running as the same account can compute and write, so the question of where hook consent really lives is wider than Postman. The thread is also full of angry commentary that should not be confused with evidence.

“I consider automatically changing unrelated coding agents and attempting to approve your own instruction hook a severe consent and trust-boundary problem.”

— Author of the GitHub issue in postmanlabs/postman-app-support