Codex में “thread not found” दिखने का मतलब यह ज़रूरी नहीं कि बातचीत का इतिहास मिट गया है। पहले यह देखें कि केवल संदेश भेजना विफल हो रहा है या बातचीत खुल भी नहीं रही है।
पहले त्रुटि संदेश का बाकी हिस्सा पढ़ें
इतिहास मिटाने से पहले लक्षण पहचानें
thread not found
os error 2 / सहेजे गए डेटा से जुड़ी त्रुटियाँ
Timeout / request expired
विषय-सूची
- 1. thread not found में Codex को क्या नहीं मिलता?
- 2. वास्तविक मामला: इतिहास मिटाए बिना संदेश फिर जाने लगे
- 3. केवल संदेश भेजना विफल हो तो क्या करें?
- 4. एक जैसा संदेश, लेकिन अलग कारण और उपाय
- 5. समस्या बनी रहे तो जाँच और काम आगे सौंपने के विकल्प
- 6. मदद माँगते समय कौन-सी जानकारी रखें?
- 7. छोटे उत्तर से पुष्टि करें कि समस्या दूर हुई है
- अक्सर पूछे जाने वाले सवाल
1. thread not found में Codex को क्या नहीं मिलता?
OpenAI के Codex में किसी मौजूदा टास्क को अगला निर्देश भेजने पर ऐसा त्रुटि संदेश आ सकता है। इसके बाद की ID उस बातचीत की पहचान करती है; यहाँ उसे छिपाया गया है। नीचे पहली पंक्ति हमारे मामले में दिखे जापानी संदेश का अनुवाद है।
संदेश भेजते समय त्रुटि हुई
thread not found: <बातचीत की ID>यह लेख डेस्कटॉप ऐप के मौजूदा लोकल टास्क के बारे में है। 21 सितंबर 2026 को हमने अपने कंप्यूटर के विफल संदेशों के लॉग की तुलना सार्वजनिक स्रोत कोड और उपयोगकर्ताओं की रिपोर्टों से की। मुख्य उदाहरण हमारे Windows कंप्यूटर का है; यह हर परिवेश में काम करने वाला प्रमाणित समाधान नहीं है।
इतिहास पढ़ने और संदेश भेजने की अलग-अलग जाँच करें
सहेजा गया इतिहास
पिछली बातचीत पढ़ना
thread/read
सहेजा गया डेटा प्राप्त करना
चलाने के लिए लोड की गई बातचीत
नया निर्देश स्वीकार करना
thread/resume → turn/start
बातचीत फिर शुरू करना → अगला निर्देश चलाना
चलाने के लिए आवश्यक बातचीत न मिलने पर संदेश भेजना विफल हो सकता है, जबकि पुराना इतिहास दिखाई देता रहता है।
आधिकारिक App Server विनिर्देश के अनुसार, thread/read सहेजा इतिहास पढ़ता है, लेकिन बातचीत को रनटाइम मेमोरी में लोड नहीं करता। यह thread/resume से अलग है, जो काम जारी रखने के लिए बातचीत फिर शुरू करता है। ये ऐप के आंतरिक संचार तरीकों के नाम हैं, चैट में टाइप करने वाले कमांड नहीं।
हमने अपने कंप्यूटर के सहेजे मेटाडेटा में दर्ज CLI संस्करण 0.155.0-alpha.9 के अनुरूप संदेश भेजने का सार्वजनिक स्रोत कोड भी देखा। turn/start की शुरुआत में बातचीत प्राप्त की जाती है। यह खोज विफल होने पर thread not found लौटता है। खोज मेमोरी में मौजूद बातचीत की सूची में होती है, इसलिए केवल इस त्रुटि से यह नहीं कहा जा सकता कि सहेजी गई फ़ाइलें गायब हैं।
notLoaded अपने आप में त्रुटि की स्थिति नहीं है। इसका अर्थ है कि सहेजी गई बातचीत अभी चलाने के लिए लोड नहीं है। समस्या तब होती है जब आवश्यक पुनः शुरू करने की प्रक्रिया नहीं चलती और बातचीत अगला निर्देश स्वीकार नहीं कर पाती। केवल इन शब्दों से सामान्य अनलोडिंग, सहेजे डेटा के स्थान का संदर्भ न मिलना, गलत बातचीत ID या अन्य कारणों में अंतर नहीं किया जा सकता।
2. वास्तविक मामला: इतिहास मिटाए बिना संदेश फिर जाने लगे
AI Arte के कार्य परिवेश में Windows ऐप संस्करण 26.915.31029 के एक अन्य टास्क को काम जारी रखने का निर्देश भेजते समय यह त्रुटि आई। नीचे 21 सितंबर 2026 के ऐप लॉग का सार है। सभी समय जापान मानक समय (JST) में हैं; बातचीत की ID, काम का विवरण और निजी जानकारी हटा दी गई है।
इंटरफ़ेस में फिर कोशिश करने से वास्तविक पुनः लोडिंग तक
संदेश भेजना विफल। आंतरिक उत्तर था thread not found
इंटरफ़ेस बातचीत को पहले से शुरू हो चुकी मान रहा था
टास्क दोबारा खोलने पर भी वही त्रुटि
दूसरी स्क्रीन पर जाकर लौटने से सुधार नहीं हुआ
अनलोड स्थिति दिखी → बातचीत सफलतापूर्वक दोबारा लोड हुई
notLoaded → needs_resume → thread/resume सफल
नए निर्देश स्वीकार हुए। संदेश भेजना सफल रहा
बाद की इतिहास जाँच में दोनों टर्न completed थे और कोई त्रुटि नहीं थी
सहेजी बातचीत और कार्य फ़ोल्डर मौजूद थे, और इतिहास पढ़ना सफल रहा। मूल टास्क आर्काइव नहीं किया गया था। हमने बातचीत के डेटाबेस या सेटिंग बदले बिना केवल पढ़कर लॉग और सहेजी स्थिति की जाँच की।
इस मामले से क्या साबित हुआ?
- इतिहास मौजूद था
- दोबारा लोड होने के बाद संदेश भेजना सफल रहा
- जाँच में इतिहास या सेटिंग नहीं बदली गईं
इससे क्या साबित नहीं होता?
- रनटाइम बातचीत अनुपलब्ध होने का सटीक कारण
- दोबारा शुरू करने से समस्या हमेशा दूर होती है
- सभी उपयोगकर्ताओं के लिए एक ही कारण है
इंटरफ़ेस की “फिर शुरू हो चुकी” स्थिति और आंतरिक स्थिति के बीच असंगति एक संभावित मजबूत व्याख्या है। लेकिन हमने समस्या को दोबारा उत्पन्न करके यह नहीं तय किया कि यह असंगति ठीक कैसे बनी। नवीनतम टर्न की स्थिति देखना और उनमें किए गए काम की शुद्धता जाँचना भी अलग बातें हैं। हमारी बहाली की पुष्टि केवल संदेश भेजने और बातचीत की स्थिति तक सीमित है।
3. केवल संदेश भेजना विफल हो तो क्या करें?
पहले अपने लिखे निर्देश की प्रति रखें, ताकि वह खो न जाए। बार-बार भेजने का बटन दबाने से पहले देखें कि वही निर्देश बातचीत में जुड़ तो नहीं गया है या उसका काम शुरू तो नहीं हो गया है। केवल देर से उत्तर मिलने वाले अनुरोध को दोबारा न भेजें, खासकर जब उसमें प्रकाशित करना, मिटाना या खरीदना शामिल हो।
बातचीत और ठीक पहले का काम जाँचें
देखें कि पुराने संदेश पढ़े जा रहे हैं या नहीं और अंतिम निर्देश पूरा, चल रहा या त्रुटि में दिख रहा है। बदली गई फ़ाइलें सहेजें और काम का स्थान लिख लें। बातचीत दिखाने में समस्या का अर्थ यह नहीं कि काम की फ़ाइलें खो गई हैं।
लोड होने दें, फिर वही टास्क दोबारा खोलें
यदि अभी टास्क खोला है, तो इतिहास का लोड होना पूरा होने दें। किसी दूसरे टास्क पर जाकर लौटें और एक छोटी जाँच करें। हमारे मामले में केवल इससे समस्या नहीं सुलझी, इसलिए एक ही अनुरोध बार-बार भेजते रहना उपयोगी तरीका नहीं है।
दूसरे काम जाँचें, फिर ऐप सामान्य तरीके से दोबारा शुरू करें
यदि कोई दूसरा टास्क चल रहा है, तो उसके पूरा होने की प्रतीक्षा करें या आवश्यक सामग्री सहेजकर उसे रोकें। फिर ऐप बंद करके दोबारा चलाएँ और वही टास्क खोलें। टास्क की स्क्रीन बदलना और पूरा ऐप दोबारा शुरू करना अलग प्रक्रियाएँ हैं।
देखें कि छोटा उत्तर पूरा होता है या नहीं
मूल बड़ा काम तुरंत फिर भेजने के बजाय ऐसा जाँच संदेश भेजें जिसमें फ़ाइल बदलने या टूल चलाने की ज़रूरत न हो। उत्तर पूरा होने पर पिछले काम को जाँचकर सामान्य रूप से आगे बढ़ें।
उदाहरण के लिए, जाँच का दायरा नीचे की तरह सीमित रखें। यह मॉडल को दिया गया निर्देश है, ऐप की समस्या ठीक करने वाला कमांड नहीं। इसे भेजने और मॉडल से उत्तर मिलने पर सामान्य उपयोग सीमा खर्च हो सकती है।
यह कनेक्शन की जाँच है। पिछला काम शुरू न करें, फ़ाइलें न पढ़ें या लिखें,
और कोई टूल न चलाएँ। केवल “उत्तर दिया जा सका” कहें।OpenAI के GitHub रिपॉज़िटरी की रिपोर्ट #30710 में Windows पर बातचीत खोलते ही संदेश भेजने की विफलता में ऐप दोबारा शुरू करने से सुधार का उदाहरण है। आधिकारिक समस्या-निवारण मार्गदर्शिका, अंतर्निहित टर्मिनल अटकने पर, सक्रिय टास्क पूरे होने की प्रतीक्षा करके ऐप दोबारा शुरू करने की सलाह देती है। वह इस खास संदेश-त्रुटि की बहाली प्रक्रिया नहीं है। इन दोनों स्रोतों में से कोई भी यह गारंटी नहीं देता कि दोबारा शुरू करने से हर thread not found त्रुटि ठीक हो जाएगी।
अपडेट आज़माने से पहले ऐप का मौजूदा संस्करण और लक्षण दर्ज करें। ऐप के साथ आने वाला Codex और अलग से इंस्टॉल किया गया CLI अलग संस्करणों के हो सकते हैं। केवल CLI अपडेट करने से यह साबित नहीं होता कि डेस्कटॉप ऐप की समस्या ठीक हो गई। हमें इस लक्षण को स्थायी रूप से ठीक करने वाला कोई निश्चित संस्करण नहीं मिला है।
4. एक जैसा संदेश, लेकिन अलग कारण और उपाय
केवल यह पढ़कर न रुकें कि संदेश भेजना विफल हुआ। बाकी त्रुटि पाठ और विफल हुई क्रिया देखें। नीचे की तालिका सार्वजनिक रिपोर्टों और हमारे अवलोकनों को वर्गीकृत करती है; यह समस्याओं की आवृत्ति की रैंकिंग नहीं है।
| दिखने वाला लक्षण | क्या जाँचें? | क्या मानकर न चलें? |
|---|---|---|
| इतिहास पढ़ सकते हैं, संदेश नहीं भेज सकते | दोबारा लोड होने के बाद भेजना काम करता है या नहीं | इतिहास पढ़ पाना संदेश भेज पाने की गारंटी नहीं |
| os error 2 / आर्काइव करना भी विफल | सहेजी फ़ाइलें और संदर्भित स्थान | केवल दोबारा शुरू करना पर्याप्त न हो |
| Timeout / request expired | रुकी प्रतिक्रिया, कतार और दूसरे कार्यों की स्थिति | इसे तुरंत लौटने वाले thread not found से न मिलाएँ |
| जारी रखना और रोकना, दोनों विफल | वास्तव में काम चल रहा है या स्क्रीन पुरानी स्थिति दिखा रही है | केवल स्क्रीन के चलने वाले संकेत पर भरोसा न करें |
इतिहास बचा रहने वाले उदाहरण के लिए #30710 में macOS उपयोगकर्ता का अगला विवरण देखें। इंटरफ़ेस बातचीत को शुरू हो चुकी मान रहा था, लेकिन संदेश बार-बार विफल हुए; बाद में इंटरफ़ेस के नए इंस्टेंस से दोबारा लोड करना सफल रहा। यह स्थिति की असंगति की रिपोर्ट है, जिसे केवल खोलते समय की क्षणिक रेस कंडीशन से पूरी तरह नहीं समझाया जा सकता। यह हमारे मामले जैसी है, लेकिन समान कारण साबित नहीं हुआ है।
इसके विपरीत, Windows की रिपोर्ट #39179 में संदेश भेजना और आर्काइव करना दोनों विफल रहे तथा दोबारा शुरू करने पर भी समस्या बनी रही। #39575 में सहेजी फ़ाइलों के नामों के समय और उन्हें ढूँढ़ने की प्रक्रिया से जुड़ा निदान भी है। हालाँकि ये उपयोगकर्ताओं की जाँचें हैं। केवल पाथ प्रीफ़िक्स या समय-क्षेत्र का अंतर होने से अपने डेटा को खराब न मानें।
इंतज़ार के बाद विफलता के लिए #27395 की संदेश टाइमआउट रिपोर्ट देखें; रोकना भी विफल होने के लिए #42604 की इतिहास और रनटाइम स्थिति की असंगति रिपोर्ट देखें। मिलते-जुलते संदेशों की रिपोर्टें होना और सभी उपयोगकर्ताओं में समस्या बार-बार होना अलग बातें हैं। इस जाँच में हमें उपयोगकर्ताओं या संदेश प्रयासों की कुल संख्या के अनुपात में घटना-दर नहीं मिली।
5. समस्या बनी रहे तो जाँच और काम आगे सौंपने के विकल्प
दोबारा शुरू करने से लाभ न हो तो देखें कि सहेजा इतिहास पढ़ा जा सकता है या नहीं। यदि आपके परिवेश में किसी दूसरे, ठीक चल रहे Codex टास्क से प्रभावित टास्क पढ़ने की सुविधा है, तो केवल पढ़ने वाली जाँच से शुरुआत करें। लक्ष्य ID सही होनी चाहिए; मिलते-जुलते नाम वाला कोई दूसरा टास्क न चुन लें।
लक्षित टास्क की केवल पढ़कर जाँच करें।
लक्ष्य ID: त्रुटि में दिखी बातचीत की ID यहाँ डालें
बताएँ कि इतिहास पढ़ा जा सकता है या नहीं, अंतिम टर्न की स्थिति और कोई त्रुटि क्या है।
दूसरे टास्क को संदेश न भेजें, पिछला काम शुरू न करें, फ़ोर्क या आर्काइव न करें,
सेटिंग या डेटाबेस न बदलें, और इतिहास की फ़ाइलें न खिसकाएँ या मिटाएँ।
टास्क प्रबंधन टूल उपलब्ध न हों तो यह सीमा स्पष्ट बताएँ।यह ऐसे परिवेश के लिए जाँच अनुरोध का उदाहरण है जहाँ टास्क प्रबंधन टूल उपलब्ध हैं। हर इंटरफ़ेस या CLI में वही सुविधाएँ नहीं होतीं। सुविधा न मिले तो मिलते-जुलते नाम वाले आंतरिक कमांड का अनुमान लगाकर उन्हें चलाने की ज़रूरत नहीं है।
नतीजे के अनुसार अगला कदम चुनें
- इतिहास पढ़ा जा सकता है / पिछला काम पूरा है
- एक और संदेश जाँच या इतिहास आगे ले जाने वाला फ़ोर्क विकल्प हो सकता है। मूल टास्क बनाए रखें।
- इतिहास पढ़ा जा सकता है / चलने की स्थिति अस्पष्ट है
- पहले रनटाइम स्थिति और फ़ाइलों के बदलाव जाँचें। अलग टास्क में वही काम दो बार न चलाएँ।
- इतिहास नहीं पढ़ सकते / सहेजे डेटा से जुड़ी त्रुटियाँ हैं
- बैकअप सुरक्षित रखें और लॉग सहित रिपोर्ट करें। पढ़ना ठीक करने के लिए मूल डेटा न मिटाएँ।
#39179 के एक अगले विवरण में दूसरे ठीक चल रहे टास्क से छोटा जाँच संदेश भेजा गया; उत्तर पूरा होने के बाद सामान्य बातचीत भी फिर चलने लगी। लेकिन एक अन्य विवरण में ऐसा ही संदेश विफल रहा, जबकि पूरे हो चुके इतिहास के फ़ोर्क में नया निर्देश स्वीकार हुआ। इस विपरीत उदाहरण के बाद पहले रिपोर्ट करने वाले ने भी स्पष्ट किया कि यह सार्वभौमिक समाधान नहीं है।
फ़ोर्क बनाना पूरे हो चुके इतिहास को दूसरे टास्क में आगे ले जाने का विकल्प है, मूल टास्क की मरम्मत नहीं। यह न मानें कि अधूरा काम बिल्कुल उसी रूप में दोहराया जाएगा। काम आगे सौंपने के बाद कार्य फ़ोल्डर, बदली फ़ाइलें और आखिरी पूरी हुई प्रक्रिया जाँचें। सार्वजनिक रिपोर्ट में नया निर्देश स्वीकार होना भी उसके बाद का पूरा काम सही ढंग से समाप्त होने की गारंटी नहीं है।
बातचीत का इतिहास और काम की फ़ाइलें भी अलग हैं। बातचीत न खुलने पर भी परियोजना के बदलाव बच सकते हैं। इसके उलट, इतिहास पढ़ पाने से यह तय नहीं होता कि फ़ाइलें नवीनतम हैं। Git वाली परियोजना में बदलावों की सूची देखें और आगे बढ़ने से पहले तय करें कि क्या पहले ही चलाया जा चुका है।
6. मदद माँगते समय कौन-सी जानकारी रखें?
सिर्फ “संदेश नहीं जाता” कहने के बजाय बताएँ कि क्या सफल हुआ और क्या विफल। ऐप संस्करण, OS, समय और समय-क्षेत्र, बातचीत की ID तथा उससे ठीक पहले की क्रिया से अलग-अलग विफलताओं को पहचानना आसान होता है। शुरुआत में पूरी बातचीत सार्वजनिक करने की ज़रूरत नहीं है।
रिपोर्ट के लिए जानकारी का प्रारूप
- परिवेश
- ऐप संस्करण / OS / कार्य चलने का स्थान, जैसे लोकल या रिमोट
- घटना
- समय और समय-क्षेत्र / पूरा त्रुटि संदेश / ठीक पहले की क्रिया
- क्या काम करता है और क्या नहीं
- इतिहास दिखना / संदेश भेजना / रोकना / आर्काइव करना: प्रत्येक का नतीजा
- आज़माए गए कदम
- दोबारा खोलने या शुरू करने से पहले और बाद में क्या बदला?
यदि लॉग देख सकते हैं, तो विफल अनुरोध के आसपास की प्रविष्टियाँ देखें। method=turn/start निर्देश शुरू होने को दर्शाता है, thread/resume बातचीत फिर शुरू करता है, और errorCode आंतरिक उत्तर का संकेत देता है। सफल प्रविष्टियाँ भी रखें और एक ही विफलता की कई लॉग पंक्तियों तथा वास्तव में कई विफल अनुरोधों में अंतर करें।
हमारे Windows कंप्यूटर पर ऐप लॉग %LOCALAPPDATA%\Codex\Logs में थे। यह हमारे उपकरण पर जाँचा गया स्थान है, हर वितरण के लिए गारंटी नहीं। आधिकारिक दस्तावेज़ों में सत्रों का स्थान $CODEX_HOME/sessions और डिफ़ॉल्ट ~/.codex/sessions बताया गया है। सेटिंग या कार्य चलने का स्थान अलग होने पर संबंधित डेटा आपके देखे जा रहे फ़ोल्डर में न हो सकता है। केवल खोज में न मिलने से उसे मिटा हुआ न मानें।
आधिकारिक समस्या-निवारण मार्गदर्शिका इनपुट बॉक्स में / टाइप करके फ़ीडबैक भेजने का तरीका बताती है। लॉग और स्क्रीनशॉट में बातचीत का पाठ, ईमेल पते, दूसरे परियोजना नाम और लोकल पाथ हो सकते हैं। सार्वजनिक Issue में केवल आवश्यक हिस्से पहचान संबंधी जानकारी हटाकर दें। पूरी ID जैसी जानकारी देने से पहले प्राप्तकर्ता और उसकी सार्वजनिक पहुँच जाँचें।
7. छोटे उत्तर से पुष्टि करें कि समस्या दूर हुई है
इतिहास मिटाने से शुरुआत करने के बजाय तीन बातें अलग-अलग जाँचें: क्या इसे पढ़ सकते हैं, क्या फिर शुरू कर सकते हैं और क्या नया निर्देश पूरा होता है? हमारे मामले में दोबारा लोड होने के बाद संदेश भेजना सफल रहा, लेकिन इससे यह साबित नहीं होता कि सहेजे डेटा से जुड़ी दूसरी त्रुटियाँ भी इसी तरह ठीक होंगी।
छोटा उत्तर पूरा होने पर देखें कि मूल निर्देश कहाँ तक चला था, फिर उचित चरण से शुरू करें। समस्या बनी रहे तो केवल पढ़कर जाँच और लॉग सुरक्षित रखने को प्राथमिकता दें। त्रुटि संदेश गायब होना या फ़ोर्क बन जाना भर पूर्ण बहाली नहीं है।
Claude Code इस्तेमाल करने वालों को Prompt is too long भी दिख सकता है, जो इनपुट की क्षमता से संबंधित है, या MCP error -32000: Connection closed दिख सकता है, जिसमें बाहरी टूल से कनेक्शन जाँचना होता है। ये दूसरे उत्पाद की अलग त्रुटियाँ हैं। भले ही लक्षण “AI को निर्देश नहीं दे पा रहे” जैसा हो, उत्पाद नाम और पूरा त्रुटि संदेश देखकर उपाय चुनें। उनके समस्या-निवारण कमांड सीधे Codex बातचीत में न अपनाएँ।
अक्सर पूछे जाने वाले सवाल
प्र. क्या thread not found का मतलब बातचीत मिट गई है?
उ. ज़रूरी नहीं। संदेश लेने के लिए रनटाइम बातचीत लोड न होने पर भी सहेजा इतिहास पढ़ा जा सकता है। लेकिन सहेजे डेटा के संदर्भ या फ़ाइलों में भी समस्या हो सकती है, इसलिए वास्तव में इतिहास पढ़कर जाँचें।
प्र. क्या notLoaded एक त्रुटि है?
उ. केवल स्थिति के नाम से त्रुटि तय नहीं होती। यह सामान्य स्थिति भी हो सकती है, जिसमें सहेजी बातचीत अभी चलाने के लिए लोड नहीं है। देखें कि आगे बढ़ने पर वह फिर शुरू होती है और छोटा उत्तर पूरा होता है या नहीं।
प्र. क्या दोबारा शुरू करने से समस्या हमेशा ठीक होती है?
उ. नहीं। कुछ रिपोर्टों में सुधार हुआ, तो कुछ में दोबारा शुरू करने के बाद भी सहेजे डेटा या आर्काइव की त्रुटियाँ रहीं। हमने अपने कंप्यूटर पर बातचीत दोबारा लोड होने के बाद संदेश सफल होते देखे; दोबारा शुरू करने का प्रभाव जाँचने का प्रयोग नहीं किया।
प्र. क्या नवीनतम संस्करण में अपडेट करने से समस्या हल होगी?
उ. हमारी समीक्षा के समय ऐसा कोई निश्चित संस्करण सत्यापित नहीं था जो इस पूरी श्रेणी के लक्षणों को दूर करता हो। अपडेट से पहले और बाद का ऐप संस्करण और नतीजा दर्ज करें। अलग से इंस्टॉल CLI और ऐप के साथ आने वाला Codex एक ही संस्करण के हों, यह ज़रूरी नहीं।
