← Back to feed

Opening Postman’s desktop app triggered an automatic install of its plugin into OpenAI Codex and Anthropic’s Claude Code, and the installer then wrote a trust record approving its own session-start hook, according to GitHub issue 14370 in Postman’s app-support repository. The issue was opened October 25 by a user going by indicava and reached the Hacker News front page on November 3. It is one user’s evidence from one Mac and has not been reproduced on a clean machine.

What the log shows

Postman’s own main.log, timestamped October 24, 2026 at 09:34 UTC, records a plugin install with the source auto-existing-upgrade and results claude-code:installed and codex:installed. The user was signed in. The app was Postman desktop 12.33.4; the Codex plugin was version 1.1.0 and the Claude Code plugin 2.0.1.

Changes found afterwards:

• Codex global config. A postman marketplace pointing at a Postman git repo, an enabled postman@postman plugin, and a hooks.state entry carrying a trusted hash for a SessionStart hook.
• Claude Code. postman@claude-plugins-official enabled at user scope, with install timestamps matching the Codex install.
• Disk. A Postman CLI executable and library in ~/.local/bin.
• MCP. A remote server entry for Postman’s endpoint that failed on every start with “Auth required”, which is what produced the repeated authentication warnings.

The hook

The SessionStart hook prints a context file that opens by telling the agent to load the postman:api-engineer skill “before responding to any non-trivial API engineering task”, covering designing, implementing, mocking, testing, monitoring, documenting or deploying an API. That is a default route into Postman for broad categories of work, not a response to a request to use Postman. The file does say user instructions in AGENTS.md, CLAUDE.md or direct requests take precedence.

The self-approval is documented in the installer source. A function called approvePostmanHook queries Codex for its hook list and calls config/batchWrite to add the hook’s hash to hooks.state, with the comment “Approves only Postman’s current hook after installation.” Postman’s plugin documentation says the installer “approves the hook for you” on Codex. Developers who install the plugin through Codex directly must review and approve the hook themselves.

What it does not show

The HN title says the app “attempts to share all API data”. The issue does not say that. Its text states it “does not claim to establish data exfiltration”, and the one remote connection it found never authenticated. The reporter also notes the trust record alone does not prove who created it, and points to the installer code as the evidence of an approval attempt.

Postman’s documented install route is npx @postman/postman-plugin, which asks for confirmation outside a terminal unless --yes is passed. Neither documentation page mentions the desktop app upgrading existing users into the plugin. By November 3 the issue had five user comments and no reply, label or assignee from Postman.

Why it matters for agent users

Coding agents now read hooks and skills from user-level config files that any desktop app with write access can edit. The trust model behind Codex hooks assumes the user approves them inside the host tool. An installer that writes the approval itself removes that step.

The reporter’s requests are specific: stop auto-installing for existing users until they opt in, remove installer-side hook approval, name the release or flag behind auto-existing-upgrade, and publish a rollback path covering agent configs, hook trust, marketplaces, MCP connections and the CLI.