TL;DR - On 25 October, a Postman user published a GitHub issue describing what he found after opening the Postman desktop app on his Mac. Postman's own log showed it had auto-installed plugins into two of his coding tools, Claude Code and Codex. It had edited his Codex settings file to add a Postman plugin marketplace, and it had written pre-approved trust values for a startup hook, so Postman instructions would load in his coding agent every session without asking. The issue is a consent story, and it is a perfect example of the letter R in S.E.C.U.R.E.: an update can change settings and consent grants in tools you thought it could not reach, so review what an install changed. What you need to do: after any app updates, review what changed in your other tools' settings and extensions. This weekend, check your coding tools for Postman plugin entries and a pre-trusted startup hook, and remove them. If any of that sounds like another language, hand this list to the tech-savvy person in your life.
| Fact | Detail |
|---|---|
| Issue published | 25 October 2026, postmanlabs/postman-app-support issue #14370 |
| App version investigated | Postman desktop 12.33.4 on macOS |
| Log file that recorded it | Postman's own main.log, entry source auto-existing-upgrade |
| What the log recorded | claude-code:installed and codex:installed |
| Settings file edited | ~/.codex/config.toml, the user's Codex agent settings |
| Hook matchers the plugin registered | startup, clear and compact, meaning it loads at the start of every session |
| Trust values written in advance | trusted_hash and trusted_content_hash, both pre-populated |
| Also found on the machine | a Claude Code plugin, a separate Postman CLI, and a remote MCP connection |
The most interesting security story I read this week is a GitHub issue. Not a breach announcement, not a ransomware claim. A single user, a log file, and an app that helped itself to other apps.
Here is what happened, as the issue records it. The user opened Postman on his Mac. Postman is a popular tool for building and testing APIs, and it has been on a lot of work computers for over a decade. Somewhere in that opening process, or in the update just before it, Postman ran an auto-install step. Its own log file recorded the results: claude-code:installed and codex:installed, plus the line Main: autoInstall.plugin.existing-user finished. Claude Code and Codex are AI coding agents, tools that sit in a programmer's terminal and write code on request.
Postman had not asked. The plugins landed in the user's coding agents because he opened Postman, and the log shows Postman treating that as an upgrade path it owned. He also found a Claude Code plugin, a separately installed Postman command-line tool, and a remote connection wired into his setup. Four new things on a machine, from one app opening.
This is an R-letter story. The R in S.E.C.U.R.E. is Review Security Settings, and the argument for it is exactly this: an update can change settings and consent grants in tools you thought it could not reach. The fix is a habit, and it takes about ten minutes.
The hook that approved itself
The plugin install is the part that made headlines among the people who read log files for a living. The part that should make everyone else pay attention is smaller and much more interesting.
The user's Codex settings file, ~/.codex/config.toml, had gained a Postman section pointing at a Postman plugin hosted on GitHub, with the plugin switched on. That is already bold. But the settings also contained a startup hook, a small instruction that fires every time the coding agent begins a session. The hook tells the agent: before responding to any non-trivial API engineering task, load the Postman API engineering skill and follow it. So every future work session in that tool would begin with Postman's own instructions in the agent's ear.
And here is the detail that turns this from clumsy into a genuine trust problem. Coding agents have a safety mechanism for hooks: a hook's instructions are hashed, and the hash is stored, so that if the hook's contents change later, the agent notices and asks the user to re-approve. It is a tamper seal. The Postman install did not wait for that approval. The hooks.state file had a trusted_hash and a trusted_content_hash pre-populated for its own hook. The installer wrote its own seal, approved its own instructions, and moved on. The user never saw a prompt.
An app reached into another app's settings, added instructions that load every session, and pre-approved its own instructions so nobody would be asked.
One thing the issue does not show, and I want to be careful here: there is no evidence in it that Postman scooped up anyone's API traffic and sent it home. The complaint, a fair one, is about consent and trust boundaries. The app extended itself into other tools and self-approved the extension. Whether anything sensitive ever left the machine is a separate question the issue does not answer, so I will not pretend it does.
Why your kitchen table cares
You may be thinking you have never opened Postman and never will, and mostly that is true for the households I write for. So why does this matter in a family newsletter?
Because the shape of this story is arriving in ordinary homes, one gadget at a time. Your TV app suggests installing its companion on your phone. Your antivirus wants to add a browser extension. Your phone manufacturer's computer app offers to "optimise" things. Every one of those is a program changing the settings of another program, and every one of those changes is a small consent grant you probably did not read.
Software updates are where this happens most. An update is sold as repairs: bugs fixed, holes closed. But an update is also a new version of a program's wishes, and some companies treat an update as permission to act on wishes you never agreed to. Postman's log literally filed this under auto-existing-upgrade. You already exist, the label says, so we upgraded you into the new arrangement.
The defender's habit is boring and it works. After anything updates, spend ten minutes reviewing. Look at the settings of the apps you actually use. Check for new extensions, new plugins, new connections, new things with permission to act. Most of the time you will find nothing. The times you find something, you will be glad you looked.
What to review this weekend
Thirty minutes, tops. None of this needs technical skill, and the two steps that do are clearly marked.
-
Find out whether this specific problem can reach you. On the computer in question, look for Postman in your list of installed applications, and think about whether anyone using that computer does coding work with AI tools. If Postman is not installed, this particular incident cannot have touched you, and you can skip to step 5. If it is installed and nobody in the house writes code, ask yourself why it is there, and consider removing the whole thing.
-
If Postman and coding tools share a machine, check the coding tool's settings for Postman entries. The file to look at is the Codex settings file, found in the
.codexfolder in your home directory, namedconfig.toml. Open it in any text editor and search for the word postman. Also open the Claude Code settings and look for a Postman plugin. Anything Postman-related in those files was almost certainly added by this install, and you did not add it yourself. (Ask the tech-savvy person in your life to do this one.) -
Check for the pre-approved startup hook. In the same
.codexfolder, look at thehooks.statefile. If it mentions Postman alongsidetrusted_hashortrusted_content_hashvalues, the installer pre-approved its own startup instructions on your machine, and those entries should go. The honest way to remove them safely is to have the plugin removed through the coding tool itself, which cleans up its own entries. (Also one for the tech-savvy person.) -
Review what else arrived with it. The issue's author found a Claude Code plugin, a separately installed Postman command-line tool, and a remote MCP connection, which is a standing link between the coding agent and Postman's servers. Check your installed applications for a Postman CLI, and check the coding agent's connection or MCP settings for anything Postman-shaped. Remove what you did not deliberately install.
-
Then do the general version, which is the actual habit. Postman is one app. The review habit covers all of them. Whenever any app on any device updates, and especially after a big version jump, spend ten minutes walking the settings of that app and the apps near it: extensions, plugins, connections, permissions, anything marked "integrations". Look for switches that turned on by themselves. Turn off what you never asked for. This is the R in S.E.C.U.R.E., it works on TVs and phones and laptops alike, and it is the only defence that catches this whole class of problem, because you cannot consent to a change you were never shown.
Key Takeaways
- Opening Postman auto-installed plugins into the user's coding agents, with the app's own log recording
claude-code:installedandcodex:installedunder an entry namedauto-existing-upgrade. - The installer pre-approved its own startup hook, writing
trusted_hashandtrusted_content_hashvalues into the settings so its instructions would load in every coding session without ever prompting the user. - The hook tells the agent to follow Postman's API engineering instructions before any non-trivial API task, registered to fire at session start, on clear and on compact.
- The install also added a Claude Code plugin, a separate Postman CLI and a remote MCP connection. One app opening, four additions.
- No claim about API data being sent to Postman's servers appears in the issue evidence. The verified problem is consent and trust boundaries.
- The fix is the review habit: after any app update, check what changed in your other tools' settings and extensions, and remove what you never asked for.
FAQ
Could this happen to my computer if I don't write code?
This specific incident needs Postman installed, and Postman is a developer tool, so most homes are clear of it. The habit is the transferable part: any app on any device can use an update to change settings elsewhere, and the review walk catches that regardless of the app involved.
Did Postman read people's code or send it anywhere?
The GitHub issue does not show that, and I am not going to claim it. What the evidence records is installation and self-approval: plugins added, a hook trusted in advance, a standing connection created. Whether data left the machine is a separate question nobody has answered in the issue.
How would I even know if an app changed another app's settings?
You would usually not, which is the point of the habit. The signs worth learning: a tool behaving differently after an update, new entries in a settings or extensions list, a new startup message from a tool you thought you knew. When something feels different, open the settings and look.
Is removing the plugin entries safe for a non-technical person?
Hand steps 2 to 4 to the tech-savvy person in your life rather than editing config files yourself. Step 1 and step 5 are entirely yours, and step 5 is the one that protects you next time.
What should I do first after any app update?
Open the app's own settings and look for anything new, then glance at the settings of the tools it works alongside. Ten minutes. You are looking for extensions, plugins, connections and permissions that switched on without a conversation.
My Take
The part of this that will stay with me is the tamper seal. Coding agents have a genuinely clever safety mechanism: every startup instruction gets a hash, and changed instructions lose the agent's trust until a human re-approves. Someone at Postman looked at that mechanism, which exists so that a human decides, and wrote the approval itself. That is a company deciding that its instructions deserve trust by default, in tools belonging to somebody else.
I expect the formal response will be that this was an onboarding choice made with good intentions. Maybe. But the bar for reaching into another program's settings has to be a prompt the user answers, every time, with no exceptions for companies that are sure you will say yes. Review your settings this weekend. It is ten minutes that catches what the prompt never showed you.
Mathew Clark Founder, SecureInSeconds Currently: reading other people's log files so you don't have to, and wishing apps would just ask Drafted with AI assistance - read, verified, and fixed by a human.
Further Reading
- Postman desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook - GitHub issue #14370 - the primary source: the log lines, the config edits and the pre-populated trust hashes
- An AI agent deleted a TV season. Least privilege is the fix - what happens when agents get more permission than they need, and the household fix
- AI agent sandboxing: why the sandbox matters - the practitioner-side story on keeping AI tools inside their lanes
- Social media privacy settings: the ten-minute walkthrough - the same review habit applied to the platforms you already use
