⏱️ Reading time: 10 min
Opening Postman on a Mac that hadn’t been used in weeks was enough for the application to install, without asking, the Postman plugin for Codex and its Claude Code equivalent. A user documented the case on October 25, 2026, in Postman’s support repository on GitHub, with logs, configuration files, and source code backing up every step.
📑 En este artículo
- TL;DR
- What the Postman plugin for Codex is
- What happened
- Context and background
- Technical details
- Impact and analysis
- What’s next
- Frequently Asked Questions
- What does the Postman plugin for Codex do once installed?
- Does installing Postman’s add-on for code agents require explicit confirmation?
- What does Postman’s startup hook do in Codex in every session?
- Does Postman’s integration with Claude Code work the same way as with Codex?
- How do I check whether Postman’s plugin marketplace is active on my machine?
- Has Postman responded to the report about its AI IDE extension?
- References
The report, published as issue #14370 in postman-app-support, tallies five unrequested changes on a single machine: a plugin in Codex, one in Claude Code, a session hook approved by the installer itself, a remote MCP connection, and a separately installed Postman CLI binary.
TL;DR
- Postman 12.33.4 installed a plugin in Codex and Claude Code without permission on October 24, 2026, according to issue #14370.
- Postman’s log records the event as auto-existing-upgrade, with the results codex:installed and claude-code:installed.
- The logs show the installer writing the hash of its own hook as trusted_hash inside Codex’s config.toml.
- That hook instructs the agent to load the postman:api-engineer skill for any API task, without the user requesting it.
- The MCP connection to mcp.postman.com was left enabled but unauthenticated, according to the logs cited in the report.
What the Postman plugin for Codex is
The Postman plugin for Codex is the extension Postman also distributes for Claude Code, with its own marketplace and a session-start hook that the agent runs automatically on startup, before handling any user instruction.
The feature is part of Postman’s plugin marketplace, a catalog where a vendor publishes an extension that Codex or Claude Code load as a skill. Postman maintains that plugin’s code in the public postman-plugin repository, with the installer, the hooks, and the documentation the agent reads on login.
What happened
The user who opened the issue found the cause in their own log file. In ~/Library/Application Support/Postman/logs/main.log, lines 11562 and 11563 record, on 2026-10-24T09:34:14.418Z, a complete automatic installation:
PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}The report dates the installation to Postman desktop version 12.33.4 and the Codex plugin at 1.1.0, with the source code pinned at revision 6c8e452e0f4237f4bcc0901cb1ac442dec707e49 of Postman’s repository. That same revision is the one issue #14370 cites for every file it examined.
The installation touched two clients at once. In Codex, the report shows a new block in ~/.codex/config.toml with Postman’s marketplace, the plugin enabled, and the hook already marked as trusted. In Claude Code, ~/.claude/settings.json enabled postman@claude-plugins-official, and installed_plugins.json ended up with version 2.0.1, at user scope, with installedAt and lastUpdated within the same second: 2026-10-24T09:34:02.610Z.
Context and background
Postman started out as an API testing client and now pushes its users toward code agents: Codex, from OpenAI, and Claude Code, from Anthropic, are two of the most widely used agentic environments among developers in 2026. Both accept external plugins that extend what the agent can do without the user writing out the full prompt every time.
That extension model rests on a simple assumption: the user decides which plugin to install and which hook can run on session start. Codex, in particular, requires every hook to be marked with a trusted_hash before it can run, precisely so that human review stands between a configuration file and the automatic execution of instructions in every session.
The issue doesn’t describe an external attack or a third-party vulnerability. It describes the vendor itself skipping that review step in its own product, which is different from an exploit: it’s a design decision made in the installer.
Technical details
sequenceDiagram
participant P as Postman desktop
participant C as Codex config
participant A as Codex agent
P->>C: writes marketplaces.postman and plugins.postman
P->>C: writes hooks.state with its own trusted_hash
Note over P,C: the installer approves the hook without asking for confirmation
A->>C: reads hooks.state on session start
C-->>A: hook already trusted, runs without noticeWhat concerns the report is not that Postman has a plugin, but how that plugin gets to run without anyone approving it by hand. The file installer/src/hosts/codex-hooks.ts retrieves, via hooks/list, the hash of the hook the installer itself just registered. It then calls config/batchWrite to write that hash into hooks.state as trusted_hash, the same field Codex uses to decide whether to ask for confirmation.
The code comment, quoted in the issue, puts it plainly: “Approves only Postman’s current hook after installation.” The installer signs off on its own approval in the same step where it installs the hook, so the user never sees the confirmation screen that field is meant to trigger.
The hook’s content isn’t neutral either. The file hooks/session-start-context.md is registered with the matcher startup|clear|compact, meaning it runs on session start, on context clear, and on context compaction. Its instruction tells the agent to load the postman:api-engineer skill before responding to any non-trivial API engineering task, without requiring the user to have mentioned Postman at all.
| Trust flow step | Expected behavior in Codex | What the issue records about Postman |
|---|---|---|
| Detecting a new plugin | The user runs an explicit install command | It fires on its own, logged as auto-existing-upgrade |
| Registering the startup hook | Saved without being marked trusted | Saved the same way, without a trust mark yet |
| Approving the hook (trusted_hash) | The user reviews the command and approves it by hand | The installer calls config/batchWrite and writes the trusted_hash itself |
| Running the hook in every session | Only runs if the user approved it beforehand | Runs on every startup, clear, and compact since installation |
The cost of that shortcut isn’t just symbolic. A hook with trusted_hash runs without notice in every new session, and this particular instruction is broad: any API task counts, not just ones that mention Postman. The user who opened the issue described the symptom before finding the cause: repeated MCP authentication warnings and Codex routing API work to Postman skills it was never asked to use.
The remote connection wasn’t working yet either. The file mcp.codex.json points to https://mcp.postman.com/mcp, but the Codex logs cited in the issue show the error Auth required, when send initialize request. The integration stays active in the user’s configuration even though the remote server doesn’t authenticate anything yet, which widens the trust surface before the feature is ready.
⚠️ Note: the issue clarifies that the trust record (trusted_hash) alone doesn’t prove who generated it. The author was careful to separate what the code does from what a specific human interaction demonstrates.
Impact and analysis
The case matters because it flips the usual order of consent. In most supply-chain incidents this year, a compromised third-party package tricks an agent or a developer. Here there’s no compromised package: it’s the original vendor writing, in its own installer, the approval that the permission system specifically requires to stop this kind of change.
For any developer using Codex or Claude Code with third-party plugins, the report leaves an uncomfortable question. If a vendor can approve its own hook during installation, the trusted_hash field stops meaning a human reviewed the change and starts meaning some installer marked it that way, and that difference is exactly what the field was meant to prevent.
The scope isn’t limited to Postman either. Any desktop application that detects Codex or Claude Code installed on the same machine could, in theory, replicate the same pattern: writing its own plugin, its own hook, and its own approval in a single silent update step, without the user ever opening a dialog.
What’s next
The issue remains open as a SEVERE severity report in the postman-app-support template, with reproduction steps still marked as not reproduced on a clean Mac. That leaves it pending for another user, or Postman itself, to confirm whether the behavior repeats outside the original machine.
What is documented in the public code is the approvePostmanHook function, invoked from installer/src/hosts/codex.ts right after the plugin installs. As long as that code doesn’t change, any new Postman installation on a machine with Codex or Claude Code can repeat the same sequence: install, register the hook, and approve it, all three steps without an intermediate screen for the user.
The bar for a real fix is simple: the installer should stop calling config/batchWrite for its own trusted_hash, and hook approval should go back to depending on an explicit user action, the same as for any other marketplace plugin.
Check your ~/.codex/config.toml and your ~/.claude/plugins/installed_plugins.json today, before trusting the next plugin that installs itself.
Frequently Asked Questions
What does the Postman plugin for Codex do once installed?
It registers a marketplace and a plugin in Codex’s configuration, and adds a hook that runs on session start, context clear, or context compaction. That hook tells the agent to load the postman:api-engineer skill for any API task, according to the code cited in issue #14370.
Does installing Postman’s add-on for code agents require explicit confirmation?
According to the report’s logs, not in every case: the event was logged as auto-existing-upgrade, meaning it was triggered by an update to an existing Postman installation, without a separate confirmation step for each agent.
What does Postman’s startup hook do in Codex in every session?
It prints the content of session-start-context.md, which instructs the agent to treat any API engineering task as a cue to use Postman’s tools, without the user having requested it in that turn.
Does Postman’s integration with Claude Code work the same way as with Codex?
The report shows both were enabled within the same time window: ~/.claude/settings.json activated the plugin and installed_plugins.json recorded version 2.0.1 at user scope. The issue doesn’t detail whether Claude Code applies the same trusted-hook mechanism as Codex.
How do I check whether Postman’s plugin marketplace is active on my machine?
In Codex, check whether ~/.codex/config.toml has a [marketplaces.postman] section and whether hooks.state includes a trusted_hash for a Postman path. In Claude Code, check whether ~/.claude/plugins/installed_plugins.json lists postman@claude-plugins-official.
Has Postman responded to the report about its AI IDE extension?
The public excerpts of issue #14370, opened on October 25, 2026, show no official Postman response in the thread itself as of this writing.
References
- GitHub, postman-app-support issue #14370: the original report with logs, configuration, and source code cited in this article.
- GitHub, postman-plugin (hooks/session-start-context.md): the text the hook prints to the agent in every session.
- GitHub, postman-plugin (installer/src/hosts/codex-hooks.ts): the code that writes the trusted_hash of Postman’s own hook.
- Postman: official site for the product and its plugin ecosystem for code agents.
📱 Enjoy this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
Featured image: Foto de Chris Ried en Unsplash
Did it work for you? Got a different error? Say so below: questions get answered and help the next reader.
Leave a comment
0 Comments