Report claims Postman update silently installed trusted plugins into Claude Code and Codex

What the report claims

A developer posting under the handle indicava filed a GitHub issue on 25 October 2026 alleging that updating the Postman desktop app to version 12.33.4 installed Postman's own plugins into Claude Code and Codex without any opt-in step, according to a dev.to write-up. The issue was still open at the time of writing, with 453 reactions and 51 comments, and a related Hacker News thread reached 1,391 points and 461 comments — a measure of how far the story travelled beyond Postman's regular users.

The installer's own log appears to document the mechanism: dev.to reports it records a source value of "auto-existing-upgrade" followed by entries marking claude-code:installed and codex:installed. If accurate, the plugin installation was triggered by the upgrade path itself rather than by anything the user did.

What changed on the machine

The reporter documented three specific modifications. The Codex configuration at ~/.codex/config.toml gained a Postman plugin marketplace entry; that marketplace listed an enabled postman@postman plugin; and the hooks state gained a trusted_hash record for a Postman hook — the kind of entry that lets a hook run without asking the user again.

The hook is a SessionStart hook that, per the issue, tells the agent to load Postman's api-engineer skill ahead of any non-trivial API engineering task. The issue also points to an approvePostmanHook step in the installer source that appears to approve the vendor's own hook programmatically rather than waiting for the user to consent.

Why the trusted hook is the crux

Editor extensions are conveniences; agent plugins are behavioural changes. A coding agent operates with access to your credentials and your codebase, so whatever it loads shapes what it does on your behalf. A session-start hook fires before the first prompt, which means an agent can begin work carrying instructions the user never reviewed. And a skill that loads ahead of API tasks does not just add a capability — it nudges every API-related decision the agent makes toward one vendor's tooling.

The trusted-hook record is what most alarmed commenters. Its purpose is to serve as the single confirmation point before a hook runs; populating it programmatically removes the user's only chance to decline.

What is and is not established

Plenty remains unproven. The report describes one developer's machine, and dev.to notes there was no public independent reproduction at the time of writing. The issue contains no evidence that API keys, request bodies or tokens were transmitted anywhere; the stronger claim that Postman shares all API data circulates on social media but is not documented in the report itself. The number of affected users, the intent behind the behaviour, and whether it applies across platforms are all open questions.

A reply in the GitHub thread, from an account that disclaims any affiliation with Postman, says the CLI and agent plugins ship bundled because separate installation confused users, that the bundling is disclosed in the download page and update flow, and that the plugins can be removed from inside the app. The same reply says the team plans to make the opt-in clearer and is reviewing the hook approval and session-start behaviour. dev.to cautions that this is not a verified statement from Postman, and that it does not address whether writing the trusted record was intended.

How to check and clean up

The dev.to article offers a read-only audit: list ~/.claude/plugins/, then search Claude Code's settings files and ~/.codex/config.toml for any mention of Postman. If traces are found, back up the config files first, then delete the marketplace entry, the enabled plugin line and the trusted_hash record, uninstall the Postman plugin from Claude Code, and restart both agents so no live session keeps the old configuration in memory. The article adds a final step that matters: open Postman and check whether it offers a setting to disable the CLI or agent plugins, otherwise the next update may simply reinstall what was removed.

Why it matters

The core concern is precedent, not one vendor. If a mainstream desktop application can modify a coding agent's behaviour during an ordinary update — installing a plugin, registering a hook and marking it trusted — then the agent's trust boundary is effectively set by whatever software happens to be installed on the machine. Coding agents hold credentials and code, so anything that changes what they load changes what they can do. Whether this incident turns out to be deliberate, careless or a packaging bug, it exposes a gap: agent configuration files do not yet enjoy the protections applied to other security-sensitive settings. The practical lessons are to audit those files after updates, keep them under version control, and expect vendors building agent integrations to be held to explicit-consent standards from now on.