A developer reports that opening the Postman desktop app was enough to change how their coding agents behave. According to a GitHub issue summarized by The New Stack, Postman desktop 12.33.4 on macOS installed plugins into both Claude Code and OpenAI Codex, added a plugin marketplace and a remote MCP connection to Codex, and marked a Codex session-start hook as trusted, all without the developer opting in. The report is one machine, it has not been reproduced elsewhere, and Postman had not answered press questions at publication. Still, the mechanism it describes is worth understanding, because it is a new route by which software outside your agent can change what your agent does. This post separates what is documented from what is only alleged, and ends with a checklist you can run in a few minutes.
TL;DR
| Question | Short answer |
|---|---|
| Am I affected? | Only if you run Postman desktop alongside Claude Code or Codex. The report covers 12.33.4 on macOS; other versions and systems are unconfirmed. |
| Is there a fix? | No vendor fix or statement yet. Postman documents npx @postman/postman-plugin remove to uninstall; the reporter says that may not undo every change. |
| Does data leave my machine? | No evidence of that. A claim of data interception was made on X, but the issue shows settings changes and an MCP connection, not transmission. |
| What should I do? | Audit plugins, hooks and MCP entries in both agents, remove what you did not choose, and treat unexpected additions as a reason to re-check. |
What was reported
The developer, who goes by "indicava" on GitHub, filed the issue on October 25 after Codex began showing authentication errors and loading Postman skills repeatedly without being asked. According to The New Stack's account of the issue, Postman's own logs show an installation event on October 24 labeled auto-existing-upgrade, with results indicating plugins were installed for both agents.
The developer then found these changes on disk:
- Codex: edits to the user-level
~/.codex/config.toml, including an enabled Postman plugin, a new plugin marketplace, and a trusted session-start hook. - Claude Code: an installed Postman plugin in its configuration.
- A Postman CLI executable whose timestamps matched the install.
- A remote MCP connection to
https://mcp.postman.com/mcp, which Codex repeatedly failed to authenticate against.
The developer says none of this was explicitly authorized. The article is careful to note that the issue documents a single macOS installation. We have not run Postman ourselves, and we could not locate the issue page independently, so everything about the logs and file contents comes from that secondary summary. Read it as a credible report, not a confirmed defect.
How a session-start hook gets trusted
The detail that drew the most attention is how the Postman plugin reaches a trusted state in Codex.
Postman's own documentation describes a plugin that adds a session-start hook to Codex. The hook steers Codex toward Postman's skills. The documentation says what happens next depends on how you install:
- Through Codex itself. Per The New Stack, developers who install the plugin directly through Codex must review and approve the hook themselves.
- Through Postman's detected-agents installer. Per Postman's docs, the installer approves the hook for you. If it can't, it tells you to review the hook in Codex, and you rerun the installer to approve later hook changes.
According to The New Stack's reading of the installer source, the installer checks whether Codex already trusts the hook, and if not, uses a config/batchWrite call to write the hook's trusted hash into Codex's configuration. It verifies the hook has not changed before approving, and logs a message telling the user to review the hook if approval fails or cannot be confirmed. The Postman docs we fetched do not mention config/batchWrite, so that part rests on the article.
Why does this matter? A session-start hook is instruction injection by design. It can hand the agent text at the start of every session. Postman's text tells Codex to load the postman:api-engineer skill before most API-development tasks. That is a legitimate feature when you chose it. The concern in the report is that the same configuration was reportedly applied to an existing environment without a choice, and that the review step Codex provides for hooks was bypassed by the installer.
The detected-agents installer
Postman documents the installer as a Node.js tool published on npm as @postman/postman-plugin. Run with no command, it installs into every detected agent. Its documented surface:
| Command or flag | Behavior |
|---|---|
install (default) | Installs or updates in each detected agent |
status | Shows detected agents and whether the plugin is installed |
remove / uninstall | Removes from each detected agent |
--agent <id> | Limits to named agents such as claude-code or codex |
--dry-run | Previews without changing anything |
-y, --yes | Skips confirmation; required outside a terminal unless --dry-run |
Two details are relevant. First, running outside a terminal requires --yes, so a desktop app invoking the installer non-interactively is a supported path, not an accident of the report. Second, the docs list Antigravity, Claude Code, Codex, GitHub Copilot CLI, Cursor, Factory, Kimi Code, OpenCode and Pi as supported targets, so the same pattern could touch other agents you run.
What we could not establish from the documentation is why an existing desktop installation would trigger this unprompted. The New Stack lists that as unanswered, and so do we.
What is verified and what is not
| Claim | Status | Source |
|---|---|---|
| Postman documents an installer that approves the Codex hook for the user | Documented | Postman docs |
| Installing via Codex itself requires approving the hook | Documented | Postman docs |
| Postman desktop 12.33.4 on macOS installed plugins into both agents without consent | Single report, unreproduced | GitHub issue via The New Stack |
Postman logs show auto-existing-upgrade on October 24 | Reported in the issue | The New Stack |
| Hooks intercept API data and send it to Postman | Unsupported so far; no evidence in the issue | Claim on X, per The New Stack |
| Postman's explanation or fix | None published yet | Company had not responded |
Security researcher Frank Denis criticized the integrations on X, pointing out the installer's attempt to trust its own hook. That is an opinion about design, not a vulnerability finding.
What this means if you run AI coding agents
Treat your agent configuration as a security boundary, because anything that can write to it can change what your agent is told and which tools it calls. A practical audit:
- Codex. Open
~/.codex/config.tomland look for plugin entries, marketplace entries and hook trust entries you do not recognize. Also check~/.codex/hooks.jsonif present. - Claude Code. Run
claude plugin listand review~/.claude/settings.jsonfor hooks and plugins you did not add. - MCP. Search both agents' configs for MCP servers pointing at hosts you did not choose, including
mcp.postman.com. An MCP connection that fails to authenticate repeatedly, as the reporter saw, is itself a sign something was added. - Preview before removing. If you use Postman and want its integration gone,
npx @postman/postman-plugin statusshows what it detects, andnpx @postman/postman-plugin remove --dry-runshows what removal would do before you commit. The reporter's point stands that uninstall may not clear trusted hooks, MCP entries and the CLI binary, so check by hand afterward. - Keep a baseline. Commit a copy of your agent config files to a private repo or snapshot them, so a diff shows what changed and when. File modification times are a fast first clue: compare them to the dates you remember editing.
- Review hook prompts. When Codex asks you to review a hook, read the hook instead of dismissing it. A hook approved on your behalf never gives you that moment.
If you manage a team, the same audit scales: ask developers to share the plugin, hook and MCP lists from their agents, compare them against what your security team approved, and note which desktop applications on managed laptops are capable of writing to those files. An unreviewed hook in a shared workstation image is harder to spot than one on a single laptop.
For desktop apps in general, the lesson is that "integrations with your coding agent" now includes silent writes to agent config. Asking vendors for explicit opt-in, a dry-run mode and a complete uninstall is reasonable.
What Beam can and cannot do here
Beam does not stop another application from editing ~/.codex/config.toml or ~/.claude/settings.json. It is not a file-integrity monitor, and it is not a kernel sandbox. What it can help with:
- Scan the files after the fact.
beam scanchecks a skill or instruction file for risky patterns without executing it, andbeam scan --mcpvalidates an MCP configuration and examines version pinning. The scan is heuristic and static; it does not launch the MCP server or judge a vendor's intent. See the scanning docs. - Watch what the agent then does. With hooks installed (
beam agent install claude-code,beam agent install codex), Beam records proposed tool calls and can deny them under a workspace policy for Claude Code and Codex. If an injected session-start instruction pushes the agent toward risky commands, those calls are visible and can be denied. Missing cached policy fails open. See connecting assistants.
Beam installs its own hook by merging an entry into the agent's configuration while preserving existing hooks, and you run that command yourself. That is the same class of change this report is about, which is exactly why the opt-in matters.
Related reading
- A malicious AGENTS.md in the Downloads folder hijacks Codex and Claude Code
- Cursor MCP config poisoning and remote code execution
- Forty-two GitHub repos shipping Claude, Gemini and Cursor hooks
- NVIDIA SkillSpector, an open-source agent skill scanner
- Stopping dangerous Codex commands
- vlt 1.5.0 links npm dependencies into agent skill directories
- November 2026 attacks timeline
Frequently asked questions
Did Postman install plugins into Claude Code and Codex without permission?
One developer, known as indicava on GitHub, reports exactly that for Postman desktop 12.33.4 on macOS, with Postman logs showing an install event marked auto-existing-upgrade. It is a single report that has not been independently reproduced, and Postman had not responded to The New Stack when it published.
What is the self-approved Codex hook?
The Postman plugin adds a session-start hook that tells Codex to load Postman skills for API work. Postman documents that its detected-agents installer approves this hook for you, while installing through Codex itself requires you to review and approve it.
Is there evidence Postman collected my API data through the hook?
No. A claim that the hooks send API data back to the company was made on X, but the GitHub report documents configuration changes and a remote MCP connection, not data transmission.
How do I check whether my agents were changed?
Review ~/.codex/config.toml for plugin, marketplace and hook entries, run claude plugin list for Claude Code, and look for MCP entries pointing at mcp.postman.com. Postman documents npx @postman/postman-plugin status and remove for its installer.
Can Beam stop a third-party app from editing my agent config?
No. Beam hooks act on agent tool calls at runtime and can scan skill and MCP config files you point it at, but it does not watch or block other applications writing to your agent settings.
Details here reflect the sources available on November 4, 2026, and the report may be confirmed, corrected or fixed afterward. Check Postman's documentation and the original GitHub issue for current status.