# Postman's installer tries to approve its own AI instructions

**Summary:** Postman's Codex installer attempts to trust its own startup hook. I want users to approve agent instructions separately from installing the integration.

- Canonical: https://markhuang.ai/news/postman-installer-self-approves-ai-hook
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-11-03
- Section: News
- Tags: Postman, Codex, Claude Code, AI Agent Plugins, Hook Approval
- Source: [GitHub / Postman App Support](https://github.com/postmanlabs/postman-app-support/issues/14370)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![An orange software parcel uses an arm attached to its own box to stamp a checkmark on its attached permission slip](https://cdn.markhuang.ai/news/postman-installer-self-approves-ai-hook/hero.webp)

*Conceptual illustration: Postman's installer combines plugin installation with an attempt to approve the plugin's startup hook.*

In an [October 25 report about Postman 12.33.4](https://github.com/postmanlabs/postman-app-support/issues/14370), a developer says opening the app led to unexpected changes in Codex and Claude Code. Postman is an API client, a tool for testing how software services communicate. The developer reports that it installed integrations into both coding agents, after which Codex showed authentication warnings and repeatedly loaded Postman skills for API work.

The detail I find most concerning is independently visible in the linked installer code: after installing its Codex plugin, Postman attempts to mark its own startup hook as trusted. I want installing an integration and approving its persistent instructions to remain separate decisions. When the installer handles both, I cannot treat a trusted hook as evidence that the user chose its instructions.

A startup hook runs when an agent session begins or at other configured session events. Here, it supplies instructions about which skills the agent should use. Those instructions can affect work outside the Postman window, so their approval deserves its own review.

## One Mac's report, backed by inspectable installer code

The issue author, indicava, supplies desktop log excerpts containing `auto-existing-upgrade` and results naming both Claude Code and Codex as installed. They also report user-wide configuration changes, a remote Postman connection and a separately installed Postman CLI. The observed sequence has not been reproduced on a clean Mac, according to the report.

The local evidence covers one machine. The public source lets us check what the installer is designed to attempt. At the revision identified by the reporter, [the Codex installation routine](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex.ts) calls `approvePostmanHook` after adding the plugin. The [approval routine](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex-hooks.ts) requests the hook's current hash, then attempts to write it into Codex's trusted-hook configuration.

That establishes an approval attempt in the code. It does not establish who created the particular trust record on the reporter's Mac, whether every Postman user received the same installation, or what consent screens may have appeared elsewhere. The reporter makes that distinction explicitly. The issue also says it does not establish data exfiltration.

## The instructions reach beyond explicit Postman requests

The pinned [startup text](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/hooks/session-start-context.md) tells the agent to load Postman's API-engineering skill before responding to any nontrivial API-engineering task. Its scope includes designing, implementing, testing and documenting APIs. Pure questions and trivial one-line edits are exempt, and the text explicitly says user instructions take precedence.

The text therefore leaves a user's direct request in charge. It still establishes a default for a broad category of work, even when the user has not asked to use Postman. I see a meaningful difference between offering an integration and making it the agent's starting point for general API tasks.

The integration has a useful purpose. [Postman's README](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/README.md) describes keeping API specifications, collections and related files alongside application code so agents can work with them. A team that chooses this workflow may welcome automatic skill selection. I want that choice to include knowing which instructions the integration adds to the agent.

## A correct hash cannot stand in for a user's choice

The approval code includes checks. It targets Postman's specific hook, verifies that the instruction file contains text, and rechecks that the hook's hash has not changed before writing approval. These checks help avoid approving different content during the operation. The code proceeds without asking the user whether to trust it.

The README is unusually direct about this: it says there is "no separate hook prompt or dump of its instructions." It also explains that installation can continue if the hook API is unavailable. The README documents the approval behavior explicitly.

The relevant path in the pinned code is:

```mermaid
flowchart TD
  A["Install the Codex plugin"] --> B["Inspect Postman's startup hook"]
  B --> C{"Hook eligible and checks pass?"}
  C -->|"Yes"| D["Attempt to write trusted_hash"]
  D --> E["Check whether approval took effect"]
  C -->|"No"| F["Skip approval or report a note"]
```

I object to putting the approval decision inside the installer. A hash identifies particular content. It cannot tell us whether the person using the agent chose to accept that content. For an integration that changes the agent's default approach to work, I want approval inside the affected agent, with the instructions available to read.

## Check instructions and data connections separately

The [Hacker News discussion](https://news.ycombinator.com/item?id=50354960) includes complaints about Postman's expanding scope and recommendations for alternatives. The thread shows frustration with the product's direction. It supplies no independent reproduction of this installation or proof of data theft.

[Postman's README describes data publishing](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/README.md#how-postman-builds-context): when a Postman folder is connected to a workspace, command-generated artifacts such as test results and request activity are published to that workspace. It also describes a hosted MCP server, a connection through which an agent can call Postman tools. Those documented paths deserve review on their own terms. Neither a configured remote connection nor an authentication failure proves that all API data was transferred.

For someone seeing unexpected Postman behavior in an agent, my first step would be to inventory the plugin, its startup instructions and trust state, then review remote connections and the separate CLI. Before relying on an uninstall path, ask whether it removes those changes and whether opening the desktop app can restore them. The issue requests a complete rollback; I have not tested one.

[OWASP's excessive-agency guidance](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) recommends limiting extensions and permissions and enforcing authorization in the systems that execute actions. The same preference for enforced boundaries runs through my [earlier analysis of agent network access](/news/claude-no-internet-live-network). For Postman's integration, I want the agent host to show the startup instructions and let the user accept or decline them before they guide a session.