If your API client can rewrite your coding agent's rules overnight, malware can too

Your API client should not quietly become the boss of your coding agent. That is the core of a developer security story that blew up in late October and early November 2026. Postman desktop, for some existing users, installed plugins into OpenAI Codex and Anthropic Claude Code without a clear opt-in, added a SessionStart instruction that pushed API work toward Postman skills, and shipped installer code that tries to approve its own hook trust record. On November 5 a Postman staff reply on the public GitHub issue said the company is reverting the change. Reverting future installs does not, by itself, wipe what is already sitting in ~/.codex and ~/.claude.

This article sticks to what the original report documented, what later users reproduced, what independent coverage confirmed, and what Postman itself wrote. Primary evidence is GitHub issue 14370 in postmanlabs/postman-app-support. Secondary coverage includes Notebookcheck (Nov 5, 2026), AI Weekly, Coderefer, and ctxsec summaries of the same thread. After the facts, a clearly labelled djcroman take section argues what this means for agent supply chain risk.

What the original report showed

On October 25, 2026 a developer posting as indicava opened issue 14370 with the title that names the problem: desktop auto installs Codex and Claude plugins, and the installer attempts to trust its own startup hook. The report is careful. It does not claim data was stolen. It claims unwanted integration and instruction changes across trust boundaries that should belong to the agent host, not to an unrelated desktop app.

The reporter pinned Postman desktop 12.33.4, Codex plugin 1.1.0, and Claude plugin 2.0.1, and linked the installed plugin revision 6c8e452. From Postman's own main.log on that Mac, at 2026-10-24T09:34:14.418Z, the log line is blunt:

PostmanAgentPluginService install script completed with source auto-existing-upgrade and results claude-code:installed and codex:installed. A follow up Main line records autoInstall.plugin.existing-user finished with outcome installed.

That wording matters. This was not a fresh download wizard. The path is labelled for existing users. Opening the app after an update was enough.

What changed on disk

In ~/.codex/config.toml the report shows a new Postman marketplace pointing at the postmanlabs/postman-plugin git repo, an enabled postman@postman plugin, and a hooks.state entry with trusted_hash and trusted_content_hash for a SessionStart hook. That is the record Codex uses to decide whether a third party hook may run.

The hook's session start context tells the agent, in substance, that before responding to any non trivial API engineering task, designing, implementing, mocking, testing, monitoring, documenting, or deploying an API or Postman Flow, it should load the postman:api-engineer skill and follow it. That is a broad default, not a narrow "only when the user asked for Postman" rule.

The same report shows Claude Code changes: ~/.claude/settings.json enabled postman@claude-plugins-official, and installed_plugins.json recorded version 2.0.1 with install timestamps matching the Postman log window. A Postman CLI binary appeared under ~/.local/bin with matching mtimes. An MCP entry pointed at https://mcp.postman.com/mcp and, in the reporter's logs, failed with Auth required because the user was not signed in for that connection.

The self approved hook is the sharp edge

Plugin install alone would already be a consent failure for many teams. The installer trying to approve its own hook is worse, because hook trust is the control that is supposed to stop exactly this class of surprise.

The issue links installer source in the pinned plugin revision. installer/src/hosts/codex.ts calls approvePostmanHook after install. installer/src/hosts/codex-hooks.ts computes the hook hash via hooks/list and writes hooks.state through config/batchWrite. A source comment says the function "Approves only Postman's current hook after installation." Postman's own plugin docs, as quoted in coverage, state that the installer approves the hook for you. In Codex that approval is normally a user decision in the agent host.

Later technical comments in the thread tested how fragile that trust model is. An agent commenter showed that on a tested Codex build, a hooks.state record is just a file the same user account can mint with a text editor, and that Claude Code settings-file hooks can fire without a separate trust store in some non interactive paths. The point for readers is not that Postman invented file based config. The point is that a vendor installer writing into that file collapses the consent ceremony into a background upgrade.

Later reproductions widened the blast radius

The original Mac report was not alone. On November 3 another user, ronthedrummer, posted that opening an existing signed in Postman on macOS updated the app from 12.31.3 to 12.35.1 and again logged auto-existing-upgrade. That run installed the CLI plus Claude Code and Codex plugins, and recorded cursor:already-installed. The user said the SessionStart style text appeared in Cursor agent sessions. Another commenter found Postman entries in ~/.copilot/settings.json for the Copilot CLI, and said Postman's in app uninstall left Copilot residue behind.

Notebookcheck's November 5 write up summarizes the same facts for a wider audience: plugins into Claude Code and Codex without asking, startup hook pushing Postman skills, later mentions of Cursor and Copilot CLI, and no public evidence of data collection through this path. AI Weekly and Coderefer repeat the check commands developers should run against ~/.codex/config.toml, ~/.claude/settings.json, installed_plugins.json, and ~/.local/bin.

So the verified picture as of November 5 is: at least Codex and Claude Code were auto installed for existing Postman desktop users on Mac; Cursor and Copilot CLI appear in later user reports; the company messaging about what the download page always said is contested by Wayback snapshots cited in the thread; and nobody in the public report chain has produced evidence of exfiltration.

What Postman said, and what a revert does not do

On November 3, Postman's product reply on the issue said the company bundles the CLI and agent plugins because many users struggle to wire them up separately, that the download page and update flow mention this, and that components can be uninstalled from inside the app. The same reply said Postman would make opt in clearer for existing users and review hook approval and session start behavior.

On November 5, staff account preethammavin wrote that the intent was to simplify setup for developers who use agents to build APIs, that community feedback showed the messaging was not enough, that Postman will redesign the experience with the right level of control, and: "In the meantime, we are reverting this change."

That sentence is good news for future launches. It is not a cleanup tool. Notebookcheck is explicit that reverting the change does not remove what is already installed. Users still need to run Postman's uninstall path, or npx @postman/postman-plugin status / remove, and then re check the config files by hand. Several commenters said in app uninstall left residue in at least one agent host.

The issue was later locked by a Postman account after the revert statement. Locking a thread is not the same as publishing a full incident report with affected version ranges, platforms, and a forced cleanup. As of the coverage used here, Mac is the platform with concrete logs. Windows verification steps were still being asked for in the comments.

How to check and clean up

If you have used Postman desktop recently, treat this as a config audit, not as panic.

1. Search for postman in ~/.codex/config.toml. Look for marketplaces.postman, plugins."postman@postman", and any hooks.state entries naming Postman. 2. Search ~/.claude/settings.json and ~/.claude/plugins/installed_plugins.json for postman@claude-plugins-official. 3. Check ~/.copilot/settings.json and related Copilot plugin folders if you use Copilot CLI. 4. Look for a postman binary under ~/.local/bin. 5. In the Postman app, use Help, Postman CLI and Plugins, uninstall. Then run npx @postman/postman-plugin status and, if needed, remove. Re grep the files afterward. 6. Restart Codex, Claude Code, Cursor, or Copilot CLI so they reload clean config.

No public report in this chain claims chats or API secrets were uploaded because of the plugin. The failure mode that matters for most teams is instruction and trust boundary takeover: a third party process wrote the rules your agent loads at session start.

djcroman's take: if a vendor can rewrite your agent overnight, malware can too

This section is opinion. Everything above is reported fact. What follows is how djcroman reads it.

Hot take: if your API client can rewrite your coding agent's rules overnight, malware can too.

Coding agents are becoming the new shell. They read your repo, hold tokens, call tools, and increasingly sit in the middle of how software gets written. The security model for that shell is still immature. We spent twenty years teaching users not to run random .exe files. We have not yet taught teams that any process with write access to your home directory can become a persistent prompt injection with a trusted_hash.

Postman's move is especially revealing because it did not need a zero day. It used ordinary user level file writes during a routine desktop update. The installer even tried to complete the consent step for itself. That is the same path a malicious updater would love: land a plugin, mint trust, steer the agent toward an MCP or skill you control. The difference between "growth experiment" and "malware" is intent and disclosure, not the file system mechanics.

There are fair counterarguments. Postman says it wanted to reduce setup friction. Many developers do struggle to connect MCP servers and skills. An honest opt in checkbox on first launch would have been a boring, acceptable product choice. Bundling for brand new installs with a clear prompt is different from auto-existing-upgrade rewriting machines that already had a workflow. And Postman did eventually say it is reverting, which is more than some vendors do when they ship dark patterns.

Still, the industry lesson is larger than one company. Agent hosts that store trust in ordinary config files under the same UID as every Electron app are inviting supply chain theater. Endpoint security vendors are already shipping AI kill switches for rogue agents. That market exists because enterprises can see the blast radius. Developer laptops are the soft underbelly: one Postman update today, one compromised Adobe updater tomorrow, one "helpful" browser extension next week.

So the practical stance for teams should be harsh and simple. Treat agent config directories as sensitive as SSH keys. Alert on unexpected writers. Prefer agent hosts that keep hook trust out of reach of random desktop apps. And assume that any vendor which ships silent cross app installs once will need a long probation before it is trusted with the same machine again.

What you can do now

• Audit ~/.codex, ~/.claude, ~/.copilot, and related agent folders for Postman entries after any Postman desktop update.
• Remove leftovers with the official remover, then verify by hand. Do not trust a single uninstall click.
• Ask vendors in writing whether their desktop apps write to other products' config trees, and ban silent existing user upgrades in procurement.
• Put file integrity monitoring on agent trust stores the same way you watch authorized_keys.
• For this incident specifically, read issue 14370 and the Notebookcheck summary before you decide whether Postman stays on your managed image.

Sources

• GitHub issue 14370: Desktop auto installs Codex/Claude plugins; installer attempts to trust its own startup hook
• Notebookcheck: Postman added itself to Claude Code and Codex without asking (Nov 5, 2026)
• AI Weekly alert on Postman desktop silent plugin install
• Coderefer: how to check and remove the Postman plugin
• ctxsec item summary of the same incident
• Pinned Postman plugin revision referenced in the issue