Postman 플러그인: Codex·Claude Code에서 확인하고 삭제하기
Postman이 코딩 에이전트 설정을 바꿨는지 확인하고, 제공자 설정을 보존하면서 원치 않는 플러그인, 원격 MCP 연결, Codex에 저장된 훅 승인을 삭제합니다. 11월 5일 변경 철회 발표와 Codex 시작 훅 제거, 기본 명령과 Postman 제거 도구, 남은 설정 확인, 팀용 관리형 훅 정책을 다룹니다.
목차
Codex나 Claude Code에 원치 않는 Postman 플러그인이 있다면 설정 사본을 보관한 뒤 플러그인을 삭제합니다. Codex에 저장된 훅 승인도 제거하고, 직접 선택하지 않은 Postman MCP 연결은 인증하지 않습니다. 평소 작업으로 돌아가기 전에 새 세션에서 결과를 확인합니다.
Postman 이슈 #14370에 보고된 대표적인 오류는 다음과 같습니다.
MCP server startup failed server_name="postman"
... error: Auth required, when send initialize request보고자는 API 작업 중 Postman 스킬이 반복해서 로드되는 현상도 설명했습니다. 이런 증상이 보이면 연동 설정을 점검해야 합니다. 다만 이 증상만으로 API 데이터가 업로드됐다고 볼 수는 없습니다.
초기 보고 이후의 변경 사항
2026-11-10 기준으로 Postman은 변경 철회를 발표했고 Codex 플러그인도 수정했습니다. 이전 설치 프로그램의 동작이 현재 모든 설치 환경에서도 그대로 이어진다고 판단해서는 안 됩니다.
최초 보고는 macOS의 Postman 데스크톱 12.33.4, Codex 플러그인 1.1.0, Claude Code 플러그인 2.0.1에 관한 내용이었습니다. 12.35.1에 관한 후속 보고에서도 자동 설치가 다시 설명됐습니다. 하지만 해당 컴퓨터에는 Codex 훅 신뢰 기록이 없었으며, Cursor 플러그인은 이전부터 설치되어 있었습니다.
11월 5일에는 저장소 멤버인 preethammavin이 Postman이 변경을 되돌리고 있다고 발표했습니다. 이는 GitHub에서 작성자의 멤버 관계가 표시되지 않았던 이전 댓글들과 구분됩니다.
같은 11월 5일에 병합된 풀 리퀘스트 #149는 설치 프로그램이 직접 승인하는 동작을 제거했습니다. 또한 hooks/codex-hooks.json을 삭제하고 Codex 매니페스트에 "hooks": {}를 설정했습니다. 현재 Codex 매니페스트도 빈 훅 선언을 유지합니다. Postman 스킬과 MCP 서버는 여전히 포함되어 있습니다.
이 변경만으로 기존 컴퓨터에서 원치 않는 연동이 정리됐다고 볼 수는 없습니다. 설치된 파일을 확인해야 합니다. 데스크톱 앱 업데이트가 예전 등록 정보나 신뢰 기록까지 삭제했을 것이라고 가정하지 않습니다.
삭제 전에 Postman이 기록한 내용을 확인합니다
먼저 Postman과 실행 중인 에이전트 세션을 닫습니다. 편집하기 전에 영향을 받은 설정, 설치 기록, 관련 로그의 사본을 비공개로 보관합니다.
문제가 발생한 세션에서 사용하는 설정 루트 디렉터리를 확인합니다. 터미널과 데스크톱 앱은 실행 환경이 다를 수 있습니다. 다음 Bash 점검 코드는 CODEX_HOME과 Claude Code 문서에 명시된 CLAUDE_CONFIG_DIR 재정의 값을 반영합니다.
설정 내용 대신 일치 항목이 있는 파일 이름만 출력합니다.
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
done일치 항목은 추가로 조사할 단서이지 자동 설치의 증거는 아닙니다. 일치 항목이 없다는 결과도 이 파일들에만 해당합니다.
보고된 macOS 설치의 경우 ~/Library/Application Support/Postman/logs/main.log를 확인합니다. 이슈에는 다음 설치 결과가 포함되어 있었습니다.
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}이 기록의 시각을 플러그인 설치 기록과 비교합니다. 시간이 일치하면 설정 파일에서 “Postman”이라는 단어만 발견한 경우보다 더 강한 근거가 됩니다.
Codex에서는 최초 보고에 나온 다음 세 항목을 각각 확인합니다.
| 설정 항목 | 확인할 내용 |
|---|---|
[marketplaces.postman] | 원본이 https://github.com/postmanlabs/postman-plugin.git인지 확인합니다. |
[plugins."postman@postman"] | 플러그인이 활성화되어 있는지 확인합니다. |
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"] | 저장된 승인에 trusted_hash, trusted_content_hash 또는 두 필드 모두 있는지 확인합니다. |
신뢰 항목이 없더라도 플러그인이 설치되어 있을 수 있습니다. 후속 보고는 이 차이를 보여줬습니다.
Claude Code에서는 ~/.claude/settings.json의 enabledPlugins를 살펴봅니다. 보고된 식별자는 postman@claude-plugins-official이었습니다. ~/.claude/plugins/installed_plugins.json에서는 해당 설치의 범위, 버전, installedAt, lastUpdated를 확인합니다.
Cursor의 경우 설치 프로그램의 호스트 어댑터에 다음 두 위치가 나옵니다.
~/.cursor/plugins/local/postman
~/.cursor/plugins/cache/cursor-public/postman이 위치를 조사 시작점으로 사용합니다. 디렉터리가 있다는 이유만으로 활성 상태라고 판단하지 않습니다. Cursor 플러그인 설정에서 실제 활성 상태를 확인합니다.
설정 파일과 로그 전체는 비공개로 유지합니다. 인증 정보, 내부 경로, 계정 정보가 들어 있을 수 있습니다. 관련 항목만 공유하고 먼저 민감한 내용을 가립니다.
플러그인과 저장된 신뢰 기록을 따로 삭제합니다
각 도구의 기본 명령이나 Postman의 제거 도구 중 하나를 선택합니다. 모든 방법을 무조건 차례로 실행하지 않습니다.
도구의 기본 명령으로 대상을 지정해 삭제합니다
보고된 Codex 플러그인 식별자에 대해서는 Bash에서 다음 명령을 실행합니다.
codex plugin remove postman@postman다음으로 해당 마켓플레이스의 원본을 확인합니다. 필요한 다른 플러그인이 사용하지 않는다는 점까지 확인한 뒤에만 마켓플레이스를 제거합니다.
codex plugin marketplace remove postman이 작업은 현재 Postman의 Codex 어댑터와 일치합니다. 이전 설치가 다른 이름으로 등록되어 있다면 컴퓨터에 실제로 존재하는 식별자를 사용합니다.
보고에 나온 사용자 범위의 Claude Code 설치에는 다음 명령을 사용합니다.
claude plugin uninstall postman@claude-plugins-official --scope userClaude Code의 플러그인 명령 참조는 user, project, local 범위를 구분합니다. 프로젝트 또는 로컬 범위의 설치로 확인되면 해당 프로젝트에서 맞는 범위를 지정해 실행합니다. 공유 프로젝트 설정을 삭제할 때는 팀과 조율합니다.
플러그인 하나를 삭제하려고 claude-plugins-official 마켓플레이스 전체를 제거하지 않습니다. installed_plugins.json을 통째로 비우거나 설정 파일 전체를 교체하지 않습니다.
설치된 CLI가 명령을 거부하면 계속하기 전에 해당 CLI의 plugin --help를 확인합니다. 지원되지 않는 제거 명령 대신 디렉터리를 광범위하게 삭제해서는 안 됩니다.
다른 방법: Postman에 문서화된 제거 도구를 사용합니다
Postman의 현재 저장소 안내에는 다음 제거 명령이 있습니다.
npx @postman/postman-plugin@latest remove패키지 코드를 검토하고 실행을 승인한 뒤에만 이 방법을 사용합니다. 영향을 받는 에이전트도 먼저 확인합니다. 현재 설치 프로그램 소스는 Node.js 22 이상을 요구합니다. remove 하위 명령을 빼지 않습니다. 이것 없이 설치 프로그램을 실행하는 것은 정리 작업이 아닙니다.
문서에 따르면 제거 도구는 프로젝트 범위의 설치를 남겨 둡니다. 현재 Codex 구현은 예전 시작 훅의 승인도 취소하려고 시도합니다.
마지막 작업은 따로 검증해야 합니다. 승인 취소 구현은 정리 문제를 알리면서도 전체 제거 작업을 실패로 처리하지 않을 수 있습니다. 경고를 읽고 작업이 끝난 뒤 파일을 확인합니다.
남아 있는 Codex 승인을 삭제합니다
해당 Codex 사용자 설정에 다음 하위 섹션이 남아 있다면 전체를 삭제합니다.
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]이 블록은 삭제할 섹션을 식별하기 위한 것입니다. 설정에 추가하는 예제가 아닙니다.
해당 섹션의 trusted_hash와 trusted_content_hash 필드를 함께 삭제합니다. 다음 TOML 테이블 헤더 앞에서 멈춥니다. hooks.state 아래의 다른 항목은 그대로 둡니다.
수동으로 편집할 때는 Postman과 관련된 것으로 확인된 항목만 삭제합니다. model_provider, model_providers, base_url, 인증 설정, 관계없는 훅은 보존합니다. Claude Code에서도 관계없는 env와 권한 설정을 유지합니다.
기본 명령으로 삭제한 뒤에는 해당 플러그인과 마켓플레이스 등록이 사라졌는지 확인합니다. 어느 방법을 사용하든 Postman의 저장된 승인이 제거됐는지도 검증합니다. 제거 완료 메시지만으로 이 세 조건을 모두 충족했다고 판단할 수는 없습니다.
Cursor, 별도 MCP 항목, CLI를 확인합니다
Cursor 마켓플레이스에서 설치한 플러그인은 추가 작업이 필요합니다. Cursor Settings > Plugins에서 Postman을 제거한 뒤 Cursor를 다시 시작합니다. 어느 제거 방법을 사용했든 Cursor의 플러그인 목록에서 Postman 설치가 남아 있는지 확인합니다.
MCP 경고가 계속되면 경고를 없애려고 로그인하지 말고 서버 설정을 점검합니다. Bash에서 영향을 받은 각 도구에 해당하는 명령을 사용합니다.
codex mcp list
claude mcp list별도로 설정한 서버는 따로 삭제해야 합니다. 원치 않는 독립 항목의 이름이 postman인지 먼저 확인합니다. 그다음 codex mcp remove postman 또는 claude mcp remove postman을 사용합니다. 삭제 전에 항목의 범위를 확인합니다. Codex CLI 참조와 Claude Code MCP 문서에 이 명령들이 설명되어 있습니다.
독립 서버를 활성화된 플러그인이 제공하는 서버와 혼동하지 않습니다. 플러그인이 제공하는 연결이라면 그 플러그인을 삭제합니다.
Postman CLI도 별도로 확인합니다. Bash의 type -a postman은 검색 경로에서 찾은 같은 이름의 명령을 표시합니다. 원래 사례에서는 실행 파일이 ~/.local/bin에 있었지만, 모든 설치가 같은 위치를 쓴다고 가정하지 않습니다.
Postman의 설치 방식별 CLI 제거 안내를 따릅니다. npm 이외의 방식으로 설치했다면 문서에 나온 방법은 실행 파일을 삭제하는 것입니다. 함께 설치된 파일은 내용을 확인한 뒤 삭제합니다. 보고에서 언급됐다는 이유만으로 공유 lib 디렉터리를 지워서는 안 됩니다.
새 세션에서 정리 결과를 검증합니다
경고가 사라졌는지만 보지 말고 설정과 로드된 구성 요소를 확인합니다.
먼저 영향을 받은 도구의 플러그인 목록을 조회합니다.
codex plugin list --json
claude plugin list --json마켓플레이스 접미사나 설치 범위가 다른 경우까지 포함해 모든 Postman 등록을 확인합니다. 실제 사용하는 Codex 설정에서 앞서 명시한 Postman 훅 승인 하위 섹션이 사라졌는지 검증합니다.
검증용 임시 저장소 작업 복사본에서 에이전트의 새 세션을 시작합니다. 원치 않는 Postman 플러그인이나 MCP 연결이 로드되지 않는지 확인합니다. 제거한 연동으로 인해 Postman 인증 경고가 새로 발생하지 않아야 합니다.
이전 대화에 남은 Postman 언급만으로 결과를 판단하지 않습니다. 기존 대화 내용과 설치된 설정은 별개입니다. 따라서 Claude Code에서 새 세션을 시작하는 것과 기존 세션을 압축하는 것의 차이가 중요합니다.
Postman이 계속 나타나면 설정 루트, 설치 범위, 남은 플러그인 등록, 별도 MCP 항목을 확인합니다. 활성 설정의 출처를 찾지 않은 채 같은 기본 파일을 반복해서 삭제하지 않습니다.
Postman 데스크톱을 계속 사용한다면 다음 통제된 실행이나 업데이트 뒤에 설정을 다시 비교합니다. 항목이 재생성되면 새로운 로그 시각과 설정 차이를 보관합니다. 어떤 프로세스가 항목을 다시 만들었는지 조사하는 동안 해당 데스크톱 앱의 배포를 일시 중단합니다.
설치 프로그램이 Codex 훅 신뢰 기록을 쓸 수 있었던 이유
예전 설치 프로그램은 Codex 설정 인터페이스를 사용해 승인을 저장했습니다. 플러그인만 등록한 뒤 신뢰 여부를 대화형 검토에서 사용자가 결정하도록 두지는 않았습니다.
커밋 6c8e452e0f4237f4bcc0901cb1ac442dec707e49의 훅 등록은 SessionStart와 matcher startup|clear|compact를 사용했습니다. 지시문은 단순한 수준을 넘는 API 엔지니어링 작업을 postman:api-engineer를 통해 처리하도록 요구했습니다.
이 지시는 Postman을 명시적으로 사용해 달라는 요청에만 적용되지 않았습니다. 질문에 답하기만 하는 경우와 사소한 수정은 예외였습니다. 사용자 지시가 우선한다는 내용도 있었습니다.
예전 approvePostmanHook 구현은 codex app-server를 실행했습니다. hooks/list로 훅의 현재 해시를 가져와 확인한 다음 config/batchWrite를 호출했습니다. 이 쓰기 작업이 hooks.state 아래에 trusted_hash를 추가했습니다.
이는 승인을 시도했다는 사실을 뒷받침합니다. 모든 Codex 버전에서 성공했다는 증거는 아닙니다. 특정 컴퓨터에 있던 기록을 누가 만들었는지도 이 사실만으로는 알 수 없습니다.
Codex의 문서화된 신뢰 메커니즘은 훅을 저장된 해시와 비교합니다. 새 훅이나 변경된 훅은 검토하고 승인할 때까지 실행하지 않습니다. 따라서 중요한 경계는 승인 상태에 대한 접근 권한입니다. 해시가 일치한다는 사실만으로 사람이 훅을 승인했다고 볼 수는 없습니다.
실무적으로는 로컬 접근 권한의 문제입니다. 에이전트 설정에 충분한 접근 권한이 있는 프로그램은 보안에 영향을 주는 상태를 바꿀 수 있습니다. 플러그인 활성화, 훅 신뢰, 원격 MCP 인증은 서로 다른 제어입니다. 하나만 정리하면 나머지 설정이 남을 수 있습니다.
팀 컴퓨터에서 같은 변경이 반복되지 않도록 합니다
민감한 정보를 제거한 승인된 기준 설정을 보관하고, 도구 설치나 업데이트 뒤에 비교합니다. 버전 관리에는 템플릿과 검토한 변경을 저장합니다. 실제 인증 정보나 개인 설정 디렉터리 전체를 넣지 않습니다.
파일 차이 비교는 변경을 감지하지만, 같은 계정의 프로세스가 파일을 쓰는 것을 막지는 못합니다. 제한을 강제하려면 일반 데스크톱 앱이 수정할 수 없는 관리자 통제 정책을 배포합니다.
macOS 또는 Linux에서 Codex의 시스템 요구사항 파일은 /etc/codex/requirements.toml입니다. 기존 파일의 최상위에 다음 설정을 추가합니다.
allow_managed_hooks_only = true관리형 설정 문서는 정책 배포 위치를 설명합니다. 설정 참조에 따르면 이 설정은 사용자, 프로젝트, 세션, 플러그인 훅을 건너뜁니다. 관리형 훅은 계속 허용합니다.
macOS의 Claude Code에서는 기존 /Library/Application Support/ClaudeCode/managed-settings.json에 다음 설정을 병합합니다.
{
"allowManagedHooksOnly": true
}이는 관리형 정책 설정이며, 사용자 환경설정을 편집하는 일을 대신하지는 않습니다. Claude Code의 훅 제어는 사용자, 프로젝트, 기타 플러그인 훅을 차단합니다. 설정 참조에는 중요한 예외가 명시되어 있습니다. 관리형 훅, SDK 훅, 관리형 enabledPlugins로 강제 활성화한 플러그인의 훅은 허용됩니다.
전체 팀에 배포하기 전에 실제 사용하는 클라이언트 버전에서 정책을 테스트합니다. 훅 제한 자체가 플러그인을 제거하거나 MCP 연결을 삭제하지는 않습니다. 이 구성 요소들은 따로 관리합니다.
다운로드한 지시 파일과 제공자 설정에도 같은 점검을 적용합니다. Codex와 Claude Code 설정 감사 가이드는 정상 작동하는 모델 설정을 버리지 않고 변경을 찾는 더 넓은 점검 목록을 제공합니다.
