Claude Code से माइग्रेशन: पुराना नक्शा, नया टूल, घर का रास्ता फिर भी मिल जाएगा

📚 सीरीज नेविगेशन: पिछला अध्याय〔31 उन्नत तकनीकें और गति बढ़ाना〕पूरी वर्कफ़्लो को अधिक तेज़ी से, अधिक किफायती रूप से और कम रीवर्क के साथ चलाने के बारे में था। यह अध्याय एक अलग दृष्टिकोण लेता है—विशेष रूप से Claude Code से माइग्रेट करने वाले आपके लिए: आपके दिमाग में मौजूद वह मानसिक मॉडल जिसे आपने लंबे समय से इस्तेमाल किया है, उसमें से क्या सीधे स्थानांतरित किया जा सकता है, किसका नाम बदलने की आवश्यकता है, और कौन सी चीजें Codex के लिए विशिष्ट हैं। अगला अध्याय〔33 Windows उपयोग के मुख्य बिंदु〕Windows पर आने वाली विशिष्ट समस्याओं के बारे में बताएगा।

पहले एक वास्तविक बातचीत को देखते हैं। पिछले महीने एक दोस्त, जो हमेशा Claude Code का उपयोग करता था, उसने Codex इंस्टॉल किया और उसके पास सवालों की एक लंबी सूची थी:

उसने कहा: "Codex में CLAUDE.md कहाँ होती है? मेरे प्रोजेक्ट की रूट डायरेक्टरी वाली फ़ाइल को यह क्यों नहीं पढ़ रहा है?" मैंने कहा: "Codex CLAUDE.md नाम को नहीं पहचानता, यह AGENTS.md पढ़ता है। आप इसके कंटेंट को लगभग वैसे ही कॉपी कर सकते हैं।" उसने कहा: "फिर मेरे settings.json में मौजूद allow / deny अनुमतियों (permissions) के नियमों का क्या होगा?" मैंने कहा: "उन्हें भी बदलना होगा—Codex ~/.codex/config.toml (TOML फ़ॉर्मेट) का उपयोग करता है। अनुमतियों के संबंध में इसका दृष्टिकोण 'सैंडबॉक्स + स्वीकृति' (sandbox + approval) है, न कि allowedTools।" उसने कहा: "स्क्रिप्ट चलाने के लिए claude -p का क्या? और क्या /compact, /clear जैसे कमांड यहाँ उपलब्ध हैं?" मैंने कहा: "claude -p यहाँ codex exec से मेल खाता है, और अधिकांश स्लैश कमांड मौजूद हैं और उनके नाम भी लगभग समान हैं। संक्षेप में कहें तो, आपकी 90% आदतें (muscle memory) सीधे यहाँ काम करेंगी।"

यह सुनकर उसने राहत की सांस ली—वास्तव में यह शुरू से एक नया टूल सीखने के बारे में नहीं था, बल्कि एक ही नक्शे पर केवल कुछ स्थानों के नाम बदलने जैसा था。यह अध्याय उसके पूछे गए और कुछ अन्य अनपूछे सवालों का उत्तर देगा: कौन सी अवधारणाएं सीधे मेल खाती हैं, किन अंतरों को सीधे अपनाने से समस्या हो सकती है, और अंत में एक वास्तविक CLAUDE.md को AGENTS.md में फिर से लिखने की व्यावहारिक प्रक्रिया।

इस अध्याय को पढ़ने के बाद, आपको मिलेगा:

मन की शांति: आपका 90% Claude Code मानसिक मॉडल सीधे Codex पर लागू किया जा सकता है, और माइग्रेशन की लागत उम्मीद से बहुत कम है
एक व्यापक "Claude Code अवधारणा → Codex समकक्ष" तुलना तालिका, जो महत्वपूर्ण अंतरों को स्पष्ट करेगी
प्रोजेक्ट मैनुअल, कॉन्फ़िगरेशन फ़ाइल, और अनुमति मॉडल जैसी तीन जगहें जिनके नाम भले ही समान हों, लेकिन उनका व्यवहार अलग है; सीधे कॉपी करने पर समस्या होना तय है
ऐसी कौन सी चीजें हैं जो Claude Code में तो थीं लेकिन Codex में नहीं हैं या भिन्न हैं, इसलिए पहले से कोई धारणा न बनाएं
एक चरण-दर-चरण व्यावहारिक प्रक्रिया जिसके माध्यम से आप CLAUDE.md को AGENTS.md में माइग्रेट कर सकते हैं

⚠️ नीचे दिए गए विशिष्ट कमांड, कॉन्फ़िगरेशन कुंजियाँ (config keys), and डिफ़ॉल्ट व्यवहार Codex आधिकारिक दस्तावेज़ पर आधारित हैं; मॉडल के नाम, संस्करण संख्या जैसी चीजें जो बदल सकती हैं, वे आपके स्थानीय /model पैनल और codex --help के अधीन हैं। दोनों उपकरण तेजी से विकसित हो रहे हैं, यह तुलना तालिका "अवधारणाओं के मिलान" के बारे में है, हर शब्द की पूर्ण गारंटी नहीं है。

01 पहले मन की शांति: आपका 90% मानसिक मॉडल सीधे काम करेगा

पहले सबसे बड़ी चिंता को दूर करते हैं: Claude Code से Codex पर स्विच करते समय, आप शुरू से एक नया टूल नहीं सीख रहे हैं, बल्कि उसी बुनियादी लॉजिक को एक नए आवरण में उपयोग कर रहे हैं。

我为什么这么有底气？因为这俩在最根本的层面是同一类东西——都是终端里的 AI 编程 CLI，都跑「代理循环（agentic loop）」，都能直接读写你真实的代码库。这三点你在 Claude Code 篇里反复见过，到 Codex 这边一个字都不用改。

समानता: एंड्रॉइड से दूसरे ब्रांड के एंड्रॉइड फोन पर स्विच करना。 यह एंड्रॉइड से आईफोन पर स्विच करने जैसा पूर्ण परिवर्तन नहीं है—कॉल करने, संदेश भेजने, ऐप्स इंस्टॉल करने और जेस्चर बैक करने की आपकी आदतें वही रहेंगी। केवल आइकन का स्थान, सेटिंग्स मेनू का स्तर, या कुछ ऐप्स के नाम बदल सकते हैं। आपको "फोन का उपयोग कैसे करें" यह फिर से सीखने की आवश्यकता नहीं है, बल्कि केवल दस मिनट देकर यह समझना है कि "इस नए फोन में चीजें कहाँ हैं"。Codex और Claude Code का संबंध बिल्कुल वैसा ही है。

विशिष्ट रूप से क्या सीधे स्थानांतरित किया जा सकता है? जब मैं खुद Claude Code से इस ओर आया, तो मुझे निम्नलिखित में कभी कोई समस्या नहीं हुई:

"सोचना → करना → देखना" का एजेंटिक लूप: आपका आवश्यकताओं को बताना, इसका योजना बनाना, संशोधन करना, और परिणामों की समीक्षा करना—यह वर्कफ़्लो बिल्कुल समान है।
"पहले इसे पढ़ने दें, योजना समझने के बाद ही काम शुरू करें" की आदत: किसी अपरिचित प्रोजेक्ट पर काम करते समय पहले इसे पूरी तरह से पढ़ने देना, योजना तैयार करना और पुष्टि के बाद ही संशोधन शुरू करना—दोनों उपकरणों में ऐसा ही करना चाहिए。
"प्रोजेक्ट के नियमों को एक फ़ाइल में लिखना और हर बार काम शुरू होने पर स्वचालित रूप से लोड होना" का विचार: केवल फ़ाइल नाम和लोडिंग विवरण में अंतर है (अगले खंड में विस्तृत जानकारी)。
स्लैश कमांड का उपयोग "बातचीत कंसोल" के रूप में करना: मॉडल बदलना, संदर्भ साफ करना, और स्थिति देखना—इन सब का मुख्य द्वार / है。

我第一次正式拿 Codex 干活，是去年把一个 FastAPI 项目从 Claude Code 切过来。我几乎是凭着旧习惯瞎按的——/status 看配置、/model 切模型、改之前先让它出方案——结果八成操作直接命中，剩下两成是文件名和权限设法不一样，翻了下官方文档十分钟就对齐了。那种「咦这我会」的熟悉感，比我预想的强太多。

💡 एक वाक्य में सारांश: Codex और Claude Code एक ही श्रेणी के उपकरण हैं (टर्मिनल CLI + एजेंटिक लूप + वास्तविक कोडबेस को पढ़ना/लिखना), आपका 90% मानसिक मॉडल सीधे स्थानांतरित हो सकता है, केवल यह जानना आवश्यक है कि "चीजें कहाँ हैं और उन्हें क्या कहा जाता है"。

02 एक व्यापक तुलना तालिका: पुराना नाम → नया नाम

यह खंड इस अध्याय का मुख्य ढांचा है—जो Claude Code में आपके द्वारा सीखी गई हर अवधारणा को Codex के समकक्ष नाम और स्थान के साथ मिलाता है। पहले इस तालिका को देखकर एक समग्र समझ विकसित करें, और बाद के खंडों में हम सबसे बड़े अंतरों के बारे में विस्तार से बात करेंगे。

Claude Code	Codex	संबंध	संक्षेप में अंतर
प्रोजेक्ट मैनुअल `CLAUDE.md`	`AGENTS.md`	नाम परिवर्तन	अवधारणा समान है, लेकिन खोज श्रृंखला/ओवरराइड नियम भिन्न हैं (देखें 03)
कॉन्फ़िगरेशन फ़ाइल `~/.claude/settings.json` (JSON)	`~/.codex/config.toml` (TOML)	फ़ॉर्मेट परिवर्तन	JSON → TOML, कुंजी नाम और संरचना पूरी तरह से भिन्न हैं (देखें 04)
अनुमति मोड + `allow`/`ask`/`deny` नियम	सैंडबॉक्स `sandbox` + स्वीकृति `approval`	दृष्टिकोण परिवर्तन	"उपकरण के अनुसार श्वेतसूची (whitelist) बनाने" से बदलकर "कार्यक्षेत्र तय करना + बाहर जाने पर स्वीकृति मांगना" (देखें 05)
हेडलेस मोड `claude -p`	गैर-इंटरैक्टिव कमांड `codex exec`	नाम परिवर्तन	दोनों का अर्थ है "इंटरैक्टिव इंटरफ़ेस में प्रवेश किए बिना काम पूरा करके बाहर निकलना"
`CLAUDE.md` पदानुक्रम (यूज़र / प्रोजेक्ट / सब-डायरेक्टरी)	`AGENTS.md` पदानुक्रम (वैश्विक / प्रोजेक्ट दर प्रोजेक्ट)	समकक्ष	सोच समान है, लेकिन Codex में `AGENTS.override.md` अतिरिक्त है
बाहरी उपकरण MCP	MCP	लगभग सार्वभौमिक	एक ही प्रोटोकॉल है, लेकिन कॉन्फ़िगरेशन का तरीका अलग है
सब-एजेंट Subagents	सब-एजेंट Subagents	समकक्ष	दोनों में उपलब्ध हैं, लेकिन कॉन्फ़िगरेशन का स्थान भिन्न है
कौशल Skills	कौशल Skills	समकक्ष	दोनों में उपलब्ध हैं, लेकिन स्थानीय निर्देशिका संगठन में थोड़ा अंतर है
स्लैश कमांड (`/model`, `/compact`...)	स्लैश कमांड (`/model`, `/compact`...)	अधिकांश समान	कमांड नाम लगभग समान हैं, कुछ अपवादों को छोड़कर (देखें 06)
स्वचालित मेमोरी memory (डिफ़ॉल्ट रूप से चालू)	Memories / Chronicle	समकक्ष लेकिन व्यवहार भिन्न	Codex मेमोरी डिफ़ॉल्ट रूप से बंद है, क्षेत्र प्रतिबंध हैं, और पृष्ठभूमि में जनरेट होती है
मॉडल Opus / Sonnet / Haiku	GPT-5.x सीरीज	मॉडल परिवर्तन	फ्लैगशिप `gpt-5.5`, हल्का `gpt-5.4-mini` आदि

इस तालिका को रटने की आवश्यकता नहीं है, बस एक सामान्य नियम याद रखें:

जो कुछ भी "अवधारणात्मक" स्तर का है (प्रोजेक्ट मैनुअल, अनुमतियां, मेमोरी, सब-एजेंट, कौशल, MCP), वह दोनों तरफ उपलब्ध है, माइग्रेशन का अर्थ केवल "नाम बदलना + सेटिंग्स को समायोजित करना" है; जो चीजें वास्तव में समस्या खड़ी कर सकती हैं, वे हैं जिनके नाम तो समान हैं लेकिन उनका व्यवहार अलग है—जैसे प्रोजेक्ट मैनुअल, कॉन्फ़िगरेशन फ़ाइल, और अनुमति मॉडल。 बाद के तीन खंड इन तीनों से निपटने के तरीके बताएंगे。

至于模型对照，一句话带过：你在 Claude Code 那边按「Opus 啃硬活、Sonnet 跑日常、Haiku 跑杂活」选型号，到 Codex 这边换成「gpt-5.5 啃硬活、gpt-5.4-mini 跑杂活」，选型逻辑（拿任务难度匹配算力）一模一样，详见〔30 怎么选模型〕。注意别把 gpt-5.4 当旗舰——旗舰是 gpt-5.5，gpt-5.4-mini 是它的轻量款。

💡 एक वाक्य में सारांश: वैचारिक स्तर पर दोनों उपकरण लगभग समान हैं, और माइग्रेशन मुख्य रूप से "नाम बदलने + सेटिंग्स को समायोजित करने" के बारे में है; वास्तविक समस्याएं प्रोजेक्ट मैनुअल, कॉन्फ़िगरेशन फ़ाइल और अनुमति मॉडल जैसी तीन जगहों पर आती हैं, जिन्हें हम आगे विस्तार से समझेंगे。

03 项目说明书：`CLAUDE.md` → `AGENTS.md`

这是你迁移时第一个会撞的问题，也是我朋友开口第一问：Codex 不读 CLAUDE.md。 你项目根目录那份它视而不见，因为它认的文件名叫 AGENTS.md。

好消息是：内容你几乎能原样搬。 项目概述、技术栈、常用命令、代码约定、禁改清单——这五类东西在两边都是同样的写法、同样的目的。你在 Claude Code 篇 [18] 学的「写每轮该记住的事实、删一切看代码就能自证的东西」，到 AGENTS.md 这边一字不改照样成立。

समानता: नौकरी बदलने के बाद हैंडओवर दस्तावेज़ तैयार करना。 जब आप नौकरी बदलते हैं, तो पुरानी कंपनी के हैंडओवर दस्तावेज़ की मुख्य जानकारी—तकनीक, परीक्षण कैसे चलाएं, क्या नहीं छूना है—को नई कंपनी के टेम्पलेट में कॉपी किया जा सकता है। लेकिन नई कंपनी के दस्तावेज़ों का फ़ोल्डर संरचना और नामकरण नियम अलग हो सकते हैं, इसलिए आपको उनके नियमों का पालन करना होगा। AGENTS.md बिल्कुल इसी स्थिति का उदाहरण है。

具体到「归档规则」的差异，有几处照搬会出问题，列清楚：

आयाम	Claude Code (`CLAUDE.md`)	Codex (`AGENTS.md`)
वैश्विक (User level) कहाँ रखें	`~/.claude/CLAUDE.md`	`~/.codex/AGENTS.md`
项目级放哪	`./CLAUDE.md` 或 `./.claude/CLAUDE.md`	`./AGENTS.md`（项目根）
子目录级	任意子目录 `CLAUDE.md`，读到才加载	从 Git 根逐级到当前目录，每目录挑一个
अस्थायी ओवरराइड	本地变体 `CLAUDE.local.md`（不进 git）	`AGENTS.override.md`（那一层跳过同级 `AGENTS.md`）
大小红线	按行数（建议 200 行内）	按字节（合并后默认 32 KiB，`project_doc_max_bytes`）

三个最该记住的差异：

पहला, अस्थायी ओवरराइड तंत्र अलग है。 Claude Code CLAUDE.local.md का उपयोग उन व्यक्तिगत प्राथमिकताओं के लिए करता है जिन्हें आप git में शामिल नहीं करना चाहते। Codex में इसके स्थान पर AGENTS.override.md है—जब यह मौजूद होता है, तो उस स्तर पर समतुल्य AGENTS.md को पूरी तरह से अनदेखा कर दिया जाता है। ये दोनों एक ही बात नहीं हैं: पहला "व्यक्तिगत सामग्री जोड़ना" है, जबकि दूसरा "इस स्तर पर मेरी फ़ाइल का उपयोग करें, मूल वाली का नहीं" है। विस्तृत जानकारी के लिए देखें [11]。

दूसरा, आकार की सीमा "लाइनों" से बदलकर "बाइट्स" हो गई है。 Claude Code सिफारिश करता है कि CLAUDE.md 200 लाइनों से अधिक न हो; Codex में यह एक कड़ा नियम है—मर्ज होने के बाद यदि यह डिफ़ॉल्ट 32 KiB से अधिक हो जाती है, तो इसे छोटा कर दिया जाता है या पूरी फ़ाइल को लोड नहीं किया जाता है। मेरे FastAPI प्रोजेक्ट की माइग्रेशन के दौरान मुझे इसका सामना करना पड़ा था: मेरी मूल CLAUDE.md थोड़ी भारी थी, और माइग्रेशन के बाद शुरू में मैंने ध्यान नहीं दिया, लेकिन बाद में पाया कि सब-डायरेक्टरी के नियम काम नहीं कर रहे थे। जाँच करने पर पता चला कि यह बाइट्स की सीमा को पार कर गई थी। इसलिए स्थानांतरण से पहले फ़ाइल को छोटा करें, और ऐसी सामग्री को हटा दें जिसे Codex कोड देखकर खुद समझ सकता है。

तीसरा, खोज श्रृंखला "मर्ज (splice)" है, न कि "ओवरराइट (overwrite)"。 वैश्विक और प्रोजेक्ट स्तर की फ़ाइलें एक ही समय में प्रभावी होती हैं, और संघर्ष होने पर वर्तमान डायरेक्टरी के सबसे करीब वाली फ़ाइल को प्राथमिकता दी जाती है। यह सोच Claude Code के पदानुक्रमित लोडिंग दृष्टिकोण के समान है, लेकिन Codex के मर्ज करने का क्रम (रूट से लेकर सब-डायरेक्टरी तक मर्ज करना, करीब वाली को बाद में मर्ज करना और प्राथमिकता अधिक होना) आधिकारिक रूप से अधिक स्पष्ट है, इसे [11] के अनुसार समझा जा सकता है।

💡 एक वाक्य में सारांश: CLAUDE.md का कंटेंट लगभग वैसे ही AGENTS.md में स्थानांतरित किया जा सकता है, लेकिन फ़ाइल नाम, अस्थायी ओवरराइड तंत्र (CLAUDE.local.md → AGENTS.override.md), और आकार सीमा (लाइनों की संख्या → बाइट्स) जैसे तीन अंतर महत्वपूर्ण हैं, इसलिए माइग्रेशन से पहले फ़ाइल को छोटा करें。

04 कॉन्फ़िगरेशन फ़ाइल: `settings.json` (JSON) → `config.toml` (TOML)

第二个坑：你 ~/.claude/settings.json 里那套配置，不能直接复制到 Codex。两边连文件格式都不一样。

Claude Code: ~/.claude/settings.json (JSON फ़ॉर्मेट), जिसमें अनुमतियाँ, पर्यावरण चर (env vars), हुक्स, और डिफ़ॉल्ट मॉडल सब एक ही फ़ाइल में होते हैं。
Codex: ~/.codex/config.toml (TOML फ़ॉर्मेट), जिसमें मॉडल, सैंडबॉक्स, स्वीकृति, MCP आदि सेटिंग्स मौजूद होती हैं。

समानता: एक ही बिजली फिटिंग का नक्शा, एक मीट्रिक सिस्टम में और दूसरा इंपीरियल में。 नक्शे का उद्देश्य एक ही है (कौन सा तार किस स्विच से जुड़ता है), लेकिन उपयोग की जाने वाली इकाइयाँ और प्रतीक अलग हैं। आप इंपीरियल सिस्टम वाले नक्शे को सीधे मीट्रिक सिस्टम वाले कारीगरों को नहीं सौंप सकते—आपको इकाइयों को बदलना होगा। JSON सेटिंग्स → TOML सेटिंग्स बिल्कुल वैसा ही बदलाव है。

格式差异最直观的几处，对照感受一下：

आप जो सेट करना चाहते हैं	Claude Code (`settings.json`, JSON)	Codex (`config.toml`, TOML)
डिफ़ॉल्ट मॉडल	`"model": "claude-..."`	`model = "gpt-5.5"`
अनुमतियाँ / सुरक्षा	`"permissions": { "deny": [...] }`	`sandbox_mode = "..."` + `approval_policy = "..."`
पदानुक्रमित संरचना	कर्ली ब्रैकेट `{ }` + कोमा	सेक्शन हेडर `[section]` + बराबर का चिह्न
स्ट्रिंग उद्धरण (quotes)	双引号必带	双引号

एक छोटा सा उदाहरण देखें। Claude Code में डिफ़ॉल्ट मॉडल सेट करना (JSON):

json

{
  "model": "claude-sonnet-4"
}

Codex में डिफ़ॉल्ट मॉडल + रीजनिंग शक्ति सेट करना (TOML):

toml

# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"

कुंजी-मान (key-value) जोड़े के लिए = का उपयोग करें, : का नहीं; पूरे ऑब्जेक्ट को कर्ली ब्रैकेट में न लपेटें, बल्कि [section] जैसे सेक्शन हेडर का उपयोग करके समूहित करें; लाइनों के अंत में कोमा (comma) न लगाएं。 जब मैं पहली बार स्विच कर रहा था, तो मैंने आदतवश config.toml की हर लाइन के अंत में कोमा लगा दिया (JSON की आदत के कारण), और Codex ने सीधे पार्सिंग एरर दे दी—यह JSON से TOML पर जाते समय होने वाली एक बहुत ही सामान्य और छोटी सी गलती है, जिसके बारे में मैं आपको पहले ही सचेत कर रहा हूँ。

config.toml में मौजूद सभी सेटिंग्स (मॉडल, सैंडबॉक्स, स्वीकृति, रीजनिंग शक्ति, सेवा स्तर, MCP...) का विस्तृत विवरण〔18 config.toml कॉन्फ़िगरेशन विवरण〕में है। यहाँ आपको बस इतना समझने की आवश्यकता है: पूरी settings.json फ़ाइल का अनुवाद करने की कोशिश न करें, बल्कि [18] में दी गई तालिका के अनुसार केवल उन सेटिंग्स को दोबारा लिखें जिनका आप वास्तव में उपयोग कर रहे हैं。 अधिकांश लोग वास्तव में केवल मॉडल, सैंडबॉक्स और स्वीकृति से संबंधित तीन या चार लाइनों को ही बदलते हैं।

💡 एक वाक्य में सारांश: settings.json (JSON) → config.toml (TOML) फ़ॉर्मेट बदलकर दोबारा लिखने जैसा है, कॉपी-पेस्ट नहीं; TOML में =, [section] का उपयोग करें, और लाइनों के अंत में कोमा न लगाएं—JSON की कोमा लगाने की आदत को छोड़ें; केवल आवश्यक सेटिंग्स को दोबारा कॉन्फ़िगर करने के लिए [18] का संदर्भ लें।

05 अनुमति मॉडल: अनुमति मोड → सैंडबॉक्स + स्वीकृति

यह माइग्रेशन के दौरान मानसिक स्तर पर सबसे बड़ा अंतर है, और यहाँ नए नियमों को समझना सबसे महत्वपूर्ण है। यदि आप Claude Code के "श्वेतसूची (whitelist) बनाने" के पुराने दृष्टिकोण को यहाँ लागू करने का प्रयास करेंगे, तो आप भ्रमित हो जाएंगे。

Claude Code के अनुमति मॉडल के केंद्र में दो बातें थीं:

अनुमति मोड (permission mode): छह स्तर, default (हर कदम पर पूछना) से लेकर bypassPermissions (पूरी तरह से छूट) तक, मोड बदलने के लिए Shift+Tab का उपयोग करना。
श्वेतसूची (whitelist) नियम: settings.json में allow / ask / deny नियम लिखना, जो विशिष्ट उपकरणों या कमांडों (जैसे rm -rf को deny करना) पर नियंत्रण प्रदान करते हैं。

Codex 不是这套。它把「能动多大」和「问不问你」拆成两个独立旋钮：

सैंडबॉक्स (sandbox): यह "यह क्या कर सकता है" को नियंत्रित करता है—read-only / workspace-write / danger-full-access जैसे तीन स्तर。
स्वीकृति (approval): यह "क्या इसे आपसे पूछना चाहिए" को नियंत्रित करता है—untrusted / on-request / never जैसे तीन स्तर。

समानता: एक ही बिजली फिटिंग का नक्शा, एक मीट्रिक सिस्टम में और दूसरा इंपीरियल में。与其像 Claude Code 那样对每个工具、每条命令都做细致的安全规定（就像每一笔报销都要审核一样），不如像 Codex 那样划定一个"预算范围"（सैंडबॉक्स），在这个范围内它可以自由运行（स्वीकृति सक्रिय नहीं होगी），केवल तभी यह काम रोकेगा और आपसे स्वीकृति मांगेगा जब इसे इस सीमा से बाहर जाने की आवश्यकता होगी。第一个工作在"项"级别，第二个工作在"圈"级别。

Claude Code में आप जो प्रभाव चाहते थे	Claude Code में कैसे सेट करें	Codex में कैसे सेट करें
केवल पढ़ने की अनुमति देना, कोड में बदलाव न करना	`default` 模式 / 只读	沙箱 `read-only`
प्रोजेक्ट के भीतर बदलाव करने देना, बाहर जाने पर पूछना	`acceptEdits` 一类	沙箱 `workspace-write` + 审批 `on-request`（日常黄金组合）
पूरी तरह से स्वचालित, बिना किसी हस्तक्षेप के	`bypassPermissions`	沙箱 `danger-full-access` + 审批 `never`（`--yolo` 更彻底：完全绕开沙箱）
किसी खतरनाक कमांड को पूरी तरह से रोकना	`permissions.deny` 写规则	rules（实验性）用 `prefix_rule()` 匹配命令前缀，`decision = "forbidden"` 即拦死
अनुमति स्तरों को बदलना	`Shift+Tab`	会话里 `/permissions` 或启动加 `-s` / `-a`

几个搬过来必须重建的认知：

पहला, "न पूछना" का अर्थ "पूर्ण अनुमति" नहीं है。 该模式越往后越松；Codex 这俩旋钮是独立的——你完全可以「只读 + 不问我」（read-only + never），意思是「随便读、但读的时候一句都别打扰」。never 是「不弹审批」，不是「放开权限」。

दूसरा, डिफ़ॉल्ट स्तर "Git की उपस्थिति" पर निर्भर करता है。 Codex प्रारंभ होते समय बुद्धिमानी से स्तर का चयन करता है: Git द्वारा प्रबंधित निर्देशिका के लिए यह workspace-write + on-request (Auto मोड) सेट करता है, और बिना Git वाली निर्देशिका के लिए यह डिफ़ॉल्ट रूप से read-only 设置。这在没有 Git 的临时目录中尤其是一道保护屏障。

तीसरा, workspace-write के तहत नेटवर्क डिफ़ॉल्ट रूप से बंद होता है, और .git केवल पढ़ने के लिए सुरक्षित होता है。这俩默认值反直觉，照搬 Claude Code 经验最容易踩。想联网得自己开 network_access 。

अनुमतियों से संबंधित पूर्ण विवरण (तीन स्तरों का संयोजन, नियमों को कैसे लिखें, और --yolo की सीमाएं)〔15 अनुमतियाँ, सैंडबॉक्स और स्वीकृति〕में हैं। माइग्रेशन के दौरान मुख्य बात "दो स्वतंत्र नॉब्स" के इस नए मानसिक मॉडल को समझना है, "श्वेतसूची" के पुराने दृष्टिकोण को यहाँ लागू न करें。

06 इंटरैक्शन की आदतें: स्लैश कमांड और सत्र प्रबंधन में अंतर

好消息回来了：进了会话之后，你的肌肉记忆大半能直接用。 斜杠命令两边重叠度极高，常用的那批几乎同名。

आप जो करना चाहते हैं	Claude Code	Codex	क्या समान नाम है
模型 बदलना	`/model`	`/model`	✅
संदर्भ को संपीड़ित करना	`/compact`	`/compact`	✅
स्क्रीन साफ करके नया सत्र शुरू करना	`/clear`	`/clear`	✅
स्थिति / कॉन्फ़िगरेशन देखना	`/status` (या `/config`)	`/status`	लगभग समान
प्रोजेक्ट मैनुअल उत्पन्न करना	`/init`	`/init`	✅ (एक `CLAUDE.md` उत्पन्न करता है, दूसरा `AGENTS.md`)
परिवर्तन diff देखना	`/diff`	`/diff`	✅
परिवर्तनों की समीक्षा करवाना	`/review`	`/review`	✅
अनुमति स्तर बदलना	`Shift+Tab` मोड स्विच	`/permissions`	❌ भिन्न प्रवेश बिंदु

मुख्य रूप से दो अंतर हैं:

पहला, अनुमति बदलने का तरीका अलग है。 Claude Code में इसके लिए Shift+Tab का उपयोग किया जाता था; Codex में आप स्लैश कमांड /permissions टाइप करके एक मेनू से स्तर चुनते हैं। कार्य समान है, लेकिन अनुभव अलग है—यह शॉर्टकट कुंजी से मेनू चयन में बदल गया है।

दूसरा, /clear और /new को Codex में अधिक स्पष्ट रूप से विभाजित किया गया है。 Codex में /clear का अर्थ है "स्क्रीन साफ करना + नया सत्र शुरू करना", और /new का अर्थ है "स्क्रीन को साफ किए बिना नया सत्र शुरू करना"。Claude Code 那边换任务清空主要就 /clear 一个。

स्विच करने के पहले सप्ताह में मेरा व्यक्तिगत अनुभव था: कमांड टाइप करने के लिए मुझे शायद ही कभी दस्तावेज़ों को देखना पड़ा—मॉडल बदलने के लिए /model, स्थिति देखने के लिए /status, और संदर्भ संपीड़ित करने के लिए /compact सीधे काम कर रहे थे। एकमात्र स्थान जहाँ मुझे थोड़ी रुकावट महसूस हुई, वह अनुमति स्तर बदलना था, जहाँ मैंने आदतवश Shift+Tab दबाया लेकिन कुछ नहीं हुआ, और फिर मुझे याद आया कि Codex में स्लैश कमांड /permissions का उपयोग किया जाता है। स्लैश कमांड की पूरी सूची〔12 स्लैश कमांड और शॉर्टकट कुंजियाँ〕में है, लेकिन आप अपनी पुरानी आदतों के साथ काम शुरू कर सकते हैं और जरूरत पड़ने पर सूची देख सकते हैं。

07 पहले से कोई धारणा न बनाएं: ये चीजें Codex में उपलब्ध नहीं हैं या भिन्न हैं

迁移最危险的不是「不会用」，是「以为和 Claude Code 一样、结果不一样」。这一节专门点出几个容易想当然的地方。

पहला, मेमोरी सिस्टम की डिफ़ॉल्ट स्थिति विपरीत है。 Claude Code में स्वचालित मेमोरी डिफ़ॉल्ट रूप से चालू रहती थी; Codex में Memories डिफ़ॉल्ट रूप से बंद होती हैं, क्षेत्र प्रतिबंध होते हैं, और पृष्ठभूमि में जनरेट होती हैं। मेरे उस दोस्त ने सोचा था कि "मैंने इसे एक बार बताया और इसने याद रख लिया"—लेकिन अगली ही बार इसने फिर से गलत पैकेज मैनेजर का उपयोग कर दिया, क्योंकि वह मान रहा था कि इसमें डिफ़ॉल्ट रूप से मेमोरी काम कर रही है। ऐसे नियम जिन्हें आप हमेशा लागू करना चाहते हैं, उन्हें दोनों उपकरणों में प्रोजेक्ट मैनुअल (AGENTS.md) में लिखा जाना चाहिए, मेमोरी के भरोसे न रहें, विवरण के लिए देखें [19]।

दूसरा, Codex में कुछ ऐसी चीजें हैं जो Claude Code में नहीं थीं。 别假设功能只是「换名」，有些是新增的：

AGENTS.override.md: किसी स्तर पर नियमों को अस्थायी रूप से बदलने के लिए उपयोग की जाने वाली ओवरराइड फ़ाइल, जो Claude Code में उपलब्ध नहीं थी (देखें [11])。
Chronicle: स्क्रीन सामग्री का उपयोग करके संदर्भ को याद रखने की क्षमता, जिसे वर्तमान में आधिकारिक तौर पर "अनुसंधान पूर्वावलोकन" के रूप में चिह्नित किया गया है, और इसे मैन्युअल रूप से सक्षम करना पड़ता है। यह Codex के लिए विशिष्ट है (देखें [19])。
Git-आधारित डिफ़ॉल्ट स्तर चयन: प्रारंभ होते समय Git की उपस्थिति के आधार पर स्वचालित रूप से सैंडबॉक्स स्तर चुनना (देखें [15])。

तीसरा, इसके विपरीत, Claude Code की कुछ चीजें Codex में अलग रूप में मौजूद हैं。 比如 Claude Code 那套 CLAUDE.local.md 本地变体，Codex 用 AGENTS.override.md 顶替但语义不同；权限白名单那套精确控命令，Codex 对应的是实验性的 rules（写法是 Starlark，不是 JSON 数组）。

आपके द्वारा मानी जाने वाली संभावित बातें	वास्तविक स्थिति
❌ Codex भी `CLAUDE.md` को पढ़ेगा	✅ यह केवल `AGENTS.md` को पढ़ता है (जब तक कि आप `project_doc_fallback_filenames` को कॉन्फ़िगर न करें)
❌ मेमोरी डिफ़ॉल्ट रूप से चालू होती है, इसे सब कुछ याद रहता	✅ Memories डिफ़ॉल्ट रूप से बंद होती हैं, पृष्ठभूमि में जनरेट होती हैं, और क्षेत्र प्रतिबंध लागू होते हैं
❌ `settings.json` को सीधे कॉपी किया जा सकता है	✅ इसे TOML फ़ॉर्मेट में `config.toml` के रूप में दोबारा लिखना होगा
❌ अनुमतियाँ उपकरण-आधारित श्वेतसूची के अनुसार होती हैं	✅ यह सैंडबॉक्स + स्वीकृति जैसे दो स्वतंत्र नॉब्स पर आधारित है
❌ `Shift+Tab` अनुमति स्तरों को बदलता है	✅ Codex में स्लैश कमांड `/permissions` टाइप करना होता है

💡 एक वाक्य में सारांश: माइग्रेशन में सबसे बड़ा जोखिम "पहले से मान लेना" है—मेमोरी डिफ़ॉल्ट रूप से बंद है, Codex में AGENTS.override.md / Chronicle जैसी विशिष्ट सुविधाएँ हैं; और अनुमतियाँ श्वेतसूची नहीं बल्कि स्वतंत्र नॉब हैं।

08 动手：把一份 `CLAUDE.md` 改写成 `AGENTS.md`

केवल देखने से याद नहीं रहेगा। नीचे हम एक विशिष्ट CLAUDE.md को AGENTS.md में बदलने की व्यावहारिक प्रक्रिया को देखेंगे, और सत्यापित करेंगे कि Codex इसे पढ़ पा रहा है या नहीं। मेरे साथ चरणों का पालन करें, इसे पाँच मिनट में पूरा किया जा सकता है。

प्लेटफ़ॉर्म अंतरों को पहले स्पष्ट करते हैं: नीचे दिए गए mkdir / git init कमांड सीधे Mac / Linux पर काम करेंगे; Windows उपयोगकर्ताओं को सलाह दी जाती है कि वे इन्हें Git Bash या WSL में चलाएं, या फ़ाइल एक्सप्लोरर के माध्यम से मैन्युअल रूप से बनाएं। पथ (path) में ~ उपयोगकर्ता की होम डायरेक्टरी को दर्शाता है, जो Windows में C:\Users\Username\ से मेल खाता है。

पहला चरण: माइग्रेशन के लिए CLAUDE.md तैयार करें。

建个玩具项目，放一份典型的 CLAUDE.md（就当是你从 Claude Code 项目里搬来的）：

bash

mkdir migrate-demo && cd migrate-demo
git init

在项目根新建 CLAUDE.md ，贴入这份（故意带一行该删的废话，演示瘦身）：

# migrate-demo 项目说明

这是一个基于 FastAPI 的订单管理后端。本项目由订单团队在 2023 年立项，
最初用 Flask，后来为了异步性能迁到 FastAPI，技术选型经过三轮评审……（一大段背景）

## 技术栈

- Python 3.11 / PostgreSQL / pytest

## 常用命令

- `pytest` —— 运行测试
- `ruff check .` —— 跑 lint

## 编程约定

- 所有函数必须有类型注解
- 字符串统一用双引号

## 禁区

- 不要改动 migrations/ 里已有的迁移文件
- 新增生产依赖前先问我

अपेक्षित परिणाम: प्रोजेक्ट रूट में CLAUDE.md फ़ाइल दिखाई देगी। ध्यान दें कि प्रोजेक्ट की पृष्ठभूमि की जानकारी—Codex को कोड लिखने के लिए इसकी आवश्यकता नहीं है, और यही वह चीज़ है जिसे माइग्रेशन के दौरान हटा दिया जाना चाहिए。

दूसरा चरण: इसे AGENTS.md के रूप में दोबारा लिखें。

新建 AGENTS.md ，把内容搬过来、顺手砍掉那段立项背景（其余几乎照搬）：

# migrate-demo — 基于 FastAPI 的订单管理后端

## 技术栈

- Python 3.11 / PostgreSQL / pytest

## 常用命令

- `pytest` —— 运行测试
- `ruff check .` —— 跑 lint

## 编程约定

- 所有函数必须有类型注解
- 字符串统一用双引号

## 禁区

- 不要改动 migrations/ 里已有的迁移文件
- 新增生产依赖前先问我

अपेक्षित परिणाम: प्रोजेक्ट रूट में AGENTS.md फ़ाइल दिखाई देगी, जो मूल CLAUDE.md की तुलना में छोटी होगी—हटाया गया कंटेंट वह है जिसे Codex कोड देखकर खुद समझ सकता है या जिसकी आवश्यकता इसे नहीं है。

तीसरा चरण: Codex से उन निर्देशों को दोहराने के लिए कहें जो इसने पढ़े हैं, ताकि माइग्रेशन की सफलता की पुष्टि की जा सके。

在项目目录里跑（这里只读总结，加 --ask-for-approval never 是为免去审批打扰、让输出干净——这正是官方文档用来验证 AGENTS.md 是否被读到的标准做法，放心用）：

bash

codex --ask-for-approval never "Summarize the current instructions."

अपेक्षित परिणाम: Codex आपके द्वारा लिखे गए नियमों को संक्षेप में प्रस्तुत करेगा—जैसे तकनीक, pytest / ruff कमांड, टाइप एनोटेशन, डबल कोट्स, migrations को न छूना, और बिना पूछे डिपेंडेंसी न जोड़ना। एक बार जब यह इन्हें दोहरा देता है, तो इसका अर्थ है कि यह AGENTS.md को संदर्भ में लोड करने में सफल रहा है, और माइग्रेशन सफल हो गया है。

चौथा चरण (वैकल्पिक): पुरानी CLAUDE.md फ़ाइल को हटा दें。

迁完确认无误，旧的 CLAUDE.md 留着也不影响（Codex 不读它），但容易让队友混淆。要不要删由你决定——这属于会改动文件的操作，自己手动处理，别让工具替你删。如果想让 Codex 顺带也认 CLAUDE.md 这个名（过渡期两边并存），可以在 ~/.codex/config.toml 里加：

toml

# ~/.codex/config.toml
project_doc_fallback_filenames = ["CLAUDE.md"]

加了这条，Codex 在每个目录的挑选顺序变成 AGENTS.override.md → AGENTS.md → CLAUDE.md ，取第一个存在且非空的——过渡期想让老 CLAUDE.md 也被读到，这是最省事的办法（改完重启 Codex 生效）。

💡 एक वाक्य में सारांश: माइग्रेशन = CLAUDE.md के कंटेंट को AGENTS.md में स्थानांतरित करना + पृष्ठभूमि को हटाना, और "Summarize the current instructions" के साथ सत्यापित करना; यदि संक्रमण काल के दौरान आप CLAUDE.md को भी पढ़वाना चाहते हैं, तो project_doc_fallback_filenames को कॉन्फ़िगर करें।

सारांश

इस अध्याय में "Claude Code से Codex पर माइग्रेशन" की वैचारिक और व्यावहारिक प्रक्रिया को विस्तार से समझाया गया है:

आयाम	मुख्य निष्कर्ष
समग्र निर्णय	90% मानसिक मॉडल सीधे लागू होता है, केवल यह सीखना है कि चीजें कहाँ हैं और उन्हें क्या कहा जाता है
प्रोजेक्ट मैनुअल	`CLAUDE.md` → `AGENTS.md` (कंटेंट कॉपी किया जा सकता है), लेकिन अस्थायी ओवरराइड तंत्र और आकार सीमा (लाइनें → बाइट्स) भिन्न हैं
कॉन्फ़िगरेशन फ़ाइल	`settings.json` (JSON) → `config.toml` (TOML) फ़ॉर्मेट बदलकर दोबारा लिखना, JSON की कोमा की आदत को छोड़ें
अनुमति मॉडल	अनुमति मोड + श्वेतसूची → सैंडबॉक्स + स्वीकृति दो स्वतंत्र नॉब्स, "न पूछना ≠ पूर्ण अनुमति"
इंटरैक्शन की आदतें	स्लैश कमांड के नाम लगभग समान हैं, सबसे बड़ा अंतर अनुमति बदलना है (`Shift+Tab` → `/permissions`)
धारणा न बनाएं	मेमोरी डिफ़ॉल्ट रूप से बंद है, Codex में `AGENTS.override.md` / Chronicle जैसी विशिष्ट सुविधाएँ हैं

अब आप यह करने में सक्षम होने चाहिए: एक CLAUDE.md फ़ाइल को साफ-सुथरे ढंग से AGENTS.md में माइग्रेट करना; यह जानना कि settings.json को config.toml की किन लाइनों में लिखना है; "अनुमति मोड + श्वेतसूची" के पुराने ढांचे के स्थान पर "सैंडबॉक्स + स्वीकृति" का उपयोग करना; और "सोचा था कि बिल्कुल वैसा ही होगा लेकिन निकला अलग" वाली गलतियों से बचना। संक्षेप में कहें तो—Claude Code का आपका अनुभव व्यर्थ नहीं गया है, टूल बदलने के बाद भी आप आसानी से काम जारी रख सकते हैं।

अगले अध्याय〔33 Windows उपयोग के मुख्य बिंदु〕में—मैंने पिछले कुछ व्यावहारिक अभ्यासों में Windows उपयोगकर्ताओं को "Git Bash या WSL में कमांड चलाने" के लिए क्यों कहा था? Windows पर Codex चलाते समय सैंडबॉक्स, पथ (paths) और टर्मिनल जैसी जगहों पर कौन सी विशिष्ट समस्याएँ आती हैं? एक छोटा सा विचार करें: इस अध्याय में चर्चा की गई सैंडबॉक्स प्रणाली, एक ऐसे ऑपरेटिंग系统 पर जिसमें Linux जैसी अलगाव (isolation) क्षमताएं डिफ़ॉल्ट रूप से नहीं हैं, कैसे सुरक्षा सुनिश्चित करती है? अगले अध्याय में हम Windows से संबंधित सभी पहलुओं को विस्तार से समझेंगे।

Claude Code से माइग्रेशन: पुराना नक्शा, नया टूल, घर का रास्ता फिर भी मिल जाएगा ​

01 पहले मन की शांति: आपका 90% मानसिक मॉडल सीधे काम करेगा ​

02 एक व्यापक तुलना तालिका: पुराना नाम → नया नाम ​

03 项目说明书：CLAUDE.md → AGENTS.md ​

04 कॉन्फ़िगरेशन फ़ाइल: settings.json (JSON) → config.toml (TOML) ​

05 अनुमति मॉडल: अनुमति मोड → सैंडबॉक्स + स्वीकृति ​

06 इंटरैक्शन की आदतें: स्लैश कमांड और सत्र प्रबंधन में अंतर ​

07 पहले से कोई धारणा न बनाएं: ये चीजें Codex में उपलब्ध नहीं हैं या भिन्न हैं ​

08 动手：把一份 CLAUDE.md 改写成 AGENTS.md ​

सारांश ​

अनुशंसित पठन ​