Postman Auto-Install: Check Claude Code and Codex Settings

To check what Postman added, start by reading ~/.codex/config.toml, ~/.claude/settings.json and the related records below for postman entries. Issue #14370 in Postman's official tracker reports automatic plugin installation into Claude Code and Codex from Postman Desktop 12.33.4. Postman said on November 5 that it was reverting the change. Data exfiltration remains unverified. This checklist inspects saved registrations without opening the app or running a removal command.

Checked: 2026-11-08 JST. Reported versions: Postman Desktop 12.33.4, Codex Postman plugin 1.1.0, Claude Code installation record 2.0.1, source revision 6c8e452e0f4237f4bcc0901cb1ac442dec707e49. Local environment: macOS (Darwin 25.6.0), Claude Code 2.1.317, codex-cli 0.166.0. No Postman.app was found at the two inspected application locations. The Desktop rollback version, automatic cleanup and actual network contents remain unverified.

Four points guide the inspection:

• The reporter found plugins, a startup hook, a remote MCP registration and a Postman CLI. Those are the reporter's observations, separate from this Mac.
• The pinned installer attempts to approve its own Codex hook. A saved trust value alone cannot identify who created that record.
• The current repository removes the Codex startup hook and documents cleanup of old approval records through remove. That does not verify automatic cleanup by a Desktop update.
• Reading the files requires no plugin installation, removal or MCP connection. Attribute a registration using its history and logs, rather than its name alone.

#What did Postman Desktop reportedly add?

#What are the source and affected versions?

The author of issue #14370 describes unexpected changes to Claude Code and Codex after opening an existing Postman installation on a Mac. The evidence includes a Postman log recording auto-existing-upgrade and successful installations for both agents, user-wide configuration and a separate CLI. The author explicitly says the sequence was not reproduced on a clean Mac.

The reported Desktop version is 12.33.4. The Codex plugin's 1.1.0, the Claude Code record's 2.0.1 and the installer's later 0.7.2 are different version numbers. None identifies a fixed Desktop release.

#What does the hook approval code do?

At the reported revision, the hook definition specifies SessionStart with startup|clear|compact. Its context document instructs the agent to route broad API engineering tasks through Postman skills. That document is evidence under inspection, not an instruction for the person doing this check.

The pinned caller invokes approvePostmanHook after installation. The approval code retrieves a hash through hooks/list and attempts to upsert trusted_hash under hooks.state using config/batchWrite. It can skip approval when APIs are unavailable or other conditions fail. This establishes an approval attempt in the source, rather than successful approval on every machine. We did not verify trust semantics across Codex versions.

For Claude Code, the official hook reference says plain-text SessionStart stdout is added to context. That documentation should be read separately from Codex's internal behavior.

#What did Postman say, and what changed afterward?

In the November 5 response, preethammavin, marked MEMBER, says the intent was easier setup, the experience would be redesigned with appropriate control, and the change was being reverted in the meantime. The issue events show a85 closed it at 11:41:48 UTC that day; the issue API gives state_reason completed. Closure alone does not establish a shipped fix.

#Was data sent outside the machine?

Data exfiltration remains unverified. The reporter does not claim to establish it. The pinned MCP definition points to https://mcp.postman.com/mcp, and the issue includes an authentication-required connection failure. That failed connection also cannot establish that no other communication occurred.

#Will a Desktop update remove existing settings?

That remains unverified. Repository changes, Desktop distribution and automatic cleanup of existing settings require separate evidence. We ran neither an update nor a removal. The README's manual remove procedure does not establish automatic cleanup.

#Which files should I read on my Mac?

The table uses default locations. If you changed CODEX_HOME or CLAUDE_CONFIG_DIR, inspect those locations too. No string match in these files does not prove absence across caches, project scope or managed settings.

Project .claude/settings.json and .claude/settings.local.json were also absent. We did not inspect arbitrary application locations or historical installations. SHA-256 hashes of the inspected files matched before and after the local checks.

#What should I look for in Codex?

The reported tables are [marketplaces.postman], [plugins."postman@postman"] and [hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]. If present, compare the saved configuration with the plugin's files locally. Names under locations such as ~/.codex/plugins alone do not establish activation or execution. We found no matching plugin or hook name in this inspection.

#What should I look for in Claude Code?

Compare enabledPlugins in settings.json with plugins/installed_plugins.json. See the official plugin guide and settings guide. Direct MCP registrations can live in ~/.claude.json or project .mcp.json, while a plugin can bundle its own definition. The Claude Code MCP configuration guide explains the scopes.

This block reads default configuration files and prints matching line numbers, without printing setting values. It distinguishes missing files, no matches and unreadable files, and skips a file that is itself a symlink. Run it from a trusted location, including trusted parent directories.

for file in \
  "$HOME/.codex/config.toml" \
  "$HOME/.claude/settings.json" \
  "$HOME/.claude/plugins/installed_plugins.json" \
  "$HOME/.claude/plugins/known_marketplaces.json" \
  "$HOME/.claude.json" \
  .claude/settings.json .claude/settings.local.json .mcp.json
do
  label=${file#"$HOME"/}
  if [ -L "$file" ]; then
    printf '%s: SYMLINK_SKIPPED\n' "$label"
  elif [ ! -e "$file" ]; then
    printf '%s: MISSING\n' "$label"
  elif [ ! -f "$file" ] || [ ! -r "$file" ]; then
    printf '%s: UNREADABLE\n' "$label"
  else
    lines=$(grep -n -i 'postman' "$file")
    result=$?
    case "$result" in
      0) printf '%s: MATCH_LINES\n' "$label"
         printf '%s\n' "$lines" | cut -d: -f1 ;;
      1) printf '%s: NO_MATCH\n' "$label" ;;
      *) printf '%s: READ_ERROR\n' "$label" ;;
    esac
  fi
done

We checked this block in synthetic homes using sh and zsh. It is a text-inspection aid, not a parser of the complete effective configuration. Do not count UNREADABLE or READ_ERROR as no match.

#Where are app and CLI traces stored?

Without opening the app, its version can be read from CFBundleShortVersionString in Info.plist. If ~/Library/Application Support/Postman/logs/main.log exists, inspect it locally for PostmanAgentPluginService or auto-existing-upgrade and compare configuration timestamps. Check ~/.local/bin/postman and command -v postman for the CLI's location. Logs and PATH output can contain account names; redact them before sharing.

#What should I do before removing a registration?

#In what order should I record and remove it?

Record the relevant filename, registration name and modification time locally, and check whether you intended to install it. Then close active Codex and Claude Code sessions and choose the removal scope using the Postman README or the agent's official instructions. The README's remove is a deletion operation. We did not execute it or verify its cleanup results, including any remaining settings.

The README also describes status, but npx @postman/postman-plugin@latest status retrieves and runs third-party code. The Claude Code MCP guide describes claude mcp list as showing connection health. We used neither command, to avoid a connection or installer execution. We have not verified a no-change guarantee for --dry-run.

#How should a team share inspection results?

Use the same file list and distinguish matches, no matches, missing files and unverified checks. There is no need to paste trusted_hash values, credentials, account names or full logs. A name match alone does not attribute a change to Postman Desktop; compare installation times and the user's actions too.

#How can I notice configuration added by another app?

Inspect startup inputs alongside hook exit codes and output and skill locations. When using worktrees to separate tasks, inspect user-wide settings separately. For restricting writes, see working-directory write limits and their exclusions.

#What are the answers to common questions?

#Did simply opening Postman install it?

The issue reports installation logs attributed to an automatic upgrade after opening an existing Postman installation. We have not reproduced this on a clean Mac or verified it for every user.

#Does removing the plugin also remove hook approval records?

The current Postman README says remove also cleans up older Codex hook approval records. We did not run that command, so cleanup results in individual environments remain unverified.

#Was this Mac affected?

Postman.app was absent at the two inspected locations, and the inspected user settings had no postman matches. This does not establish no historical impact or absence at every possible location.

#Can I check with claude mcp list?

It checks connection health, so read the files first if you want to avoid communication during inspection. We did not use it in this local run.

#Is the npx Postman status command safe?

The README documents status, but npx retrieves and executes third-party code. We did not run it and do not guarantee its safety or lack of changes.

#Were Cursor and Copilot CLI also automatically configured?

The README lists support for other agents, but the specific configuration evidence in this issue concerns Claude Code and Codex. Automatic installation in other environments remains unverified.