Postman reverts agent-plugin auto-install and drops its Codex hook self-approval, but npm's default build still has it

Postman is backing out of the change that put its plugins into developers' coding agents without asking. On November 5, Postman organization member Preetham (GitHub: preethammavin) wrote in issue #14370 that the company "will be re-designing the experience with the right level of control. In the meantime, we are reverting this change." The same day, Postman engineers removed the code in the @postman/postman-plugin installer that approved Postman's own Codex hook. We reported last week that the installer did exactly that, using the same app-server calls as Codex's own hook review.

The fix took a detour, though, and the detour is still what npm serves by default.

What changed in the plugin repository

PR #149, merged on November 5 at 17:19 UTC, does two things. The first commit is titled "stop auto-approving the Codex session-start hook" and says it plainly: "The installer wrote trust for Postman's hook into the user's Codex config. The user must make that choice. Remove approvePostmanHook and its tests."

The second commit goes further and drops the hook from the Codex version of the plugin altogether. .codex-plugin/plugin.json now declares "hooks": {}, and hooks/codex-hooks.json is deleted:

   "skills": "./skills/",
-  "hooks": "./hooks/codex-hooks.json",
+  "hooks": {},
   "mcpServers": "./mcp.codex.json",

The reason given is mechanical rather than ethical: "Codex updates a git-marketplace plugin at session start, and every content change leaves the hook untrusted again." In other words, once the installer stopped approving the hook itself, Codex's trust check would have kept switching it off after every plugin update. Codex users still get Postman's skills and MCP server, but no longer the session-start text that tells the agent to load postman:api-engineer before "any non-trivial API engineering task".

Reverted, re-applied, not yet shipped

The npm registry shows the back-and-forth. Version 0.7.0, published at 21:09 UTC on November 5, contained the fix. At 23:50 UTC someone reverted PR #149, and 0.7.1 went out five minutes later. We downloaded both tarballs: 0.7.0 has no hook-approval code, while 0.7.1's dist/hosts/codex-hooks.js is back to calling config/batchWrite with the hook's current hash as trusted_hash.

The fix was re-applied on November 6 at 08:25 UTC together with a 0.7.2 version bump, but 0.7.2 was never published to npm. The next thing to appear there was 0.8.0-rc.0 on November 6, under the next tag. As of November 9, npx @postman/postman-plugin still resolves to latest, which is 0.7.1, the build with approvePostmanHook in it.

In practice that build should now find nothing to approve. It installs the Codex plugin from the repository's main branch, and main no longer declares a Codex hook, so by our reading of the code the approval step ends with "Postman's session-start hook was not found; hook approval skipped." The self-approval code is still in the default package. It just has nothing left to act on.

Cleaning up is a separate change

Reverting the desktop behavior doesn't undo installs that already happened. Postman's November 6 PR #148 admits that the installer's remove "used to take out only the plugin entry". In 0.8.0 it also removes Postman's marketplaces from Claude Code, Codex, Copilot CLI and Factory Droid when nothing else uses them, and it revokes Codex's approval of the session-start hook through the same config/batchWrite call the old installer used to grant it. That version exists on npm only as the 0.8.0-rc.0 release candidate. The default remove is still 0.7.1's.

What hasn't changed

The session-start instruction is gone only from Codex. On main, hooks/hooks.json still runs the session-start script for the other hosts, and the plugin's own developer notes list Claude Code, Cursor, Factory Droid and Copilot CLI among the routes that read it. session-start-context.md still opens with <EXTREMELY_IMPORTANT> and the same "load the postman:api-engineer skill" instruction.

On the desktop side, Postman's statement promises a revert and a redesign "with the right level of control". It doesn't name a version, and it doesn't say whether the redesigned flow will be opt-in for everyone, which is what commenters asked for. About eight hours after the statement, GitHub user a85 locked the thread, writing that the issue "is considered closed" and that they didn't "want to encourage ragebait". The thread was also where Postman had promised to post updates "as changes land".

The episode leaves one detail for agent hosts. Codex's hash-based hook trust didn't stop a vendor script from approving its own hook, as we described last week. But once that shortcut was gone, the same mechanism made the hook impractical to ship, and Postman removed it. On Codex, a trust check that re-asks after every update ended up enforcing consent.