Postman AI Plugins: Audit What Your Dev Tools Install

You update a desktop app you have used for years. Nothing looks different. A day later your AI coding assistant starts its sessions with an extra instruction you never wrote, telling it to load a third-party skill before any API task. That is roughly what one developer described in a report against Postman's desktop app in late October, and it is why Postman AI plugins became one of the most discussed developer stories this week.

The interesting part is not one vendor. It is that our AI coding agents now read configuration files that any installed program can write to. This article sets out what was reported, what has and has not been shown, and a practical routine for auditing what your tools add to your agents.

What was reported about the Postman AI plugins

According to Neoteric's write-up of the GitHub issue, the reporter was running Postman desktop 12.33.4 on macOS. Postman's own log recorded an automatic install with the source auto-existing-upgrade, and results showing the Claude Code and Codex integrations as installed. In other words, the change arrived with an upgrade for an existing user rather than through a prompt the reporter remembers accepting.

The reported changes were:

• A Postman marketplace and an enabled Postman plugin added to ~/.codex/config.toml.
• A Postman plugin enabled in ~/.claude/settings.json, with a matching entry in the installed-plugins record.
• A Postman CLI placed in ~/.local/bin.
• A session-start hook that injects an instruction to load a Postman skill before non-trivial API engineering work.
• A remote MCP server entry, which in the reporter's case failed with an authentication error.

Gabriel Anhaia's analysis on DEV adds the detail that drew most criticism: the public installer code includes a step that approves Postman's own Codex hook, writing a trust record so the hook does not wait for the user's approval. Anhaia is careful to note that the code shows an approval attempt, not proof of who wrote the record on that particular machine.

What has not been shown

Some headlines said Postman tried to share "all API data". None of the sources I read supports that. Neoteric states plainly that the report documents unwanted configuration changes, not stolen data, and Anhaia notes the reporter did not show data leaving the machine. The reporter also said the sequence had not yet been reproduced on a clean Mac.

That distinction matters. Overstating an incident makes it easier to dismiss, and the real lesson here holds up without exaggeration.

How Postman has responded

RuntimeWire reports that Postman's head of product said the company bundles its CLI and agent plugins to ease setup, will make the opt-in clearer, especially for existing users, and is reviewing the hook approval and session-start behaviour that was flagged. No specific changes had been listed at the time of writing, so it is worth checking the issue thread and release notes before assuming anything has changed.

Why agent configuration is now a security boundary

A few years ago, a tool writing to your dotfiles was an annoyance. Today those files decide what your AI agent is told at the start of every session, which tools it may call, and which remote servers it connects to.

I covered the input side of this problem in prompt injection in AI agents: models treat text in their context as potential instructions. A session-start hook is a direct, trusted route into that context. Even when the vendor's intent is helpful, as Postman says it is here, three things change:

1. Behaviour. Your agent may follow a vendor's workflow instead of yours, without you noticing why.
2. Reach. A new MCP server can give the agent a way to send or fetch data from somewhere new once it is authenticated.
3. Consent. Hook approval prompts exist so a person decides what runs. A tool that pre-approves itself removes that decision.

For freelancers and small agencies, there is a client angle too. If you work on client APIs, you should be able to say exactly which tools can see that work.

A practical audit routine for your AI coding agents

These checks are read-only and take a few minutes. The paths below are the ones reported for macOS; adjust for your setup.

1. Look for unexpected entries

Search the agent configuration files for anything you did not add:

grep -n -i postman ~/.codex/config.toml
grep -n -i postman ~/.claude/settings.json
claude plugin list
ls -l ~/.local/bin

Do not stop at one vendor name. Read the whole plugin, hook and MCP sections and ask of every entry: did I add this, and do I still need it?

2. Review hooks and trust records

Session-start hooks deserve the most scrutiny because they run every time. In Codex, the reported trust records sit in the hooks.state section of config.toml; Anhaia suggests using the /hooks command to review and disable unwanted ones. Any hook you cannot explain should be off until you can.

3. Remove cleanly

For Claude Code, the DEV article lists claude plugin disable or claude plugin uninstall with the plugin name. Postman reportedly says the components can also be removed from inside the app. Anhaia warns that removing the desktop app itself may not remove these integrations, so check the config files again afterwards.

4. Put your agent config under version control

This is the step that turns a one-off clean-up into a habit. Neoteric suggests keeping agent configuration in a dotfiles repository. Once config.toml and settings.json are tracked, any silent change shows up as a diff the next time you look.

Common mistake: deleting things blind

The tempting fix is to paste a clean-up script from a forum or delete whole files. That can remove your own hooks, break plugins you rely on, or miss the trust record entirely. One article covering the story even pointed readers at the wrong file for the Codex trust data.

The fix is simple: back up the files first, remove entries one at a time, and diff before and after. If a vendor offers an official removal command, read what it does before you run it.

Key takeaways

• A Postman desktop upgrade was reported to add plugins, a CLI, a session-start hook and an MCP entry to Claude Code and Codex configuration without a clear prompt.
• The reports document configuration changes; they do not show API data leaving the machine.
• Postman says it will make the opt-in clearer and is reviewing the hook behaviour.
• AI agent configuration files are now a security boundary and deserve the same care as SSH keys or CI secrets.
• A five-minute read-only audit, plus version control for your dotfiles, catches silent changes from any tool.

FAQ

Did Postman steal API data?

No source I reviewed shows that. The reports describe configuration changes, and the MCP connection failed authentication on the reporter's machine. The concern is consent and control, not proven data loss.

Do I need to stop using Postman?

Not necessarily. Check your agent configuration, remove anything you did not choose, and watch for Postman's promised changes to the opt-in. Make the decision on what you find.

Does this only affect Claude Code and Codex?

Those are the two agents named in the reports. The wider point applies to any AI tool whose configuration other software can write to, so audit every agent you use.

If you would like a second pair of eyes on how your development tools, web systems or AI workflows handle trust and permissions, take a look at my cyber and e-commerce service or get in touch. I am always happy to talk through practical security for small teams.