त्रुटि के बाकी हिस्से से शुरू करें
इतिहास मिटाने से पहले लक्षणों को अलग करें
thread not found
सेव स्थान के संदर्भ की त्रुटि (इतिहास अक्सर फिर भी पढ़ा जा सकता है)
Timeout / App server request expired while queued
विषय-सूची
- 1. thread not found का मतलब क्या है
- 2. केस स्टडी: इतिहास बचा रहते हुए भेजना फिर से चालू हुआ
- 3. सिर्फ भेजना विफल होने पर आज़माने का क्रम
- 4. वही संदेश, पर कारण और उपाय एक नहीं हो सकते
- 5. फिर भी न चले तो: जाँच और हस्तांतरण
- 6. जाँच का अनुरोध करते समय साथ रखने योग्य जानकारी
- 7. पुनः चालू हुआ या नहीं, यह एक छोटे जवाब से जाँचें
- FAQ
1. thread not found का मतलब क्या है
OpenAI के Codex में किसी मौजूदा टास्क पर आगे का संदेश भेजते समय ऐसी त्रुटि दिख सकती है। अंत में दिया गया ID संबंधित बातचीत की पहचान करता है, जिसे नीचे छिपाया गया है।
メッセージの送信中にエラーが発生しました
thread not found: <बातचीत का ID>अंग्रेज़ी में दिखने वाले ऐप में पहली पंक्ति Error submitting message होती है (#30710)।
Error submitting message
thread not found: <बातचीत ID>यह लेख डेस्कटॉप ऐप के मौजूदा लोकल टास्क पर लागू होता है। यह हमारे वातावरण (Windows) में देखे गए एक उदाहरण के लॉग, सार्वजनिक सोर्स कोड और उपयोगकर्ताओं की बग रिपोर्ट के आधार पर, 21 सितंबर 2026 तक की स्थिति के अनुसार तैयार किया गया है।
“पढ़ पाना” और “भेज पाना” अलग-अलग जाँच हैं
सेव किया गया इतिहास
पिछली बातचीत पढ़ें
सेव डेटा लोड करना
निष्पादन के लिए लोड बातचीत
नए निर्देश स्वीकार करे
बातचीत फिर से शुरू करना → अगला निर्देश
अगर निष्पादन वाली बातचीत नहीं मिलती, तो पिछला इतिहास दिखने पर भी भेजना विफल हो सकता है।
इतिहास दिखाना और नए निर्देश स्वीकार करना अलग तंत्र हैं। कुछ समय से न खोले गए टास्क में इतिहास पढ़ा जा सकता है, पर निर्देश स्वीकार करने वाली ओर बातचीत लोड न हो। ऐसे में सीधे भेजने पर यही त्रुटि आती है।
तंत्र का विवरण (ऐप के भीतर के संचार नाम)
आधिकारिक App Server विनिर्देश के अनुसार, thread/read सेव किया गया इतिहास पढ़ता है; वह बातचीत को निष्पादन की मेमोरी में लोड नहीं करता। बातचीत को आगे बढ़ाने वाले thread/resume से इसकी भूमिका अलग है। ये ऐप के भीतर के संचार नाम हैं, चैट बॉक्स में टाइप किए जाने वाले कमांड नहीं।
हमारे वातावरण के सेव मेटाडेटा में दिख रहे CLI संस्करण 0.155.0-alpha.9 से संबंधित भेजने की प्रक्रिया का सार्वजनिक सोर्स कोड में, turn/start का प्रवेश बिंदु बातचीत लाता है, और विफल होने पर thread not found लौटाता है। यह खोज मेमोरी में मौजूद बातचीत की सूची में होती है, इसलिए यह त्रुटि सेव फ़ाइल के खो जाने का संकेत नहीं है।
notLoaded वह सामान्य स्थिति है जिसमें सेव की गई बातचीत अभी निष्पादन के लिए लोड नहीं है। आधिकारिक App Server विनिर्देश के अनुसार, जिस बातचीत का आख़िरी सब्सक्राइबर हट जाए, वह 30 मिनट तक बिना सब्सक्राइबर और बिना गतिविधि रहने पर अनलोड होकर notLoaded बन जाती है। समस्या तब होती है जब उस स्थिति से ज़रूरी फिर से शुरू करने की प्रक्रिया नहीं होती और अगला निर्देश स्वीकार नहीं होता। हमारे उदाहरण में भी विफलता आख़िरी सफल भेजने के एक घंटे से ज़्यादा बाद हुई थी।
2. केस स्टडी: इतिहास बचा रहते हुए भेजना फिर से चालू हुआ
यह हमारे वातावरण का एक उदाहरण है। Windows ऐप 26.915.31029 के एक टास्क में, जारी रखने का निर्देश भेजते समय यह त्रुटि आई। नीचे 21 सितंबर 2026 के ऐप लॉग को UTC समय में बदलकर, बातचीत ID और कार्य का विवरण हटाकर व्यवस्थित किया गया है।
स्क्रीन पर दोबारा कोशिश से वास्तविक पुनः लोड तक
भेजना विफल (आंतरिक उत्तर था thread not found)
स्क्रीन पहले ही बातचीत को फिर से शुरू मान चुकी थी
फिर खोलने के बाद भी वही भेजने की त्रुटि
सिर्फ स्क्रीन बदलने से सुधार नहीं हुआ
अनलोड अवस्था की पुष्टि → बातचीत सफलतापूर्वक दोबारा लोड
अनलोड → फिर से शुरू की ज़रूरत तय → फिर से शुरू सफल
अगला निर्देश स्वीकार हुआ; भेजना सफल
बाद की इतिहास जाँच में दोनों टर्न completed और बिना त्रुटि के दिखे
सेव की गई बातचीत और कार्य डायरेक्टरी बनी रही, और इतिहास पढ़ने का काम भी सफल रहा। मूल टास्क आर्काइव नहीं हुआ था।
इस उदाहरण में जो पुष्टि हुई
- इतिहास बचा रहा
- दोबारा लोड होने के बाद भेजना सफल हुआ
- जाँच में इतिहास या सेटिंग नहीं बदली गई
इस उदाहरण से जो पता नहीं चलता
- बातचीत आंतरिक रूप से अनलोड होने का सटीक कारण
- सभी उपयोगकर्ताओं में समान कारण
संभावित कारण एक असंगति है: स्क्रीन बातचीत को फिर से शुरू मान रही थी, जबकि भीतर से वह लोड नहीं हुई थी। भेजना वापस आने के बाद उस टर्न का कार्य सही है या नहीं, यह भी जाँचें।
3. सिर्फ भेजना विफल होने पर आज़माने का क्रम
पहले इनपुट न खोए, इसके लिए उसे अपने पास सेव करें। भेजें बटन बार-बार दबाने से पहले देखें कि वही निर्देश बातचीत में पहले से जुड़ा तो नहीं, या प्रसंस्करण शुरू तो नहीं हो गया। ख़ासकर प्रकाशन, हटाने या ख़रीदारी वाले निर्देशों में, प्रतिक्रिया में देर वाले अनुरोधों को एक के ऊपर एक न भेजना बहुत ज़रूरी है।
बातचीत और अपना हाल का कार्य जाँचें
पिछले संदेश पढ़े जा सकते हैं या नहीं, और आख़िरी निर्देश पूरा, चालू या त्रुटि वाला दिख रहा है या नहीं, यह देखें। अगर टास्क सूची में न दिखे, तो Settings में "Archived chats" भी खोलें (आधिकारिक समस्या-निवारण गाइड में बताया गया है)। अगर आपने फ़ाइलें संपादित की हैं, तो उन्हें सेव करें और कार्य का स्थान नोट कर लें। बातचीत दिखने की गड़बड़ी और कार्य फ़ाइलों के गायब होने को अलग-अलग मानें।
लोड होने दें, फिर वही टास्क दोबारा खोलें
अगर अभी-अभी टास्क खोला है, तो इतिहास दिखने के स्थिर होने का इंतज़ार करें। किसी दूसरे टास्क पर जाकर लौटें और एक छोटी जाँच आज़माएँ। हमारे उदाहरण में अकेले इस कदम से समस्या नहीं सुलझी, इसलिए एक ही संदेश बार-बार भेजने के बजाय अगले चरण पर जाएँ।
दूसरे कार्य जाँचें, फिर ऐप को पूरी तरह रीस्टार्ट करें
अगर कोई दूसरा टास्क चल रहा है, तो उसके पूरा होने का इंतज़ार करें, या ज़रूरी सामग्री सेव करके उसे रोकें। फिर ऐप बंद करें, दोबारा चालू करें और वही टास्क खोलें। टास्क का दृश्य बदलना और पूरे ऐप को रीस्टार्ट करना अलग-अलग क्रियाएँ हैं।
छोटी प्रतिक्रिया पूरी होती है या नहीं, जाँचें
मूल बड़ा कार्य तुरंत दोबारा न भेजें। ऐसा छोटा जाँच संदेश भेजें जिसमें फ़ाइल बदलाव या टूल का उपयोग न हो। प्रतिक्रिया पूरी होने पर हाल का कार्य जाँचें और सामान्य काम पर लौटें।
जाँच संदेश को इस तरह सीमित कर सकते हैं। यह मॉडल को सामान्य निर्देश के रूप में भेजा जाता है, इसलिए यह सामान्य रूप से उपयोग-खपत में गिना जा सकता है।
यह कनेक्शन की जाँच है। पिछला काम फिर से शुरू न करें।
फ़ाइलें न पढ़ें-लिखें और कोई टूल कॉल न करें,
केवल “जवाब मिल गया।” लौटाएँ।OpenAI के GitHub रिपॉज़िटरी पर रिपोर्ट #30710 में एक ऐसा मामला है जहाँ Windows पर बातचीत खोलने के ठीक बाद का भेजने का विफल होना ऐप को पूरी तरह रीस्टार्ट करने से ठीक हो गया। आधिकारिक समस्या-निवारण मार्गदर्शन में "चल रहे टास्क के पूरा होने का इंतज़ार करके रीस्टार्ट करें" का जो चरण है, वह अंतर्निर्मित टर्मिनल के जम जाने वाले मामलों के लिए है; वह इस भेजने की त्रुटि के लिए मार्गदर्शन नहीं है।
अपडेट आज़माने से पहले, अपना मौजूदा ऐप संस्करण और लक्षण दर्ज करें। आधिकारिक समस्या-निवारण गाइड के अनुसार, डेस्कटॉप ऐप के साथ आने वाला Codex और अलग से इंस्टॉल किया गया CLI अलग संस्करण के हो सकते हैं। CLI अपडेट करने से ऐप की गड़बड़ी ठीक नहीं हो जाती।
4. वही संदेश, पर कारण और उपाय एक नहीं हो सकते
सिर्फ "Error submitting message" वाली पंक्ति देखकर फ़ैसला न करें; उसके बाद के शब्द और विफल हुई क्रिया देखें। नीचे की तालिका सार्वजनिक रिपोर्टों और हमारे वातावरण के उदाहरणों को लक्षण के अनुसार अलग करती है।
| दिखने वाला लक्षण | क्या जाँचें | क्या न मान लें |
|---|---|---|
| इतिहास पढ़ा जाता है, पर भेजना नहीं | दोबारा लोड होने के बाद भेजना काम करता है या नहीं | इतिहास पढ़ पाने का मतलब भेज पाना नहीं है |
| आर्काइव भी विफल / os error 2 | सेव की गई फ़ाइलों और उनके संदर्भ की स्थिति (इतिहास अक्सर फिर भी पढ़ा जा सकता है) | रीस्टार्ट के बाद भेजना लौट आए, तब भी आर्काइव बार-बार विफल हो सकता है |
| Timeout / App server request expired while queued | लगभग 30 सेकंड इंतज़ार हुआ या नहीं, प्रतिक्रिया रुकी या कतार में थी | तुरंत लौटने वाली thread not found के साथ न मिलाएँ |
| जारी रखने के साथ रोकना भी विफल | सच में चल रहा है या स्क्रीन पर पुराना दृश्य है | सिर्फ स्क्रीन पर दिखने वाले “चल रहा है” संकेत पर भरोसा न करें |
इतिहास बचे रहने वाले मामलों के लिए, #30710 में macOS उपयोगकर्ता का जोड़ उपयोगी है। स्क्रीन बातचीत को फिर से शुरू मान रही थी, पर भेजना बार-बार विफल होता रहा; बाद में नई स्क्रीन की ओर से दोबारा लोड सफल हुआ। यह "खोलने के क्षण भर की रेस" से पूरी तरह न समझाई जा सकने वाली स्थिति की असंगति की रिपोर्ट है, और इसका क्रम यहाँ के मामले से काफ़ी मिलता है।
दूसरी ओर, Windows की रिपोर्ट #39179 में इतिहास पढ़ा जा सकता था, पर भेजना और आर्काइव विफल थे, और रिपोर्टकर्ता के वातावरण में यह रीस्टार्ट के बाद भी जारी रहा। बाद के एक जोड़ में बताया गया है कि ऐप को पूरी तरह रीस्टार्ट करने पर जारी रखना संभव हुआ, पर आर्काइव की विफलता निश्चित रूप से ठीक नहीं हुई। #39575 में सेव फ़ाइल नामों के समय-चिह्नों और संदर्भ प्रक्रिया पर निदान है। ये सभी उपयोगकर्ताओं की जाँचें हैं, इसलिए केवल पथ के उपसर्ग या समय के अंतर से यह न मान लें कि आपका अपना डेटा भी ख़राब है।
इंतज़ार वाला प्रकार #27395 की भेजने के टाइमआउट वाली रिपोर्ट में दिखता है, जिसमें लॉग है कि turn/start को 30 सेकंड (timeoutMs=30000) पर रोका गया और Timeout के रूप में विफल हुआ। #23644 के जोड़ में, भेजने की पूर्व-शर्त वाला अनुरोध कतार में लगभग 30 सेकंड (queueWaitMs=30001) रुकने के बाद App server request expired while queued के साथ विफल हुआ। रोकना भी विफल होने वाला प्रकार #42604 की इतिहास और निष्पादन-स्थिति की असंगति वाली रिपोर्ट में देखा जा सकता है।
5. फिर भी न चले तो: जाँच और हस्तांतरण
फिर से शुरू करने के बाद भी न चले, तो सेव किया गया इतिहास पढ़ा जा सकता है या नहीं, यह जाँचें। अगर कोई ऐसी सुविधा उपलब्ध है जिससे कोई सामान्य Codex टास्क लक्ष्य टास्क को पढ़ सकता है, तो केवल पढ़ने वाली जाँच से शुरू करें। लक्ष्य ID को किसी मिलते-जुलते नाम वाले टास्क से न मिलाना भी ज़रूरी है।
लक्ष्य टास्क की केवल-पढ़ने वाले (read-only) मोड में जाँच करें।
लक्ष्य ID: त्रुटि में दिखाई गई बातचीत ID
बताएँ कि इतिहास पढ़ा जा सकता है या नहीं, आख़िरी टर्न की स्थिति, और कोई त्रुटि।
किसी दूसरे टास्क को संदेश न भेजें, पिछला काम फिर से शुरू न करें, फ़ोर्क, आर्काइव, सेटिंग बदलाव, DB संपादन, या इतिहास फ़ाइलों को स्थानांतरित या हटाने जैसा कोई काम न करें।
अगर कोई टास्क-प्रबंधन सुविधा उपलब्ध न हो, तो यह बताएँ।यह टास्क-प्रबंधन सुविधा वाले वातावरण के लिए एक नमूना वाक्य है। अगर ऐसी सुविधा न मिले, तो मिलते-जुलते नाम वाले आंतरिक कमांड का अनुमान लगाकर न चलाएँ; अध्याय 6 की रिपोर्ट पर जाएँ।
जाँच परिणाम के आधार पर अगला कदम चुनें
- इतिहास पढ़ा जा सकता है और पिछला काम पूरा है
- एक अतिरिक्त जाँच संदेश भेजने, या इतिहास आगे ले जाने वाले फ़ोर्क पर विचार करें। मूल टास्क को रखें।
- इतिहास पढ़ा जा सकता है, पर काम चल रहा है या नहीं, यह अस्पष्ट है
- पहले चालू स्थिति और फ़ाइल बदलाव जाँचें। किसी दूसरे टास्क में वही काम दोबारा न चलाएँ।
- स्टोरेज त्रुटि आती है (जैसे os error 2)
- बैकअप सुरक्षित रखें और लॉग के साथ रिपोर्ट करें। लोडिंग ठीक करने के लिए मूल फ़ाइलें न हटाएँ।
#39179 पर एक जोड़ में वर्णन है कि एक दूसरे सामान्य टास्क से छोटा जाँच संदेश भेजा गया, और प्रतिक्रिया पूरी होने के बाद सामान्य बातचीत भी ठीक हो गई। लेकिन एक अन्य जोड़ में ऐसा ही भेजना विफल होने और पूरे हुए इतिहास के फ़ोर्क से नए निर्देश स्वीकार होने की रिपोर्ट है। इस प्रतिउदाहरण के बाद, मूल रिपोर्टकर्ता ने जोड़ा कि यह सामान्य समाधान नहीं है।
फ़ोर्क पूरे हो चुके इतिहास को एक अलग टास्क में आगे ले जाने की क्रिया है; मूल टास्क ठीक नहीं होता। यह न मानें कि अधूरा काम अपने-आप आगे चलता रहेगा। हस्तांतरण के बाद कार्य डायरेक्टरी, बदली गई फ़ाइलें और आख़िरी पूरा हुआ चरण जाँचें।
इतिहास डेटा और कार्य फ़ाइलें भी अलग हैं। बातचीत न खुले, तब भी प्रोजेक्ट के संपादन परिणाम मौजूद हो सकते हैं। इसके उलट, बातचीत पढ़ी जा सके, तब भी फ़ाइलें नवीनतम होंगी ही, ऐसा नहीं। अगर आपका प्रोजेक्ट Git उपयोग करता है, तो बदलावों की सूची जाँचें और जारी रखने से पहले यह तय करें कि क्या पहले ही चल चुका है।
6. जाँच का अनुरोध करते समय साथ रखने योग्य जानकारी
रिपोर्ट में सिर्फ "नहीं भेज पा रहे" नहीं, बल्कि यह भी बताएँ कि क्या सफल हुआ और क्या विफल। ऐप संस्करण, OS, घटना का समय और टाइमज़ोन, लक्ष्य बातचीत ID, और उससे ठीक पहले की क्रिया बताने से अलग-अलग गड़बड़ियाँ मिलाए बिना उन्हें खोजना आसान होता है। शुरू में पूरी बातचीत सार्वजनिक करने की ज़रूरत नहीं है।
रिपोर्ट नोट का ढाँचा
- वातावरण
- ऐप संस्करण / OS / कहाँ चल रहा है, जैसे लोकल या रिमोट
- घटना
- समय और टाइमज़ोन / पूरा त्रुटि संदेश / उससे ठीक पहले की क्रिया
- क्या काम करता है, क्या नहीं
- इतिहास दिखना / भेजना / रोकना / आर्काइव, हर एक का परिणाम
- आज़माई गई क्रियाएँ
- फिर खोलने या रीस्टार्ट के पहले और बाद में क्या बदला
लॉग जाँचे जा सकें तो विफल अनुरोध से पहले और बाद की पंक्तियाँ देखना उपयोगी होता है। method=turn/start निर्देश की शुरुआत बताता है, thread/resume बातचीत फिर से शुरू होना बताता है, और errorCode आंतरिक प्रतिक्रिया का संकेत है। सफल पंक्तियाँ भी रखें, और यह अलग करें कि वही विफलता कई लॉग पंक्तियों में सिर्फ दिखी है, या सच में कई बार विफल हुई।
ऐप लॉग का स्थान: आधिकारिक समस्या-निवारण गाइड में macOS के लिए ~/Library/Logs/com.openai.codex/YYYY/MM/DD दिया गया है। Windows पर हमारे वातावरण में ये दो जगह थीं।
- त्रुटि वाला PC:
%LOCALAPPDATA%\Codex\Logs - दूसरे PC का Microsoft Store संस्करण (मार्च 2026 के लॉग):
%LOCALAPPDATA%\Packages\OpenAI.Codex_<ID>\LocalCache\Local\Codex\Logs(इस PC में%LOCALAPPDATA%\Codexनाम का फ़ोल्डर ही नहीं था)
Microsoft के स्पष्टीकरण के अनुसार, पैकेज्ड ऐप AppData में जो नई फ़ाइलें बनाता है, वे ऐप-विशेष स्थान में लिखी जाती हैं और ऐप को सामान्य स्थान में दिख सकती हैं। एक जगह न मिले तो दूसरी भी खोजें। आधिकारिक रूप से सेशन का सेव स्थान $CODEX_HOME/sessions (डिफ़ॉल्ट ~/.codex/sessions) बताया गया है। सेटिंग या चलने का स्थान अलग हो तो जिस फ़ोल्डर को आप देख रहे हैं उसमें लक्ष्य नहीं होगा, इसलिए "खोज में नहीं आता" से ही उसे हटाया गया न मानें।
Codex के डेटा (CODEX_HOME) या ऐप को किसी दूसरे ड्राइव पर ले जाने के बाद क्या कहाँ है, इसकी जाँच का रिकॉर्ड ChatGPT और Codex को दूसरे ड्राइव पर ले जाना में संकलित है।
आधिकारिक समस्या-निवारण गाइड में इनपुट बॉक्स में / टाइप करके फ़ीडबैक भेजने का तरीका बताया गया है। लॉग और स्क्रीनशॉट में बातचीत का पाठ, ईमेल पता, दूसरे प्रोजेक्ट के नाम और स्थानीय पथ हो सकते हैं। सार्वजनिक Issue में ज़रूरी हिस्सा ही गुमनाम करके डालें, और पूरा ID आदि देते समय भेजने वाले और सार्वजनिक दायरे की जाँच करें।
7. पुनः चालू हुआ या नहीं, यह एक छोटे जवाब से जाँचें
इस त्रुटि पर पहली प्रतिक्रिया इतिहास मिटाना नहीं, बल्कि पढ़ा जा सकता है या नहीं, फिर से शुरू हो सकता है या नहीं, और नया निर्देश पूरा होता है या नहीं, इन्हें अलग-अलग जाँचना है। इस मामले में बातचीत दोबारा लोड करने से भेजना लौट आया। स्टोरेज त्रुटि दिखे तो यह अलग रास्ता है, इसलिए अध्याय 5 की जाँच पर जाएँ।
छोटा जवाब पूरा हो जाए, तो मूल निर्देश कहाँ तक पहुँचा यह देखें, और ज़रूरी चरण से आगे बढ़ें। अगर फिर भी ठीक न हो, तो केवल-पढ़ने वाली जाँच और लॉग संरक्षण को प्राथमिकता दें। त्रुटि संदेश गायब होने या सिर्फ फ़ोर्क बन जाने को पुनर्प्राप्ति पूरी मान लेना सही नहीं है।
संबंधित लेख:
- Codex की क्षमता त्रुटि और उपयोग सीमा खत्म होने में अंतर, और उनके उपाय ("Selected model is at capacity" दिखने पर)
- Remote कनेक्शन की शर्तें और डिस्कनेक्ट के बाद की जाँच (निष्पादन स्थान और PC का स्लीप मोड)
- Claude Code की मिलती-जुलती त्रुटियाँ: Prompt is too long (इनपुट का आकार) और MCP error -32000: Connection closed (बाहरी टूल से कनेक्शन)
FAQ
प्र. अगर "thread not found" दिखे, तो क्या बातचीत मिट गई है?
उ. ज़रूरी नहीं। सेव किया गया इतिहास पढ़ा जा सकता है, फिर भी भेजने के लिए ज़रूरी निष्पादन वाली बातचीत लोड न हुई हो सकती है। दूसरी ओर, सेव स्थान का संदर्भ या फ़ाइलें ख़ुद समस्याग्रस्त हो सकती हैं, इसलिए वास्तव में पढ़ पाने की जाँच करें।
प्र. क्या notLoaded एक त्रुटि है?
उ. यह स्थिति अपने-आप में सामान्य है। इसका अर्थ है कि सेव की गई बातचीत अभी निष्पादन के लिए लोड नहीं है। समस्या तब होती है जब जारी रखते समय वह फिर से शुरू नहीं होती और छोटी प्रतिक्रिया भी पूरी नहीं होती।
प्र. क्या रीस्टार्ट करने से हमेशा ठीक हो जाएगा?
उ. हमेशा नहीं। पूरे रीस्टार्ट से ठीक होने की रिपोर्ट (#30710) भी है, और रीस्टार्ट के बाद भी भेजने व आर्काइव की विफलता जारी रहने की रिपोर्ट (#39179) भी। हमारे उदाहरण में बातचीत दोबारा लोड होने के बाद भेजना लौटा।
प्र. क्या नवीनतम संस्करण में अपडेट करने से समस्या सुलझ जाएगी?
उ. 21 सितंबर 2026 तक हमें ऐसा कोई सुधरा हुआ संस्करण नहीं मिला जिसमें इस लक्षण को पूरी तरह ठीक करने का स्पष्ट उल्लेख हो। अपडेट करते समय पहले और बाद के ऐप संस्करण और परिणाम दर्ज करें। अलग से इंस्टॉल किए गए CLI और ऐप के साथ आने वाले Codex के संस्करण हमेशा एक जैसे नहीं होते।
