Codex और Claude Code में 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 का प्लगइन पहले से मौजूद था।

5 नवंबर को रिपॉज़िटरी सदस्य preethammavin ने घोषणा की कि Postman बदलाव वापस ले रहा है। यह पहले की उन टिप्पणियों से अलग है जिनके लेखकों को GitHub पर सदस्य के रूप में चिह्नित नहीं किया गया था।

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 user

Claude Code का प्लगइन कमांड संदर्भ user, project और local दायरों में अंतर करता है। अगर स्थापना project या local दायरे में होने की पुष्टि हो, तो उसी प्रोजेक्ट से संबंधित दायरा चुनकर कमांड चलाएँ। प्रोजेक्ट की साझा सेटिंग हटाने से पहले टीम से समन्वय करें।

एक प्लगइन हटाने के लिए पूरा claude-plugins-official मार्केटप्लेस न हटाएँ। installed_plugins.json को पूरा खाली न करें और पूरी सेटिंग फ़ाइल न बदलें।

अगर आपका स्थापित 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 और startup|clear|compact matcher इस्तेमाल किया था। उसके निर्देशों के पाठ में सामान्य से बड़े 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 कॉन्फ़िगरेशन की जाँच वाला मार्गदर्शन काम कर रहे मॉडल की सेटिंग बचाते हुए बदलाव पहचानने की व्यापक सूची देता है।