Claude Code MCP Tasks: बैकग्राउंड काम और Elicitation
लंबे MCP टूल कॉल चलाएँ और Claude Code को दूसरे काम करने दें। वर्शन, प्रोटोकॉल और फ़ीचर फ़्लैग की शर्तें जाँचें, सही टास्क हैंडल और अंतिम नतीजा लौटाएँ, Elicitation हुक की जाँच करें और जानें कि रद्द करने, बाहर निकलने या सेशन बदलने पर टास्क का क्या होता है।
विषय-सूची
Claude Code में MCP Tasks चलाने के लिए ऐसा MCP सर्वर इस्तेमाल करें जो Tasks का समर्थन करता हो, और v2.1.304 या बाद के वर्शन वाले टर्मिनल CLI में मुख्य बातचीत से उसका टूल चलाएँ। सर्वर जॉब स्वीकार करता है, Claude दूसरे काम करता रहता है और जॉब पूरी होने पर नतीजा मिलता है। सर्वर बदलने से पहले ज़रूरी शर्तें जाँचें: सामान्य टूल कॉल का दो मिनट बाद अपने आप बैकग्राउंड में चले जाना एक अलग व्यवस्था है।
2026-10-24 तक की जानकारी के अनुसार, Claude Code में MCP Tasks सार्वजनिक बीटा के रूप में उपलब्ध हैं। यह गाइड प्रोटोकॉल की मौजूदा 2026-07-28 रिविज़न और उन शर्तों को समझाती है जिनसे तय होता है कि आपका कॉल टास्क बन सकता है या नहीं।
Tasks और Elicitation किस काम आते हैं
Tasks ऐसे लंबे कामों के लिए इस्तेमाल करें जिन्हें सर्वर स्वतंत्र रूप से स्वीकार और ट्रैक कर सके, जैसे बिल्ड, टेस्ट चलाना, एक्सपोर्ट या रिसर्च। Elicitation तब इस्तेमाल करें जब आगे बढ़ने से पहले सर्वर को आपसे कोई निर्णय या छूटी हुई जानकारी चाहिए।
ये तीन व्यवहार देखने में एक जैसे लग सकते हैं:
| व्यवस्था | क्या होता है | सर्वर को क्या लागू करना होगा |
|---|---|---|
| सामान्य MCP कॉल | Claude टूल के नतीजे का इंतज़ार करता है। | टूल की सामान्य इम्प्लीमेंटेशन। |
| अपने आप बैकग्राउंड में भेजना | मुख्य बातचीत का कोई कॉल दो मिनट बाद भी चल रहा हो, तो वह बैकग्राउंड में चला जाता है। उसका नतीजा बाद में आता है, लेकिन सेशन से बाहर निकलने के बाद यह बैकग्राउंड कॉल नहीं बचता। | Tasks का समर्थन ज़रूरी नहीं है। |
| MCP Task | जॉब स्वीकार करते ही सर्वर टास्क हैंडल लौटाता है—टास्क की पहचान और स्थिति बताने वाला ऑब्जेक्ट। Claude Code उस हैंडल को ट्रैक करके नतीजा प्राप्त करता है। रिमोट सर्वर की जॉब CLI से बाहर निकलने के बाद भी चल सकती है। | Tasks एक्सटेंशन और टास्क की स्थिति को स्थायी रूप से संभालने की व्यवस्था। |
Elicitation एक अलग सुविधा है। रिपोर्ट बनाने वाला टूल पहले पूछ सकता है कि किस एनवायरनमेंट से जानकारी लेनी है और फिर एक्सपोर्ट को Task के रूप में चला सकता है। जल्दी पूरा होने वाला टूल भी टास्क बनाए बिना यही जानकारी माँग सकता है।
Elicitation इस रिलीज़ से पहले भी मौजूद था: Claude Code v2.1.76 में इनपुट माँगने वाले डायलॉग और Elicitation व ElicitationResult हुक जोड़े गए थे। यहाँ नई सुविधा सर्वर द्वारा संचालित Tasks है।
जाँचें कि आपका कॉल MCP Task बन सकता है या नहीं
आधिकारिक शर्तों की सूची की हर शर्त पूरी होनी चाहिए। नया CLI इंस्टॉल करने से सिर्फ़ पहली शर्त पूरी होती है।
| क्या जाँचना है | ज़रूरी शर्त |
|---|---|
| Claude Code का वर्शन | v2.1.304 या बाद का वर्शन। |
| सर्वर की इम्प्लीमेंटेशन | सर्वर Tasks एक्सटेंशन का समर्थन करता हो। सिर्फ़ MCP कनेक्शन बन जाना इस समर्थन का प्रमाण नहीं है। |
| ट्रांसपोर्ट और प्रोटोकॉल | HTTP, stdio या claude.ai कनेक्टर का सर्वर प्रोटोकॉल रिविज़न 2026-07-28 पर जुड़ा हो। |
| पुराना प्रोटोकॉल लागू करने वाली सेटिंग | MCP_SDK_GENERATION=v1 या MCP_PROTOCOL_NEGOTIATION=legacy कनेक्शन को पुराने प्रोटोकॉल पर जाने के लिए बाध्य न कर रही हों। |
| फ़ीचर की उपलब्धता | सेशन फ़ीचर फ़्लैग प्राप्त करता हो और Anthropic ने उस तरह के सेशन के लिए Tasks चालू किया हो। |
| समर्थित क्लाइंट या रनटाइम | टर्मिनल CLI, Agent SDK या GitHub Actions। VS Code एक्सटेंशन और डेस्कटॉप ऐप अभी MCP Tasks का समर्थन नहीं करते। |
| कॉल कहाँ से आया | कॉल मुख्य बातचीत से आया हो। सबएजेंट के कॉल MCP Tasks नहीं बनते। |
| इनपुट मोड | इंटरैक्टिव सेशन, या नीचे दी गई अतिरिक्त शर्तें पूरी करने वाला Agent SDK अथवा स्ट्रीमिंग इनपुट सेशन। |
गैर-इंटरैक्टिव काम के लिए Agent SDK सेशन या --input-format stream-json के साथ चलाए गए claude -p को इन सेटिंग की भी ज़रूरत होती है:
CLAUDE_AUTO_BACKGROUND_TASKS=1CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUNDका मान1न होCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSका मान0न हो
इनपुट स्ट्रीम खुली रखें: इनपुट बंद होने के बाद रन MCP Tasks के पूरा होने का इंतज़ार नहीं करता। एक बार चलकर बंद होने वाले claude -p "..." को Tasks नहीं मिलते। GitHub Actions का समर्थित होना इनपुट मोड की इन शर्तों को नहीं हटाता।
एनवायरनमेंट वेरिएबल के संदर्भ दस्तावेज़ में फ़्लैग प्राप्त करने से रोकने वाली ये सेटिंग दी गई हैं:
DISABLE_GROWTHBOOK=1याtrueDO_NOT_TRACK=1DISABLE_TELEMETRYका कोई भी गैर-खाली मानCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICका कोई भी गैर-खाली मान
अंतिम दो वेरिएबल के लिए 0 या false भी संबंधित व्यवहार को बंद कर देता है। Amazon Bedrock जैसे थर्ड-पार्टी प्रदाताओं के सामान्य सेशन भी फ़्लैग प्राप्त नहीं करते। दस्तावेज़ में उन एम्बेडेड इंटीग्रेशन के लिए अपवाद दिया गया है जिनमें होस्ट ऐप प्रदाता को संभालता है।
लॉन्च करने वाले एनवायरनमेंट और वास्तव में लागू हो रही सेटिंग की जाँच करें। आम सेटिंग फ़ाइलें ~/.claude/settings.json, .claude/settings.json और .claude/settings.local.json हैं; संगठन की प्रबंधित सेटिंग भी लागू हो सकती हैं। सेटिंग का संदर्भ दस्तावेज़ बताता है कि कौन-सी सेटिंग कहाँ प्रभावी होती है।
पुराने मोड की सेटिंग हटाने से ऐसे सर्वर में नया प्रोटोकॉल नहीं जुड़ जाता जो उसका समर्थन ही नहीं करता। इसी तरह, गेटवे के ज़रिए API संगतता मिलने से यह साबित नहीं होता कि सेशन ज़रूरी फ़ीचर फ़्लैग प्राप्त कर सकता है। यदि आपकी तैनाती में कोई बाधक सेटिंग बनाए रखना ज़रूरी है, तो सामान्य टूल कॉल इस्तेमाल करें।
इंटरैक्टिव सेशन में CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=0 Claude को इंतज़ार कराता है। CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND=1 भी उसे Tasks का इंतज़ार कराता है, हालाँकि सामान्य ऑटोमैटिक बैकग्राउंड व्यवस्था बाद में किसी लंबे कॉल को बैकग्राउंड में भेज सकती है। अकेले CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 से MCP Tasks को फ़ोरग्राउंड में रहने के लिए बाध्य नहीं किया जा सकता।
एक जॉब चलाएँ और नतीजा जाँचें
ऐसे सर्वर से शुरुआत करें जिसके लिए प्रमाणीकरण पूरा हो और जिसकी दस्तावेज़ी जानकारी या इम्प्लीमेंटेशन से Tasks का समर्थन साबित होता हो। फिर ऐसा एक काम आज़माएँ जो नुकसान पहुँचाने वाले बदलाव न करे। Bash में इंटरैक्टिव CLI खोलने से पहले इंस्टॉलेशन और कॉन्फ़िगर किए गए सर्वर जाँचें:
claude --version
claude mcp list
claudeयदि वर्शन न्यूनतम ज़रूरत से पुराना है और आपकी इंस्टॉलेशन में अपडेट की सुविधा मौजूद है, तो claude update चलाएँ और दोबारा जाँचें। ये कमांड CLI के संदर्भ दस्तावेज़ में दिए गए हैं।
Claude Code के भीतर /mcp से पुष्टि करें कि सर्वर जुड़ा है और ज़रूरी प्रमाणीकरण पूरा करें। यदि टेस्ट चलाने वाला टूल जुड़ा है, तो यह अनुरोध दे सकते हैं:
मुख्य बातचीत से इस रिपॉज़िटरी के MCP टूल के ज़रिए इसके टेस्ट चलाओ। टेस्ट चलने के दौरान README के आधार पर टेस्ट की संरचना समझाओ। काम पूरा होने पर नतीजा और किसी भी विफलता की जानकारी दो।
व्यवहार को दो स्तरों पर जाँचें:
- Claude Code में: MCP टास्क की संख्या देखें और
/tasksखोलें। सिर्फ़/tasksमें एंट्री आना पर्याप्त नहीं है, क्योंकि सामान्य बैकग्राउंड कॉल भी वहाँ दिखते हैं। - सर्वर के ट्रेस में: पुष्टि करें कि
tools/callनेresultType: "task"लौटाया और बाद केtasks/getअनुरोध उसीtaskIdका इस्तेमाल कर रहे हैं।
काम पूरा होने पर Claude Code को नतीजा मिलता है; Claude से उसे बताने को कहें। अगर Claude खाली है, तो वह नतीजे पर अपने आप काम शुरू कर सकता है। यदि कॉल सामान्य ही रहता है, तो टूल दोबारा लिखने से पहले वास्तविक अनुरोध में घोषित क्षमताएँ और शर्तों की सूची जाँचें।
सर्वर बनाने वालों के लिए: हैंडल लौटाएँ और नतीजा पहुँचाएँ
पुराना प्रयोगात्मक उदाहरण कॉपी करने के बजाय मौजूदा Tasks एक्सटेंशन लागू करें। MCP 2026-07-28 के बदलावों में tasks/result की जगह tasks/get के ज़रिए पोलिंग आई, tasks/update जोड़ा गया और tasks/list हटा दिया गया।
टास्क तभी लौटाएँ जब अनुरोध में उसका समर्थन घोषित हो
हर अनुरोध में इस पाथ पर समर्थन जाँचें:
params._meta["io.modelcontextprotocol/clientCapabilities"].extensions["io.modelcontextprotocol/tasks"]
इसका मान {} होता है। आपका सर्वर server/discover के जवाब में capabilities.extensions के तहत संबंधित एक्सटेंशन घोषित करता है। Tasks एक्सटेंशन का परिचय दोनों स्थान समझाता है।
क्लाइंट समर्थन घोषित करता है, उसके बाद सर्वर तय करता है कि उस खास ऑपरेशन को Task बनाना है या नहीं। समर्थन न हो, तो जहाँ संभव हो सामान्य नतीजा लौटाएँ। यदि ऑपरेशन के लिए Tasks ज़रूरी हैं, तो एक्सटेंशन में अनुपस्थित क्लाइंट क्षमता के लिए -32021 त्रुटि तय है; ऐसे क्लाइंट को टास्क हैंडल न लौटाएँ जो उसे संभाल नहीं सकता।
जवाब देने से पहले टास्क को स्थायी रूप से सहेजें, ताकि tasks/get उसके ID से उसे तुरंत ढूँढ़ सके। नए कनेक्शन पर भी टास्क उपलब्ध रहना चाहिए। बाद के अनुरोधों में प्रमाणीकरण और उस टास्क तक पहुँच की अनुमति जाँचें।
यह उदाहरणात्मक JSON-RPC जवाब एक बिल्ड स्वीकार करता है। इसके ID, टाइमस्टैम्प और बाद में मिलने वाला नतीजा उदाहरण हैं, किसी वास्तविक रन का रिकॉर्ड नहीं:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"resultType": "task",
"taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
"status": "working",
"createdAt": "2026-10-24T08:00:00Z",
"lastUpdatedAt": "2026-10-24T08:00:00Z",
"ttlMs": 3600000,
"pollIntervalMs": 5000
}
}टास्क के फ़ील्ड सीधे JSON-RPC result के भीतर रहते हैं। अतिरिक्त task रैपर नहीं होता, और शुरुआती हैंडल में content ऐरे की ज़रूरत नहीं होती।
| फ़ील्ड | ज़रूरत |
|---|---|
resultType | टास्क लौटाने वाले शुरुआती जवाब के लिए "task"। |
taskId | ज़रूरी, सर्वर द्वारा बनाया गया और अनुमान लगाना मुश्किल हो। Claude Code इसे बिना स्पेस वाले अधिकतम 128 प्रिंटेबल ASCII कैरेक्टर तक सीमित भी करता है। |
status | ज़रूरी: working, input_required, completed, failed या cancelled। |
createdAt, lastUpdatedAt | ISO 8601 फ़ॉर्मैट की ज़रूरी टाइमस्टैम्प स्ट्रिंग। |
ttlMs | निर्माण के समय से गिने गए मिलीसेकंड का ज़रूरी पूर्णांक, या असीमित अवधि तक रखने के लिए null। यह काम पूरा होने में लगने वाले समय का अनुमान नहीं है। |
pollIntervalMs | वैकल्पिक फ़ील्ड: पोलिंग अंतराल मिलीसेकंड में, पूर्णांक के रूप में। null न भेजें। |
statusMessage | प्रगति या स्थिति बताने वाला वैकल्पिक टेक्स्ट। |
एक्सटेंशन की प्रकाशित स्कीमा यह संरचना तय करती है। Claude Code की खास जाँचें सर्वर लेखकों के संदर्भ दस्तावेज़ में दी गई हैं।
अगर Claude Unsupported result type 'task' for tools/call दिखाता है, तो जाँचें कि आने वाले अनुरोध में एक्सटेंशन था या नहीं। फिर पुष्टि करें कि taskId, status, createdAt, lastUpdatedAt और ttlMs में से कोई फ़ील्ड गायब नहीं है। status का असमर्थित मान भी यही त्रुटि देता है। गलत टास्क ID पर इसके बजाय टास्क हैंडल के गलत फ़ॉर्मैट की त्रुटि आती है।
टूल का अंतिम नतीजा tasks/get में दें
हर पोलिंग अनुरोध का जवाब टास्क की मौजूदा स्थिति से दें। सफल tasks/get जवाब में resultType: "complete" होता है, भले ही जॉब का status अभी working हो: स्थिति पूछने वाला अनुरोध पूरा हुआ है, ज़रूरी नहीं कि जॉब भी पूरी हो गई हो।
ऊपर दिए गए बिल्ड के लिए पूरा होने का जवाब ऐसा होगा:
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"resultType": "complete",
"taskId": "6f17bfa2-4c5e-4d21-b563-2f7e83a902bc",
"status": "completed",
"createdAt": "2026-10-24T08:00:00Z",
"lastUpdatedAt": "2026-10-24T08:03:00Z",
"ttlMs": 3600000,
"result": {
"resultType": "complete",
"content": [
{
"type": "text",
"text": "Build completed successfully."
}
]
}
}
}भीतर वाला result टूल का सामान्य नतीजा रखता है। isError: true वाली टूल-स्तर की त्रुटि भी completed टास्क में आती है। failed उस JSON-RPC निष्पादन त्रुटि के लिए है जिसे error में दिया जाता है।
tasks/cancel भी लागू करें, लेकिन समझें कि रद्द करने का अनुरोध सर्वर के सहयोग पर निर्भर करता है। एक्सटेंशन की स्पेसिफ़िकेशन यह गारंटी नहीं देती कि रद्द करने से पहले से चल रहा काम रुक जाएगा। Claude Code अभी पोलिंग से नतीजा प्राप्त करता है, इसलिए नतीजा पहुँचाने के लिए notifications/tasks पर निर्भर न रहें।
जिन निर्णयों को टूल नहीं ले सकता, उनके लिए Elicitation इस्तेमाल करें
जिस कार्रवाई के लिए एनवायरनमेंट, गंतव्य या अनुमति की जानकारी चाहिए, उसे करने से पहले वह जानकारी माँगें। फ़ॉर्म मोड में Elicitation संरचित फ़ील्ड से जानकारी लेता है; URL मोड ब्राउज़र में कोई प्रक्रिया खोलने का विकल्प देता है, जैसे बाहरी सेवा में साइन-इन।
Task के दौरान सवाल पूछने के लिए tasks/get के जवाब में status: "input_required" और inputRequests मैप दें। हर एंट्री का अलग की होना चाहिए और उसमें माँगा गया method, जैसे elicitation/create, तथा उसके params होने चाहिए। Claude Code tasks/update के ज़रिए जवाब भेजता है और inputResponses में उन्हीं की का इस्तेमाल करता है।
इंटरैक्टिव CLI में यदि सवाल /tasks के पीछे छिपा हो, तो /tasks बंद करें। मना करना या Esc दबाना Elicitation का जवाब भेजता है; जॉब जारी रहेगी या नहीं, यह सर्वर तय करता है।
यदि कोई Task गैर-इंटरैक्टिव सेशन में उपयोगकर्ता से इनपुट माँगता है, तो Claude Code सर्वर से उसे रद्द करने को कहता है। वह न तो Elicitation हुक चलाता है, न Agent SDK का onElicitation कॉलबैक बुलाता है। बिना निगरानी वाला काम शुरू करने से पहले ज़रूरी विकल्प दे दें या इंटरैक्टिव सेशन इस्तेमाल करें। यह रोक खास तौर पर MCP Tasks के ज़रिए माँगे गए इनपुट पर लागू होती है।
Elicitation के जवाब को मानवीय स्वीकृति मानने से पहले हुक की भी जाँच करें। हुक का संदर्भ दस्तावेज़ बताता है कि:
Elicitationअपने आप जवाब देकर डायलॉग दिखने से रोक सकता है।ElicitationResultउपयोगकर्ता का जवाब बदल सकता है; गलत लिखा हो, तो मना किए जाने को स्वीकृति में भी बदल सकता है।- यदि
Elicitationहुक पहले ही जवाब दे चुका हो, तोElicitationResultनहीं चलता।
उपयोगकर्ता, प्रोजेक्ट, लोकल, प्रबंधित और प्लगइन कॉन्फ़िगरेशन से लागू हो रहे हुक देखें। सिर्फ़ रिपॉज़िटरी की सेटिंग फ़ाइल जाँचने पर वह हुक छूट सकता है जो वास्तव में जवाब दे रहा है।
टास्क रोकने, बाहर निकलने और सेशन दोबारा शुरू करने पर क्या होता है?
यदि रिमोट Task को रद्द करने का अनुरोध भेजना चाहते हैं, तो उसे स्पष्ट रूप से रोकें; CLI से बाहर निकलने पर ऐसा नहीं होता। दस्तावेज़ में दिया गया जीवनचक्र सर्वर पर निष्पादन और Claude Code द्वारा ट्रैक किए जाने के बीच अंतर करता है।
| कार्रवाई | नतीजा और अगला कदम |
|---|---|
/tasks में Task चुनकर x दबाएँ या Claude से उसे रोकने को कहें | Claude Code उसे ट्रैक करना बंद करता है और रद्द करने का अनुरोध भेजता है। सर्वर फिर भी काम पूरा कर सकता है। |
सामान्य बातचीत के दौरान Esc दबाएँ | इससे बैकग्राउंड Task नहीं रुकता। |
| रिमोट Task चलने के दौरान बाहर निकलें | सर्वर की जॉब चलती रहती है। उसे दोबारा ट्रैक करने के लिए मूल सेशन फिर शुरू करें। |
| stdio Task चलने के दौरान बाहर निकलें | लोकल सर्वर की प्रक्रिया बंद हो जाती है। जब तक सर्वर स्पष्ट रूप से उस प्रक्रिया से स्वतंत्र निष्पादन का समर्थन न करे, काम जारी रहने की अपेक्षा न करें। |
Claude Code खुला रखते हुए /clear, /branch इस्तेमाल करें या /resume से सेशन बदलें | नतीजा मौजूदा बातचीत में आ सकता है। बाहर निकलने के बाद वही सेशन दोबारा शुरू करें जहाँ Task शुरू हुआ था। |
| मूल सेशन इंटरैक्टिव तरीके से फिर शुरू करें | सर्वर दोबारा जुड़ने पर ट्रैकिंग शुरू होती है, बशर्ते सर्वर को Task की जानकारी अभी भी हो। उसका नाम और कनेक्शन सेटिंग न बदलें। |
नया सेशन शुरू करें या --fork-session इस्तेमाल करें | नया सेशन Task की ट्रैकिंग नहीं अपनाता। |
एक बार चलने वाले claude -p से सेशन फिर शुरू करें | वह रन Task को ट्रैक नहीं करता। इंटरैक्टिव तरीके से सेशन फिर शुरू करें या ज़रूरी शर्तों वाला स्ट्रीमिंग इनपुट इस्तेमाल करें। |
यदि सर्वर डिस्कनेक्ट है, तो Task रोकने से पहले /mcp के ज़रिए उसे दोबारा जोड़ें। वरना रद्द करने का अनुरोध सर्वर तक नहीं पहुँचेगा और Claude Code Task को भूल जाएगा।
मूल बातचीत चुनने के लिए claude --resume इस्तेमाल करें। सर्वर की डेटा रखने की नीति फिर भी महत्वपूर्ण है: सेशन दोबारा शुरू करने से वह नतीजा वापस नहीं आ सकता जिसे सर्वर हटा चुका है।
अपने MCP सेटअप के ऑडिट के लिए प्रॉम्प्ट
सर्वर या सेटिंग बदलने से पहले बिना बदलाव किए ऑडिट करें, ताकि सबसे छोटा उपयोगी सुधार पता चले। यह प्रॉम्प्ट @Voxyz_ai के MCP ऑडिट सुझाव पर आधारित है और इसमें मौजूदा जवाब के फ़ॉर्मैट तथा स्ट्रीमिंग सेशन के व्यवहार की जाँच जोड़ी गई है।
Goal: Audit my Claude Code MCP setup for Tasks and Elicitation.
Read the current official documentation:
https://code.claude.com/docs/en/mcp
https://code.claude.com/docs/en/env-vars
https://code.claude.com/docs/en/hooks
https://modelcontextprotocol.io/extensions/tasks/overview
Scope: Inspect connected MCP servers, their configuration, effective settings, and any MCP server implementation in this repository. Say explicitly if no server implementation is present. Keep credential values out of the report.
Check:
1. Long-running tools: identify builds, test runs, exports, or research that could benefit from Tasks. For my server code, recommend the smallest change to return a valid task handle, persist it across connections, and deliver the final result through tasks/get. For third-party servers, cite evidence for the deployed version's support; otherwise mark support unknown.
2. Eligibility: check the CLI version, transport, actual protocol revision, per-request Tasks capability, feature-flag fetching, provider, supported surface, main conversation versus subagents, and input mode. Include MCP_SDK_GENERATION, MCP_PROTOCOL_NEGOTIATION, privacy/flag-fetching variables, CLAUDE_AUTO_BACKGROUND_TASKS, CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND, and CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS. Distinguish one-shot claude -p from stream-json input.
3. Elicitation: find tools that guess missing parameters or perform irreversible actions without obtaining the necessary decision. Inspect Elicitation and ElicitationResult hooks for automatic acceptance or changes to a user's refusal, including hooks outside this repository.
4. Lifecycle: check cancellation, remote versus stdio execution, retention, and resume. Identify unattended Tasks that might request user input.
Output: For each finding, name the tool or setting, cite the evidence, describe current behavior, recommend the smallest change, and give one verification step. Mark conditions you cannot observe as unknown.
Do not edit files, change settings, or invoke operational jobs during this audit. Show recommendations first.
