Codex has a good rule: a hook from a plugin doesn't run until you've reviewed it. The catch is where your answer gets stored. It's a hash in a file in your home directory, and a report against Postman's desktop app says the installer wrote that answer for you.
A trust decision the trusted party can record for itself is not a decision. That's the class here, and it's bigger than one vendor.
What Was Reported
The reporter's logs from Postman 12.33.4 show a plugin install nobody asked for, with "source":"auto-existing-upgrade" and "results":["claude-code:installed","codex:installed"]. That's quoted in this audit, and a second write-up lists what changed: a marketplace and plugin entry in ~/.codex/config.toml, trusted_hash and trusted_content_hash under [hooks.state...] for a session_start hook, and postman@claude-plugins-official enabled in ~/.claude/settings.json.
The hook prints a block of instructions into each agent session, telling it to load a Postman API skill before non-trivial API work. So this is an app adding standing instructions to your agent, not a stolen credential. The report claims no exfiltration, and it isn't yet reproduced on a clean Mac. It rests on one user's logs, plus a commenter who reports the same on 12.35.1.
Postman's head of product told RuntimeWire on Nov 3 that opt-in will get clearer and the hook approval is under review. No fix or date so far.
The Mechanism
Codex skips plugin hooks until you trust the current hash, and a changed hook goes back to review. Fine design. But the report says the installer read the hash and wrote it back through Codex's own config API, in a function called approvePostmanHook. If that's right, the review ran to completion with nobody in the room.
Claude Code has less to bypass. A plugin's hooks merge with yours when the plugin is enabled, and enabling it is a key in settings.json, which is in your home directory too. As far as I can tell from the docs, a write there skips the /plugin install warning. And that plugin ID sits in the official marketplace, so an allowlist that includes the official marketplace doesn't help.
I've written about a relay script rewriting these same files. That was an attacker. This is a mainstream dev tool with an upgrade path, which is the part that should bother you: nobody has to be malicious. Claude Desktop drew a similar complaint in April over browser manifests.
Check It
Every marketplace and plugin should be one you added. Remove what isn't, then run it again to confirm nothing is left.
The Control
Move the decision to a file your user account can't write. In /etc/codex/requirements.toml:
= true
And in Claude Code's managed-settings.json (/etc/claude-code/ on Linux, /Library/Application Support/ClaudeCode/ on macOS):
Claude Code's docs say this doesn't trust hooks from plugins users enable themselves. Now an upgrade can write to your dotfiles and its hook still doesn't run.
The Tradeoff
It's blunt. Every hook a developer wrote for themselves dies too, so someone has to own a managed list, and on a personal laptop you may not bother. It's also narrow: a plugin's skills and the rest can still load, and anything running as you can still edit ~/.zshrc. Hooks are one door.
So I don't think root-owned config is the end state. It's a human-era permission holding a line for now. Agents need trust as a primitive of their own, a record that a process can't write just because it shares a user ID with you. My bet is that gets built, because this is exactly what agent tooling will keep hitting.
Until then, read your config after every upgrade. Nobody does that, which is why the installer could.