🚨 Postman Auto-Installed Plugins: Codex & AI Security—What Now
Learn what Postman auto-installed plugins (Codex & AI Security) prove—plus why agent hook trust matters. Get practical steps for software consent.
When an App Changes Your AI Tools Without a Clear Opt-In
A desktop app shouldn't quietly change how your other software behaves. That's the concern behind a November 2026 Postman issue: a user reported that launching Postman on macOS was followed by installations and configuration changes involving Codex, Claude Code, a Postman command-line tool, and - later in another report - Cursor.
The changes described included agent plugins, startup instructions, and an MCP connection. The reporter also found installer code that appears to try to approve a Postman hook in Codex.
The key distinction here is between a product integration and a consent failure. Bundling an integration can be reasonable. Installing it into a different app, changing its configuration, or authorizing a startup hook is another matter - one that affects trust, scope, and the security posture of software the user didn't "choose" at that moment.
At the same time, the reports don't show that Postman stole data, and they don't establish that every user was affected. The evidence is tied to specific Macs and versions, and it looks like the behavior may have changed between reports.
This article separates what the reporters observed from what's still unverified. It also explains why agent hooks and configuration files matter, and it lays out a practical response for users and product teams. The point isn't to label anyone from a comment thread. It's to figure out where the trust boundary should be - and what responsible install behavior should look like.
What did Postman reportedly install?
The first report describes Postman desktop version 12.33.4 on macOS. According to the issue, launching the signed-in desktop app triggered a logged auto-existing-upgrade process. The app's own log recorded successful Codex and Claude Code plugin installation.
The reporter then found changes in the user-level configuration for those agent tools, along with a separately installed Postman CLI executable.
A later user described a similar sequence on a different installation after Postman updated from 12.31.3 to 12.35.1. Their logs recorded the CLI installation and plugin installation for Claude Code and Codex. Cursor showed up as already installed rather than newly installed in that launch.
That distinction matters: the later report supports the claim that the installation ran on another Mac, but it doesn't prove that the same launch installed Cursor.
The reported components
The initial report described several separate changes:
- Codex: A Postman marketplace source and an enabled plugin appeared in the user's global configuration. The plugin registered a session-start hook with instructions to load a Postman API engineering skill for broad API tasks.
- Claude Code: The reporter found an enabled Postman plugin in settings and an installation record for a user-scoped plugin.
- Postman CLI: A Postman executable and its library directory appeared in the user's local binary directory around the same installation window.
- MCP configuration: Codex was configured to connect to Postman's remote MCP endpoint. The reporter's Codex logs showed authentication failures, not a successful authenticated session.
- Cursor: In the later report, the installer logged Cursor as already installed. The user also described a Postman marketplace plugin and MCP configuration in Cursor, but did not attribute their initial installation to that launch.
These components shouldn't be treated as one permission. Installing a CLI alongside a desktop app is not the same as installing a plugin inside an AI coding agent. Adding an MCP server connection is not the same as enabling a local startup hook. Each affects a different app and leads to different security and operational outcomes.
Why existing-user upgrades are the key detail
Both reports point to an auto-existing-upgrade path. In the later account, the logs showed that fresh-download checks were skipped, while existing-user checks were the ones that ran. That suggests the behavior wasn't limited to someone choosing an integration during a brand-new setup.
Postman's response in the issue said the CLI and agent plugins were bundled to reduce setup friction. It also said the company disclosed this on its download page and in the update flow, and that components could be uninstalled inside the app. It added that Postman would make opt-in clearer for existing users, and review hook approval and session-start behavior.
That said, the intent explanation doesn't fully answer the core product question: what specific user action authorized each change in each host application? A notice in a download or update flow may explain what's being bundled. It doesn't automatically prove an explicit, informed choice to alter a separate agent's global configuration.
Why do agent hooks and configuration changes matter?
An AI agent plugin can do more than add a menu item. Depending on the host, it can provide skills, instructions, tools, remote connections, or hooks that run at particular times in a session. A startup hook can shape what the agent sees before the user asks a question. In that context, installation and authorization are meaningful security and product decisions - even if the plugin itself is legitimate and there's no allegation of malicious behavior.
In the initial report, the Codex hook ran at session start. The instructions directed the agent to load a Postman API engineering skill before responding to a wide range of non-trivial API tasks. The scope described included designing, implementing, mocking, testing, monitoring, documenting, or deploying APIs - broader than a user explicitly requesting Postman for a single, specific task.
Installation, execution and trust are different steps
It helps to break the flow into four steps:
- Install: Files or package records are added to the agent's environment.
- Configure: The host is told where the plugin, marketplace item, or MCP server is located, and whether it's enabled.
- Authorize: The host or user decides whether hooks and tools are allowed to run.
- Execute: The integration actually runs, makes a connection, or changes the agent's behavior.
Evidence for one step doesn't prove the others. A plugin being listed as enabled doesn't, by itself, prove that a hook executed. An MCP endpoint appearing in a configuration file doesn't prove authentication succeeded. A trust record in a config file doesn't prove which person or process created it.
The issue's first report says installer source code invokes a function to approve the Postman hook after plugin installation. It also cites code that requests hook information and writes a trust record to Codex configuration. That suggests an installer-side attempt in the source revision the reporter reviewed.
What it doesn't prove is whether a user saw and accepted a consent prompt - or which interaction created any resulting trust record.
A later report described a different state: plugin configuration was written, but no trusted-hook record appeared in the Codex configuration the reporter examined. A commenter's local tests on particular Codex and Claude Code versions were also meant to show that host behavior can depend on the execution path and trust settings. Those tests are useful context, but they're not proof of what happened on every reported machine or in every release.
The real boundary is control over another application
The concern isn't that an API client offers an agent integration. It's that a desktop app may initiate changes in other programs without a clear, specific choice from the person who actually owns those programs.
This matters even more when the change is global to a user account - because it can affect future sessions across unrelated projects.
A startup instruction can also steer product behavior without "executing code" in the usual way. If an agent is nudged toward routing broad API work through one vendor's skill, the user's default workflow changes. That may be fine when requested. As an implicit default, it reduces user control and makes the agent's behavior harder to explain later.
What does the evidence prove - and what does it not prove?
The strongest parts of the evidence are local and concrete: timestamped desktop logs, configuration entries, plugin installation records, a CLI file with a matching modification time, and source code pinned to a specific plugin revision. A second user provided logs from a later desktop version showing a similar existing-user installation path.
Taken together, those details support treating the behavior as a consent and trust-boundary issue rather than dismissing it as a documentation misunderstanding.
But incident analysis also needs limits. The first reporter explicitly said the sequence hadn't been reproduced on a clean Mac. The later account adds another affected environment, but it still doesn't show how many users were affected, which feature flag controlled the behavior, or whether every agent host followed the same path.
What the reports support
Based on the source material, it's reasonable to say:
- Postman's logs on at least two reported Macs recorded automatic installation activity tied to existing-user upgrades.
- The reported installations affected agent plugins and, in one account, the Postman CLI.
- The first reporter found global Codex and Claude Code configuration changes, and the later reporter found related Codex, Claude Code, and Cursor state.
- The first reporter identified source code that attempts to approve a Codex hook after installing the plugin.
- One reported Codex MCP connection failed because authentication was required. That indicates a failed startup attempt, not a successful authenticated connection.
- The startup instruction described in the first report had broad API-engineering scope.
Those findings are serious enough to justify a clear product response: identify the release and rollout conditions, explain the consent flow, document affected hosts, and provide a reliable removal path.
What remains unproven
The reports do not establish data exfiltration, credential theft, successful unauthorized access, or malicious intent. The issue author explicitly excluded a claim of data exfiltration. The authentication warnings indicate the reported MCP connection didn't initialize successfully in that instance.
The material also doesn't prove that every Postman user received the integrations, that every installation automatically trusted a hook, or that a specific user never saw a notice. The initial report includes a hook trust record; the later report does not. Those differences are exactly why release, configuration, and host-version details matter.
Public reaction in an issue thread isn't technical evidence. Calling software malware, speculating about legality, or recommending replacements doesn't show what the installer actually changed. The more useful questions are narrower: which code path ran, which files were modified, what the host executed, what data moved, and which user action authorized each step.
What should users and software teams do?
For users, the sensible move is a scoped audit, not panic. If you use Postman with Codex, Claude Code, or Cursor on macOS, check whether the integrations are present and whether you intended to install them.
Also: don't assume an installation record means a hook ran. Don't assume an MCP authentication failure means no configuration was written.
A practical user audit
Start by checking the settings and plugin-management interfaces for each agent you use. Look for Postman marketplace entries, enabled plugins, Postman MCP server records, and startup hooks.
On macOS, the reported locations included user-level Codex configuration under ~/.codex, Claude settings and plugin records under ~/.claude, and the CLI under ~/.local/bin. Paths and formats can change across versions, so verify against the agent's current documentation or interface before editing files.
Then review Postman's own installation and update logs for entries such as auto-existing-upgrade, autoInstall.plugin.existing-user, and autoInstall.cli.existing-user. Compare timestamps with file modification times. This helps distinguish changes made during the reported launch from older plugin installs or a pre-existing CLI.
If you decide to remove an integration:
- Use the agent host's plugin controls where available, then confirm the plugin or marketplace entry is no longer enabled.
- Remove the Postman MCP entry through the host's own settings, and verify it doesn't come back after restarting the app.
- Review hooks and their trust state separately. Removing a plugin package may not remove every configuration entry or trust record.
- Remove the CLI only if you're sure it isn't used by scripts or team workflows. Check the executable and related files before deleting anything.
- Re-check after launching or updating Postman again. If the desktop app silently reinstalls components, your "removal" isn't actually complete.
Avoid deleting whole configuration directories or copy/pasting cleanup commands from an unverified comment. Agent settings can include unrelated preferences, credential references, and project configuration. Back up first, make targeted changes, and if the Mac is managed for work, involve an administrator.
What responsible product behavior looks like
For vendors, the fix isn't just clearer release notes. A reliable consent flow should name the affected host, the component, the permissions, and the scope before making changes. It should default to no changes in other applications unless the user opts in.
If a checkbox covers a bundle, the scope has to be explicit - and the user should be able to distinguish the CLI, plugins, MCP connections, and hooks.
Hook approval should come from the agent host's actual user-consent mechanism, not from an installer silently writing a trust state. The important design property isn't that a trust value exists - it's that authorization happens through a process users can understand and control. Because agent-host trust models vary, vendors should test each supported host and document the behavior per version.
A complete remediation also needs to answer operational questions: which releases and feature flags triggered the existing-user path, which operating systems and agents were eligible, which files could be changed, and how users can remove each component without it returning. Removal should be persistent.
Startup instructions should be narrow enough to activate only when the user asks for Postman-specific help - not as a default for general API engineering.
Key takeaways
- Treat an app's changes to another application as a separate consent decision.
- Distinguish installation, configuration, hook authorization, and actual execution.
- Use logs and timestamps to determine what changed; don't infer data theft from an authentication error.
- Make removal complete and persistent, including agent configuration and any CLI.
- For vendors, disclose the integration scope and require explicit opt-in before modifying other tools.
Conclusion
The Postman reports describe a serious design problem: an existing desktop app reportedly installed integrations and altered configuration in other user applications, including an agent startup instruction with broad scope. That's enough to justify detailed triage and a specific opt-in flow. It's not enough to claim data theft or to assume the behavior happened for everyone.
The standard should be straightforward: installing an API client shouldn't silently make it part of another application's default workflow. Users should choose each meaningful integration, agent hosts should control hook authorization, and vendors should provide a complete, persistent rollback path. If you're a user, verify what actually changed before drawing conclusions. If you're on a product team, make consent specific before the next update.