Postman Wired Itself Into Claude Code and Codex. Audit Your Agent's Hooks in 10 Minutes.
A bug report about an API client exposes the weak spot in every agent's review gate, and the ten-minute audit that closes it
The big coding agents now ship with a safety step for the scripts they run on their own. Codex won't run a new hook until you approve it. Claude Code lets you turn plugins and hooks on and off by scope. These gates rest on one quiet assumption: the person clicking "approve" is you.
A bug report that drew hundreds of upvotes on Hacker News on November 3 says that assumption broke. According to issue #14370 on Postman's tracker, the Postman desktop app installed its own plugins into both Claude Code and Codex during an upgrade, and its installer code then tries to write the approval for its own startup hook.
Nobody has shown that data left anyone's machine. That is not the point. The point is where the approval lives, and who else can write to it.
The result is a shift in how to think about agent safety. Your agent's config folder is no longer a private settings file. It is a shared surface that other software on your machine can edit, and the gate only counts if you check what is already behind it.
What the report says, and what it doesn't
Here is the claim in plain terms, from the issue itself.
GitHub user indicava filed the report on October 25 against Postman Desktop 12.33.4 on macOS. Postman's own log, they write, shows an install tagged auto-existing-upgrade that put three things on the machine:
- A Postman plugin in Codex, with a Postman MCP server (MCP is the Model Context Protocol, the standard way agents connect to outside tools) and a SessionStart hook, a script that runs every time an agent session opens.
- A Postman plugin in Claude Code, installed at user scope, meaning it loads in every project.
- A Postman command-line tool in
~/.local/bin.
Two details turn this from "unwanted install" into something worth your attention.
The first is what the hook says. It tells the agent to load a Postman skill "before responding to any non-trivial API engineering task." A skill is a packet of instructions an agent reads before it works. So the hook does more than add a tool. It steers how your agent approaches a whole category of work, every session, whether or not you asked for Postman.
The second is the approval. The reporter points to installer source in which a file called codex.ts calls a function named approvePostmanHook after installation, with the code comment "Approves only Postman's current hook after installation." At that commit, the helper in codex-hooks.ts writes the hook's fingerprint into Codex's trust settings when its conditions are met. The reporter is careful here too: the code shows the approval attempt, but the trust record on their machine doesn't by itself prove which run created it.
Now the honest part, because the Hacker News headline went further than the evidence. The thread title says Postman "attempts to share all API data." The issue does not say that. The reporter writes that it "does not claim to establish data exfiltration." The Codex log shows the remote MCP connection to mcp.postman.com failing with "Auth required," so that connection attempt did not complete. The reproduction is marked as not yet verified on a clean Mac, and no Postman staff reply was visible on the issue when this was written.
So treat it as a credible, well-documented report, not a proven incident. The lesson holds either way.
Why the review gate is the weak spot
Think of a hook approval like the guest list at a building's front desk. The desk checks every visitor against the list. That works well until a visitor can walk behind the desk and add their own name.
Here is how the gate works in Codex. Its hooks documentation says new or changed hooks are "marked for review and skipped until trusted," and that Codex "records trust against the hook's current hash." A hash is a fingerprint of the file. If the hook changes, the fingerprint changes, and Codex asks again.
That design is sound against one threat: a hook that changes after you approved it. It does nothing against a program that writes the fingerprint for a hook you never saw. The trust record sits in your config, and your config is a file. Any program running as your user account can write to it. The Postman desktop app runs as your user account.
Claude Code has the same shape of risk. A plugin can carry far more than a skill. Per the plugin reference, one plugin can bundle hooks, MCP servers, agents, skills, and a bin/ folder whose files land on the agent's PATH (the list of folders your shell searches when you type a command), so the agent can run them as plain commands. A plugin that loads at user scope brings all of that into every project you open.
None of this is a bug in Claude Code or Codex. Both tools assume the operating system protects your home directory from other people. They cannot protect it from other software you installed and run as yourself. That gap is the one Postman's installer walked through, and it will not be the last tool to do it. Every desktop app that wants to "work with your AI agents" now has a reason to write to the same folders.
The audit: what to check this week
This takes about ten minutes per machine. You are building an inventory, not hunting for malware.
1. List every plugin Claude Code loads
Run this from your shell:
claude plugin list
The command reference says the output groups plugins by how they load: installed from a marketplace, session-only, found in a skills directory, and synced from your claude.ai account. Add --json and each entry shows its scope and whether it is enabled, which makes it easy to spot something at user scope you don't remember adding.
For anything you didn't install on purpose, turn it off or remove it:
claude plugin disable <plugin>
claude plugin uninstall <plugin>
The enabledPlugins setting does the same job in a settings file, per scope, which is the better choice if you want the decision written down where a teammate can see it (settings reference).
2. Read your trusted hooks in Codex
Open Codex and run /hooks. In the desktop app, it is under Settings, then Hooks. The docs say this view shows every hook source and lets you review, trust, or disable individual hooks.
The thing to look for is not "untrusted hooks." Codex already skips those. Look at what is already trusted, and ask for each one: did I approve this? A hook you have no memory of approving is the finding.
If you don't use hooks at all, the docs give a switch for config.toml:
[features]
hooks = false
3. Check what runs at session start
SessionStart hooks deserve extra attention because they run before you type anything. In Claude Code, setting disableAllHooks in your own settings turns off user, project, local, and ordinary plugin hooks at once, according to the settings reference. Hooks your organization manages, and hooks from plugins it force-enables, keep running. That is a blunt tool. It also stops hooks you wrote on purpose, such as formatters or safety checks. Use it to test whether a strange behavior goes away, then turn hooks back on and remove the specific one you don't want.
4. Look in your PATH
The Postman report included a CLI dropped into ~/.local/bin. Check that folder, and any bin/ folders inside installed plugins, for commands you don't recognize. An agent will happily run a command it finds there.
5. For teams: move the decision out of user files
If you manage a team, the user-level files are the wrong place to enforce anything, because every app on the laptop can write to them. Claude Code's managed settings sit above user settings and can't be overridden from them. Two managed-only keys matter here: strictKnownMarketplaces, which allowlists where plugins can come from, and allowManagedHooksOnly, which blocks ordinary user, project, local, and plugin hooks while keeping the ones your organization manages or force-enables (settings reference). Codex documents a similar route: admins can enforce the hooks setting in requirements.toml, and managed hooks are trusted by policy rather than by a per-user record (hooks docs).
Expect a few plugins you forgot you installed, and maybe one you can't place. That one is the finding.
What this doesn't solve
A few honest limits.
An inventory is a snapshot. The Postman install arrived through an app upgrade. The next upgrade of any desktop tool can do the same thing. Re-run the list after you update tools that advertise "AI agent integration," or put the check in a weekly script.
Managed settings need an admin. The strongest fix, moving plugin and hook policy into managed settings, only exists if your organization deploys it. Solo developers are left with the manual audit.
Some of this is still one person's report. If Postman explains the auto-existing-upgrade flow, the details may change. The audit stays useful regardless.
Turning everything off has a cost. Hooks are how many teams enforce formatting, block dangerous commands, and log agent actions. Disabling all of them to be safe removes your own guardrails too. Remove the specific thing you don't want.
The question to ask about every agent integration
The useful mental model is simple. Every agent gate has two parts: the check, and the record the check reads. Vendors have spent the year hardening the check. The record is a file in your home directory.
So when a tool offers to "set up your AI agents for you," ask one question before you click: will it ask my agent's permission, or will it write the permission itself?
You can find out in ten minutes. Run claude plugin list, open /hooks, and read what is already trusted. What you do with the answer is up to you.
Sources: Postman issue #14370 (read November 3, 2026), Hacker News thread, Codex hooks documentation, Claude Code plugin commands reference, Claude Code plugin manifest reference, Claude Code settings reference, Postman installer source at commit 6c8e452.