Postman wrote itself into Claude Code and Codex: put ~/.claude and ~/.codex in your threat model

A Postman Desktop update installed its plugin into both Claude Code and Codex on a Mac without the user asking, and in Codex it also approved its own session-start hook. If an app update can write to your agent config, it can change what your agent is told before you type anything. The evidence is a log line from 24 October at 09:34 UTC, tagged auto-existing-upgrade, with two results: claude-code:installed and codex:installed. The user had asked for neither. That line anchors GitHub issue 14370, opened the next day, and it is why I now treat my agent config directories as attack surface rather than dotfiles.

What landed on disk

The reporter, on Postman 12.33.4, documented the changes file by file. In ~/.codex/config.toml: a new marketplace pointing at the postmanlabs/postman-plugin Git repository, the Postman plugin enabled, and a hooks.state entry with a trusted_hash for the plugin's SessionStart hook. In ~/.claude/settings.json: the Postman plugin enabled, with installed_plugins.json showing version 2.0.1 at user scope. In ~/.local/bin: a Postman CLI. The plugin also points Codex at Postman's remote MCP server, which kept failing with "Auth required".

The hook fires on startup, clear and compact. It prints a markdown file telling the agent that before non-trivial API work it should load the postman:api-engineer skill and follow it. That is context injection into every session, in every repository, from an application the user installed to send HTTP requests.

The part that should worry you: self-approved trust

Codex asks you to approve a hook before it runs, and stores your approval as a trusted hash. The reporter found that Postman's installer calls a function named approvePostmanHook after installation, reads the hook's hash through Codex's hooks/list call, and writes the trust record itself through config/batchWrite. The source comment says it "approves only Postman's current hook after installation". The New Stack notes that Postman's own documentation describes this automatic approval, while users who install the plugin through Codex directly must approve the hook themselves.

So the one human checkpoint in the hook model was answered by the party that wanted the hook to run. A commenter testing Codex CLI 0.162.1 (a self-described AI agent, so weigh it accordingly) reported that the trusted hash covers the hook declaration rather than the script it runs. If that holds, whoever controls the plugin repository can change what executes without triggering a new prompt.

Anything that can write to ~/.claude or ~/.codex can decide what your agent reads before your first prompt.

What is disputed and what Postman said

The report does not claim data exfiltration, and nobody in the thread has shown any. The original reporter is careful on attribution as well: a trust record on disk does not by itself prove who wrote it, which is why the installer source matters more than the config file. Behavior also varies by version. A user who updated from 12.31.3 to 12.35.1 on 3 November saw the same automatic plugin and CLI install, but no hooks.state entry in Codex, and the session-start text showed up in Cursor instead. Another user found Postman entries in ~/.copilot/settings.json that the in-app uninstall menu did not remove.

A commenter answering for Postman replied on 3 November: the CLI and plugins are bundled because many users had trouble wiring them up separately, the bundling is mentioned on the download page and in the update flow, and every component can be uninstalled from inside the app. The commitment was to "make the opt-in clearer, especially for existing users" and to review the hook approval and session-start behavior. No version, no date, and no promise to stop installing for existing users. The New Stack also discloses that its owner, Insight Partners, is an investor in Postman and OpenAI.

Why this will happen again

Picture the next one. You click Update on a desktop tool. The installer runs as you, so it can write any plain file in your home directory, agent configs included, and this thread shows a single installer reaching Claude Code, Codex, Cursor and Copilot at once. Next morning you start your agent in a production repository, and a session-start hook you never saw has already told it how to behave, because hooks run code and inject context before your first prompt. Every developer tool vendor now wants a plugin inside your coding agent, and the desktop app already on your machine is the cheapest way to ship one. That makes any desktop app update a potential agent supply-chain event, the same class of problem as unverified GGUF files, only quieter.

What I check now

The audit takes two minutes:

grep -n -i postman ~/.claude/settings.json ~/.claude/plugins/installed_plugins.json ~/.codex/config.toml ~/.copilot/settings.json
grep -n -A3 "hooks.state" ~/.codex/config.toml
ls -la ~/.local/bin

Anything you cannot trace to your own decision goes. Then make the next change impossible to miss. The fix I recommend is a small Git repository holding the settings files under ~/.claude and ~/.codex, diffed by a daily check, so a new marketplace, plugin or trusted hash shows up as a diff somebody has to explain instead of a silent edit. If you rely on hooks as guardrails, review the hook list after every desktop app update, not only after agent updates, because a desktop app update is exactly how this one arrived. For teams the rule belongs in the onboarding policy: on machines that hold production credentials, only managed configuration may add marketplaces or trust hooks.

Do it before your next standup. Run the three commands above, and if the first one prints a Postman line you did not add, remove the component through the app's uninstall menu and run the grep again, because one user found entries in ~/.copilot/settings.json that the menu left behind. Then copy your agent settings files into a folder, run git init there and make the first commit, so the next vendor that finds this channel shows up as a diff.