Postman, Claude Code, and the Plugin You Never Installed

On 25 October 2026, a developer reported that updating Postman to version 12.33.4 silently installed Postman plugins into Claude Code and Codex, and registered its startup hook as trusted. It matters because a coding agent runs with your credentials and codebase, so anything that changes what it loads changes what it can do for you.

Key takeaways

• Postman 12.33.4 allegedly installed its own plugins into Claude Code and Codex during an ordinary app update, without an explicit opt-in step.

• The report says a Postman SessionStart hook was added to the agent's trusted list, so it runs before every session and steers API work towards Postman's skill.

• A two-minute audit of your settings files and plugin directories shows whether your machine is affected.

• Removal is straightforward: delete the plugin entry, the marketplace entry and the trusted hook record, then restart the agent.

• No evidence in the original issue shows API data being shared — that stronger claim circulates on social media but is not documented in the report itself.

What was actually alleged?

The allegation comes from a GitHub issue filed on 25 October 2026 by a developer using the handle indicava, titled with a severity marker and still open at the time of writing, with 453 reactions and 51 comments. A Hacker News thread on the same report reached 1,391 points and 461 comments, which is why the story travelled far beyond the people who use Postman daily.

According to the issue, the installer's own log records the event with the source field set to "auto-existing-upgrade", followed by claude-code:installed and codex:installed. In plain terms, the upgrade path itself triggered the plugin installs, not a separate action by the user. The reporter then found three concrete changes on their machine:

• Their ~/.codex/config.toml had gained a Postman plugin marketplace entry.

• That marketplace had an enabled postman@postman plugin.

• The hooks state had gained a trusted_hash entry for Postman's hook, which is the record that lets a hook run without asking again.

The hook in question is a SessionStart hook, and the report says it instructs the agent to load the postman:api-engineer skill before any non-trivial API engineering task. The issue also points to an approvePostmanHook step in the installer source, which appears to approve Postman's own hook programmatically rather than waiting for the user to approve it.

None of this has been independently reproduced in public at the time of writing, and the report describes one developer's machine. Treat it as a credible, specific allegation with receipts in the form of log lines and config diffs — not as a confirmed finding about every Postman installation.

Why does a quiet plugin install matter so much?

A plugin for an ordinary editor is a convenience. A plugin for a coding agent is a change to the agent's behaviour, and that distinction is the whole story.

First, a SessionStart hook runs before you type anything. By the time you see your first prompt, the agent has already loaded instructions you never reviewed. Second, a skill that loads "before any non-trivial API engineering task" does not just add a feature; it steers every API decision the agent makes towards one vendor's tooling. Third, the trusted record exists precisely to stop silent changes: the confirmation dialog is the one moment a user gets to say no, and writing your own entry into the trusted list removes that moment entirely.

As one commenter put it, the precedent is the problem: if a mainstream desktop app can change how your coding agent behaves during a routine update, then the trust boundary of the agent is whatever any installed app decides it is. That is a much bigger claim than "Postman added a plugin", and it is worth taking seriously even if you never use Postman.

How do I check my own machine?

You do not need to install anything to audit this. The check is read-only: it looks, it does not change. Run it in your terminal:

# 1. Claude Code: settings files and plugin directories
ls ~/.claude/plugins/ 2>/dev/null
grep -ri "postman" ~/.claude/settings.json ~/.claude/settings.local.json 2>/dev/null

# 2. Codex: the config file named in the report
grep -n -i "postman" ~/.codex/config.toml 2>/dev/null

# 3. Sweep both tool directories for any Postman mention at all
grep -rn -i "postman" ~/.claude/ ~/.codex/ \
  --include="*.json" --include="*.toml" 2>/dev/null | head -40

What the output means: no matches means no trace of Postman in either tool's configuration, and you can stop here. Matches in config.toml that mention a marketplace, a postman@postman plugin or a trusted_hash entry match the pattern described in the report. Matches elsewhere, such as an MCP server entry you added yourself, are a different thing — a plugin you installed deliberately is not the problem this article is about.

One honest limitation: this sweep covers the two tools named in the report and their usual config locations. If you run other agents, their plugin directories deserve the same five minutes, because the same technique would work there too.

What do I do if I find it?

Back up first, then remove the three pieces. The backup costs nothing and makes every later step reversible:

cp ~/.codex/config.toml ~/.codex/config.toml.bak
cp ~/.claude/settings.json ~/.claude/settings.json.bak 2>/dev/null

• Open ~/.codex/config.toml and delete the Postman marketplace entry, the enabled postman@postman plugin line, and the trusted_hash entry under the hooks state.

• In Claude Code, list installed plugins and uninstall the Postman one, then check ~/.claude/settings.json for any Postman hook entry and remove it.

• Restart both agents completely, so no already-loaded session keeps the old configuration in memory.

• Re-run the audit commands above and confirm the output is empty.

Do not stop at step 4. Open Postman itself and check whether its settings offer an option for the CLI or agent plugins, and switch it off if it does — otherwise the next update may simply reinstall what you just removed. If no such option exists, that absence is itself useful information to include in any bug report you file.

What has Postman said, and what is still unproven?

A reply in the GitHub issue, from an account that states no affiliation with Postman, says the CLI and agent plugins are bundled because users struggled to install them separately, that the bundling is noted on the download page and in the update flow, and that the plugins can be uninstalled from inside the app. The same reply says the team is going to make the opt-in clearer, especially for existing users, and is reviewing the hook approval and session-start behaviour. That is a meaningful concession on the opt-in question, but note what it is not: it is not a verified statement from Postman, and it does not address whether writing a trusted hook record was intended.

Equally important is what nobody has shown. The original issue contains no evidence that API keys, request bodies or production tokens were sent anywhere. The stronger version of the story — that Postman "shares all API data" — appears in social media threads and video explainers, but the details behind it are not spelled out in the issue itself. Repeating the stronger claim as fact would be exactly the kind of sloppy reporting this site tries to avoid. Similarly unproven: how many users were affected, whether the behaviour was a deliberate growth tactic or a packaging bug, and whether it affects every platform or only the reported setup.

How do I stop this happening again?

• Audit after every update. The two-minute sweep above is worth running after any update to an app that integrates with your coding tools, not just Postman.

• Put agent settings under version control. A git repo for ~/.claude and ~/.codex config turns a silent change into a visible diff. You will see the next surprise the day it happens.

• Treat hook approvals as security decisions. Never approve a hook you did not ask for, and periodically review the trusted list the same way you review SSH keys.

• Keep agent API keys scoped. A key that can only read a staging environment limits the damage if an agent ever does something you did not authorise.

• Prefer explicit installs. If a tool's plugin is worth having, installing it yourself takes thirty seconds and leaves no doubt about consent.

The deeper lesson is not really about Postman. Coding agents collapse the distance between "software installed on your machine" and "software acting on your behalf". Until agent tools treat plugin installs and hook approvals with the same seriousness as browser extensions or OS permissions, the audit above is part of basic hygiene — the equivalent of checking what is running at startup. Run it now, while the story is fresh, and keep it in your routine after that.

Originally published on LogicStack. Run the code examples right in your browser with our free interactive Python and SQL playgrounds — no setup, no sign-up.