Postman Plugin in Codex and Claude Code: Audit and Remove
Check whether Postman changed your coding-agent configuration, then remove unwanted plugins, remote MCP connections, and saved Codex hook approvals without deleting provider settings. Includes the November 5 rollback announcement, the removal of Codex's startup hook, native and vendor uninstall routes, residual checks, and managed hook policies for teams.
Contents
For an unwanted Postman plugin in Codex or Claude Code, preserve the configuration, uninstall the plugin, and remove any saved Codex hook approval. Do not authenticate a Postman MCP connection you did not choose. Verify the result in a fresh session before returning to normal work.
The recognizable symptom in Postman issue #14370 was:
MCP server startup failed server_name="postman"
... error: Auth required, when send initialize requestThe reporter also described repeated Postman skill loading during API work. These symptoms justify checking the integration. They do not establish that API data was uploaded.
What changed after the original reports?
As of 2026-11-10, the response includes a rollback announcement and changes to the Codex plugin. Do not treat the original installer behavior as an unchanged description of every current installation.
The original report concerned Postman desktop 12.33.4 on macOS, with Codex plugin 1.1.0 and Claude Code plugin 2.0.1. A later report involving 12.35.1 described another automatic installation. However, that machine had no Codex hook-trust record, and its Cursor plugin already existed.
On November 5, repository member preethammavin announced that Postman was reverting the change. This is distinct from earlier comments whose authors lacked a GitHub member association.
Also on November 5, merged pull request #149 removed installer-side approval. It also deleted hooks/codex-hooks.json and set the Codex manifest to "hooks": {}. The current Codex manifest retains that empty hooks declaration. It still includes Postman skills and an MCP server.
These changes do not demonstrate that an existing machine has been cleaned. Check the installed files, rather than assuming a desktop update removed old registrations or trust records.
Check what Postman wrote before running cleanup
Close Postman and active agent sessions first. Save private copies of the affected configuration, installation records, and relevant logs before editing them.
Use the configuration root of the affected session. A terminal and a desktop application may have different launch environments. The following Bash check respects CODEX_HOME and Claude Code’s documented CLAUDE_CONFIG_DIR override.
It prints matching filenames, not configuration contents:
codex_root="${CODEX_HOME:-$HOME/.codex}"
claude_root="${CLAUDE_CONFIG_DIR:-$HOME/.claude}"
for file in \
"$codex_root/config.toml" \
"$claude_root/settings.json" \
"$claude_root/plugins/installed_plugins.json"
do
if [ -f "$file" ]; then
grep -ilF -- postman "$file"
fi
doneA match is a lead for inspection, not proof of automatic installation. No matches only clears these particular files.
For the reported macOS installation, inspect ~/Library/Application Support/Postman/logs/main.log. The issue included this installation result:
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}Compare its timestamp with the plugin installation records. A matching timeline provides stronger evidence than finding the word “Postman” in a configuration file.
In Codex, inspect these three separate entries from the original report:
| Configuration entry | What to check |
|---|---|
[marketplaces.postman] | Whether its source is https://github.com/postmanlabs/postman-plugin.git. |
[plugins."postman@postman"] | Whether the plugin is enabled. |
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"] | Whether a saved approval contains trusted_hash, trusted_content_hash, or both. |
An absent trust entry does not rule out an installed plugin. The later report demonstrated that distinction.
For Claude Code, inspect enabledPlugins in ~/.claude/settings.json. The reported identifier was postman@claude-plugins-official. In ~/.claude/plugins/installed_plugins.json, inspect the matching installation’s scope, version, installedAt, and lastUpdated.
For Cursor, the installer’s host adapter identifies two locations:
~/.cursor/plugins/local/postman
~/.cursor/plugins/cache/cursor-public/postmanUse these as investigation leads. Confirm the enabled state in Cursor’s plugin settings rather than inferring it from a directory alone.
Keep full settings and logs private. They may contain credentials, internal paths, or account information. Share only the relevant, redacted entries.
Remove the plugin and its saved trust separately
Choose either native host removal or Postman’s remover. Do not run every route automatically.
Use the host commands for targeted removal
For the reported Codex plugin identifier, run this in Bash:
codex plugin remove postman@postmanThen remove its marketplace only after confirming the source and checking that no wanted plugin uses it:
codex plugin marketplace remove postmanThese operations match the current Postman Codex adapter. Use the identifiers actually present on your machine when an older installation has a different registration.
For the reported Claude Code user-scoped installation:
claude plugin uninstall postman@claude-plugins-official --scope userClaude Code’s plugin command reference distinguishes user, project, and local scopes. For a confirmed project or local installation, use the corresponding scope from that project. Coordinate removal of shared project settings with the team.
Do not remove the entire claude-plugins-official marketplace to remove one plugin. Do not truncate installed_plugins.json or replace your complete settings file.
If your installed CLI rejects a command, check its plugin --help before continuing. Do not substitute broad directory deletion for an unsupported uninstall command.
Alternatively, use Postman’s documented remover
Postman’s current repository instructions provide this removal command:
npx @postman/postman-plugin@latest removeUse this route only after approving the package code and reviewing the affected agents. The current installer source requires Node.js 22 or later. Keep the remove subcommand; running the installer without it is not a cleanup operation.
The documented remover leaves project-scoped installations in place. Its current Codex implementation also attempts to revoke the old startup-hook approval.
That last operation needs verification. The revocation implementation can report a cleanup problem without failing the overall removal. Read its warnings and inspect the file afterward.
Delete any remaining Codex approval
Remove the entire subsection below from the affected Codex user configuration if it remains:
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]This block identifies the section to delete; it is not configuration to add.
Delete that section’s trusted_hash and trusted_content_hash fields together. Stop at the next TOML table header. Leave other entries under hooks.state intact.
When editing manually, remove only confirmed Postman entries. Preserve model_provider, model_providers, base_url, authentication settings, and unrelated hooks. For Claude Code, preserve unrelated env and permission settings.
After native removal, verify that the matching plugin and marketplace registrations are gone. After either route, verify that the saved Postman approval is gone. An uninstall message alone does not prove all three conditions.
Check Cursor, separate MCP entries, and the CLI
Cursor marketplace installations need an additional action: uninstall Postman in Cursor Settings > Plugins, then restart Cursor. After either removal route, check Cursor’s plugin inventory for remaining Postman installations.
If an MCP warning remains, inspect the server configuration instead of signing in to silence it. In Bash, use the command for each affected host:
codex mcp list
claude mcp listA separately configured server requires separate removal. After confirming that an unwanted standalone entry is named postman, use codex mcp remove postman or claude mcp remove postman. Check the entry’s scope before removal. The Codex CLI reference and Claude Code MCP documentation describe these commands.
Do not confuse a standalone server with one supplied by an enabled plugin. Remove the plugin that owns a plugin-provided connection.
Check the Postman CLI separately. In Bash, type -a postman shows matching commands on your path. The original incident placed an executable under ~/.local/bin; do not assume every installation uses that location.
Follow Postman’s method-specific CLI uninstall instructions. For a non-npm installation, the documented method removes the executable. Inspect any accompanying files before deleting them, and never delete a shared lib directory merely because the report mentioned one.
Verify cleanup in a fresh session
Verify configuration and loaded components, not just the absence of a warning.
First, use the affected hosts’ plugin inventories:
codex plugin list --json
claude plugin list --jsonCheck for every Postman registration, including installations with a different marketplace suffix or scope. Confirm that the exact Postman hook-approval subsection is absent from the active Codex configuration.
Start a new agent session in a disposable checkout. Check that no unwanted Postman plugin or MCP connection loads. There should be no new Postman authentication warning from the removed integration.
Do not use an old conversation’s references to Postman as the sole test. Existing conversation text is a different object from installed configuration. The distinction between starting a new Claude Code session and compacting an existing one matters here.
If Postman still appears, check the configuration root, installation scope, remaining plugin registrations, and separate MCP entries. Do not repeatedly delete the same default file without locating the active source.
If you retain Postman desktop, compare the configuration again after its next controlled launch or update. If entries return, preserve the new log timestamps and diff. Pause that desktop rollout while investigating which process recreated them.
Why could the installer write Codex hook trust?
The historical installer used Codex’s configuration interface to persist an approval. It did not merely register a plugin and leave the trust decision to the interactive review.
At commit 6c8e452e0f4237f4bcc0901cb1ac442dec707e49, the hook registration used SessionStart with matcher startup|clear|compact. Its instruction text directed non-trivial API engineering work through postman:api-engineer.
That instruction covered more than explicit requests to use Postman. It exempted pure questions and trivial edits, and stated that user instructions took precedence.
The historical approvePostmanHook implementation launched codex app-server. It obtained the current hook hash through hooks/list, checked it, then called config/batchWrite. The write inserted trusted_hash under hooks.state.
This establishes an approval attempt. It does not prove success on every Codex version or identify who created a particular machine’s existing record.
Codex’s documented trust mechanism compares a hook with its saved hash and skips new or changed hooks pending review. The important boundary is therefore access to the approval state. A matching hash is not, by itself, evidence that a human approved the hook.
The practical implication is local: software running with enough access to your agent configuration can change security-relevant state. Plugin enablement, hook trust, and remote MCP authentication are separate controls. Cleaning only one can leave the others configured.
Prevent repeat changes on team machines
Keep an approved, sanitized configuration baseline and compare it after tool installations and updates. Store templates and reviewed changes in version control, not live credentials or complete personal configuration directories.
Diffs detect changes; they do not stop a same-account process from writing files. For enforcement, deploy administrator-controlled policies that ordinary desktop applications cannot rewrite.
For Codex on macOS or Linux, the system requirements file is /etc/codex/requirements.toml. Merge this top-level setting into the existing file:
allow_managed_hooks_only = trueThe managed configuration documentation describes deployment locations. The configuration reference defines this setting: it skips user, project, session, and plugin hooks while allowing managed hooks.
For Claude Code on macOS, merge the following into /Library/Application Support/ClaudeCode/managed-settings.json:
{
"allowManagedHooksOnly": true
}This is a managed-policy setting, not a substitute for editing user preferences. Claude Code’s hook controls block user, project, and other plugin hooks. Its settings reference preserves important exceptions: managed hooks, SDK hooks, and hooks from plugins force-enabled through managed enabledPlugins.
Test policies with the actual client versions used by your team before wider deployment. Hook restrictions do not themselves uninstall plugins or remove MCP connections; govern those components separately.
Extend the same review to downloaded instructions and provider settings. The Codex and Claude Code configuration audit provides a broader checklist for identifying configuration changes without discarding a working model setup.
