कोडिंग एजेंट्स की मेमोरी: Claude Code, Codex और Cursor

Claude Code, Codex और Cursor जैसे कोडिंग एजेंट्स के लिए साझा मेमोरी की शुरुआत वर्ज़न कंट्रोल में रखे AGENTS.md और काम की स्थिति बताने वाले छोटे हैंडऑफ़ नोट से करें। संदर्भ अपने आप दर्ज करने और काम अगले एजेंट को सौंपने के लिए ai-memory जोड़ें; सेशन के रिकॉर्ड देखकर दोबारा काम आने वाले निष्कर्ष मंज़ूर करने हों, तो Beacon चुनें। किसी भी विकल्प में प्रोजेक्ट के अनिवार्य नियम रिपॉज़िटरी में ही रखें।

टूल बदलते समय कौन-सी जानकारी बचानी है

लंबे समय तक लागू रहने वाले फ़ैसलों को मौजूदा काम की स्थिति से अलग रखें। नया एजेंट आपका कोड पढ़ सकता है, लेकिन उसे यह पता न हो कि आपने कोई तरीका क्यों छोड़ा, कल कौन-सा सुधार बताया था या अधूरे काम में अगला कदम क्या है।

तीन तरह के संदर्भ अलग समस्याएँ हल करते हैं: निर्देश बताते हैं कि काम कैसे करना है, हैंडऑफ़ नोट बताते हैं कि काम कहाँ रुका था, और सेशन का इतिहास दोनों का आधार जाँचने में मदद करता है। इनमें से एक को साझा करने से बाकी संदर्भ, चल रही प्रक्रियाएँ या टूल की अनुमतियाँ अपने आप ट्रांसफ़र नहीं होतीं।

तरीका	क्या सुरक्षित रहता है	कब चुनें	कब विकल्प बदलें
रिपॉज़िटरी में निर्देश और हैंडऑफ़ फ़ाइलें	नियमित रूप से सँभाले गए नियम, फ़ैसले और काम की स्थिति	कुछ नोट आपकी ज़रूरत पूरी करते हों और उन्हें Git के साथ रखना हो	अगर लोग बार-बार नोट अपडेट करना भूलते हैं, तो किसी सेवा पर जाएँ
ai-memory	दर्ज की गई जानकारी, खोजी जा सकने वाली Markdown विकी और एजेंट्स के बीच हैंडऑफ़	आप अक्सर एजेंट बदलते हों और संदर्भ दर्ज करना व ढूँढना अपने आप कराना चाहते हों	अगर हुक, क्रेडेंशियल और सर्वर सँभालने की मेहनत लाभ से अधिक हो, तो फ़ाइलों पर बने रहें
Beacon	एक समान प्रारूप में सेशन रिकॉर्ड और स्पष्ट रूप से मंज़ूर किए गए प्रोजेक्ट निष्कर्ष	आपको घटनाएँ जाँचकर बार-बार दिए गए सुधारों से भरोसेमंद नियम बनाने हों	अगर अपने आप काम सौंपना रिकॉर्ड और निष्कर्षों की समीक्षा से अधिक ज़रूरी हो, तो ai-memory चुनें

2026-10-21 की स्थिति के अनुसार, यह तुलना ai-memory v3.1.2 और Beacon v1.3.45 पर आधारित है। फ़र्क इनके ढाँचे में है: ai-memory में Git-आधारित Markdown विकी के साथ सर्वर, हुक और MCP भी हैं; Beacon में डेटा कैप्चर और मेमोरी की मंज़ूरी अलग प्रक्रियाएँ हैं।

AGENTS.md और छोटे हैंडऑफ़ नोट से शुरू करें

AGENTS.md को प्रोजेक्ट का साझा संदर्भ बनाएँ और जाँचें कि हर टूल उसे लोड करता है। टूल के अपने लोडिंग नियम अलग हैं:

• Codex: प्रोजेक्ट की रूट डायरेक्टरी से वर्किंग डायरेक्टरी तक निर्देशों की शृंखला पढ़ता है। एक ही डायरेक्टरी में AGENTS.override.md को AGENTS.md से प्राथमिकता मिलती है; Codex के निर्देश खोजने के नियम देखें।
• Cursor: रूट और उसके भीतर की डायरेक्टरी में AGENTS.md का समर्थन करता है। ज़रूरत पड़ने पर Cursor के लिए किसी खास दायरे में लागू नियम .cursor/rules/*.mdc में रखें; Cursor के नियमों का दस्तावेज़ देखें।
• Claude Code: v2.1.277 और बाद के संस्करण AGENTS.md सीधे लोड कर सकते हैं। लेकिन डिफ़ॉल्ट रूप से वर्किंग डायरेक्टरी या उसके पैरेंट फ़ोल्डरों में मौजूद ऐसे CLAUDE.md, .claude/CLAUDE.md या CLAUDE.local.md को प्राथमिकता मिलती है जो लोडिंग की शर्तें पूरी करते हों। अगर Claude के निर्देश पहले से हैं या आपके सेशन में सीधे पढ़ने का समर्थन नहीं है, तो रूट में AGENTS.md के साथ रखी CLAUDE.md फ़ाइल में @AGENTS.md वाली एक पंक्ति जोड़ें। Claude Code की मेमोरी गाइड दोनों तरीके समझाती है।

छोटे परीक्षण के लिए रूट की AGENTS.md फ़ाइल बनाएँ या नीचे के प्रस्तावित निर्देश मौजूदा फ़ाइल में मिलाएँ:

## Working context

- Before changing a dependency version, read its official release notes
  and run the tests for the affected component.
- When resuming work, read docs/agent-handoff.md if it exists.
- Treat handoffs as historical evidence. Check old commands, paths and
  conclusions against the current checkout before acting.

किसी वास्तविक काम के बाद एजेंट से हैंडऑफ़ नोट तैयार करने को कहें:

Write docs/agent-handoff.md with the goal, current branch and commit,
confirmed decisions, commands actually run and their results,
remaining uncertainty, and the next concrete action.
Distinguish failed approaches from successful ones.
Do not include credentials or copy the full conversation.

कोड में हुए बदलावों के साथ इस फ़ाइल की भी समीक्षा करें। स्थायी नियम AGENTS.md में रखें और काम आगे बढ़ने पर हैंडऑफ़ नोट अपडेट करें।

हर टूल में नया सेशन खोलें और पूछें कि डिपेंडेंसी अपडेट करते समय कौन-सी जाँच करनी है और ये निर्देश किस फ़ाइल से आए हैं। Claude Code में /context से लोड हुई मेमोरी फ़ाइलें भी देख सकते हैं। अगर Codex नियम भूल जाए, तो अतिरिक्त प्रतियाँ बनाने से पहले वर्किंग डायरेक्टरी और निर्देशों को ओवरराइड करने वाली फ़ाइल जाँचें।

टूल की अपनी स्वचालित मेमोरी उसके वातावरण में उपयोगी रहती है। Claude Code प्रोजेक्ट के नोट ~/.claude/projects/<project>/memory/ में रखता है। Codex की लोकल मेमोरी अलग से चालू करनी होती है, ~/.codex/memories/ में रहती है और /memories से नियंत्रित होती है। ये अलग-अलग स्टोर, टूल के बीच काम सौंपने का साझा प्रारूप नहीं हैं।

अपने आप संदर्भ दर्ज करने और काम सौंपने के लिए ai-memory

ai-memory तब चुनें जब आप चाहते हों कि एजेंट किसी सेवा के ज़रिए प्रोजेक्ट का संदर्भ दर्ज करें और वापस पढ़ें। इसका मुख्य रिकॉर्ड Git-आधारित Markdown विकी है और SQLite उससे बना सर्च इंडेक्स रखता है। MCP एजेंट को मेमोरी टूल देता है, जबकि हुक — सेशन के इवेंट पर चलने वाले हैंडलर — डेटा कैप्चर और सेशन की शुरुआत व समाप्ति पर होने वाली कार्रवाइयाँ सँभालते हैं।

एजेंट इंस्टॉल और कनेक्ट करें

नीचे का उदाहरण macOS पर Bash से यूज़र के लिए नई इंस्टॉलेशन के लिए है। Git और आपके कोडिंग एजेंट पहले से इंस्टॉल हों तथा एजेंट्स का ऑथेंटिकेशन पूरा हो। अन्य प्लेटफ़ॉर्म के लिए इस रिलीज़ की इंस्टॉलेशन गाइड देखें।

curl -fsSLo /tmp/ai-memory-install-v3.1.2.sh \
  https://github.com/akitaonrails/ai-memory/releases/download/v3.1.2/install.sh
less /tmp/ai-memory-install-v3.1.2.sh
AI_MEMORY_VERSION=3.1.2 sh /tmp/ai-memory-install-v3.1.2.sh
export PATH="$HOME/.local/bin:$PATH"
ai-memory --version
ai-memory setup --plan --agent claude-code --agent codex --agent cursor
ai-memory setup --agent claude-code --agent codex --agent cursor
ai-memory status

अपेक्षित संस्करण 3.1.2 है। सेटअप स्वीकार करने से पहले उसका प्लान देखें: यह बैकग्राउंड सेवा बनाता है और यूज़र के दायरे में MCP, हुक और स्किल की कॉन्फ़िगरेशन बदलता है। इसलिए चुने हुए एजेंट्स के दूसरे प्रोजेक्ट भी कैप्चर हो सकते हैं।

इस रिलीज़ का Codex कॉन्फ़िगरेशन लिखने वाला कोड ai-memory के टूल के लिए default_tools_approval_mode = "approve" भी सेट करता है। अगर आप मेमोरी में बदलाव के लिए पुष्टि ज़रूरी रखना चाहते हैं, तो इस अनुमति की समीक्षा करें।

इस रिलीज़ में Codex के नेटिव पंजीकरण के लिए बना हुआ bearer टोकन उस एनवायरनमेंट में लोड करें जिससे Codex चलाएँगे। macOS की डिफ़ॉल्ट डेटा डायरेक्टरी के लिए ये Bash कमांड टोकन को प्रिंट किए बिना ऐसा करते हैं:

AI_MEMORY_AUTH_TOKEN="$(cat "$HOME/Library/Application Support/ai-memory/auth-tokens/default")"
export AI_MEMORY_AUTH_TOKEN
codex

पंजीकरण AI_MEMORY_AUTH_TOKEN का संदर्भ देता है; MCP इंस्टॉलेशन गाइड Codex की यह खास आवश्यकता बताती है। आपकी डेटा डायरेक्टरी अलग हो तो ai-memory status में दिखाया गया वास्तविक पाथ इस्तेमाल करें।

Codex के भीतर /hooks चलाएँ और इंस्टॉल हुए ai-memory हुक को विश्वसनीय चिह्नित करें। सेटअप के बाद Claude Code और Cursor दोबारा शुरू करें। केवल इंस्टॉलर के एग्ज़िट कोड से यह साबित नहीं होता कि Codex ऐसे हुक चलाएगा जिन्हें अभी विश्वसनीय नहीं माना गया है।

सहेजी गई जानकारी और हैंडऑफ़ अलग-अलग जाँचें

पहली जाँच में रिपॉज़िटरी की एक ही वर्किंग कॉपी इस्तेमाल करें और प्रोजेक्ट का दायरा स्पष्ट रखें। उसके रूट से ai-memory project init चलाएँ और वर्कस्पेस व प्रोजेक्ट के नाम स्वीकार करें या चुनें। यह .ai-memory.toml लिखता है; सभी एजेंट्स में दोनों नाम एक जैसे रखें।

Claude Code में यह प्रॉम्प्ट दें:

Read .ai-memory.toml and use its workspace and project for ai-memory calls.
Call memory_status.
Use memory_write_page to save decisions/shared-memory-demo.md with:
"Memory trial: before a dependency upgrade, check the official release
notes and run the affected component's tests."
Read the page back with memory_read_page and report its stored path.

उसी वर्किंग कॉपी में Codex या Cursor खोलें। उससे Memory trial के लिए memory_query और फिर मिले हुए परिणाम पर memory_read_page चलाने को कहें। सफलता का मतलब है कि टूल का वास्तविक परिणाम सहेजा गया पाथ और फ़ैसला लौटाए; मेमोरी पढ़े बिना विश्वसनीय लगने वाला उत्तर काफ़ी नहीं है। ये ऑपरेशन मेमोरी के प्रोग्रामेटिक इस्तेमाल के संदर्भ दस्तावेज़ में दिए गए हैं।

इसके बाद किसी छोटे वास्तविक काम से स्वचालित हैंडऑफ़ जाँचें: एक स्पष्ट कार्रवाई अधूरी छोड़ें, सेशन सामान्य रूप से बंद करें और उसी डायरेक्टरी में अगला एजेंट खोलें। उसके शुरुआती संदर्भ में लंबित कार्रवाई दिखाई देनी चाहिए। स्थायी पेज आगे भी खोजा जा सकता है; हैंडऑफ़ अगले सेशन के लिए होता है और उसे केवल एक बार लिया जा सकता है।

जानकारी वापस न मिले तो ai-memory doctor चलाएँ, MCP कनेक्शन की स्थिति देखें और वर्कस्पेस व प्रोजेक्ट की जोड़ी जाँचें। Codex में ऑथेंटिकेशन की विफलता हो तो उसके लॉन्च एनवायरनमेंट को जाँचें; हैंडऑफ़ न मिले तो देखें कि हुक विश्वसनीय चिह्नित हैं और सेशन कैप्चर हो रहा है। इन्हें एक ही तरह की विफलता न मानें।

सेशन रिकॉर्ड और मंज़ूर किए गए निष्कर्षों के लिए Beacon

Beacon तब चुनें जब दोबारा इस्तेमाल होने वाले निष्कर्ष के पीछे का आधार जाँचना हो। यह OpenTelemetry, हुक और लोकल सेशन फ़ाइलों से डेटा वापस लेने जैसे तरीके जोड़ता है; कौन-से इवेंट मिलेंगे, यह टूल पर निर्भर करता है। किसी सेशन को कैप्चर करने से उसकी सामग्री अपने आप मंज़ूर की गई मेमोरी नहीं बनती।

लोकल कलेक्टर इंस्टॉल करें

macOS पर Bash और Homebrew से नई इंस्टॉलेशन के लिए केवल यहाँ इस्तेमाल किए गए तीन एजेंट कॉन्फ़िगर करें:

brew update
brew trust asymptote-labs/tap
brew tap asymptote-labs/tap
brew install beacon
beacon version
BEACON_ONBOARDING=0 beacon endpoint install \
  --harness claude,codex,cursor --no-backfill
beacon endpoint status

सत्यापन की तारीख़ पर Homebrew फ़ॉर्मूला 1.3.45 उपलब्ध कराता है। यह उदाहरण पुराने सेशन का डेटा आयात करने और इंटरैक्टिव शुरुआती सेटअप विज़ार्ड चलाने के चरण छोड़ देता है। चुने हुए एजेंट्स के लिए कैप्चर यूज़र के दायरे में स्थापित होता है, इसलिए दूसरे रिपॉज़िटरी में उनका काम भी लॉग में आ सकता है।

सामान्य विज़ार्ड में Beacon Cloud पहले से चुना होता है। नई इंस्टॉलेशन में विज़ार्ड छोड़ने और --connect न देने पर Cloud में पंजीकरण नहीं होता। इससे पहले से जुड़ी इंस्टॉलेशन डिस्कनेक्ट नहीं होती; उसके लिए beacon endpoint disconnect इस्तेमाल करें। डेटा कहाँ रखा या भेजा जाएगा, इसके विकल्प शुरुआती सेटअप के दस्तावेज़ में दिए गए हैं।

कॉन्फ़िगरेशन के बाद एजेंट दोबारा शुरू करें और Codex के /hooks में Beacon के हुक की समीक्षा करके उन्हें विश्वसनीय चिह्नित करें। परीक्षण वाली रिपॉज़िटरी में छोटा सेशन चलाएँ और ऊपर दिया गया डिपेंडेंसी की समीक्षा का नियम स्पष्ट रूप से बताएँ।

एक निष्कर्ष बनाएँ, मंज़ूर करें और वापस पढ़ें

मेमोरी के लिए निष्कर्ष बनाने से पहले दर्ज किया गया सेशन देखें। रिपॉज़िटरी के रूट से चलाएँ:

beacon endpoint traces list --limit 10
read -r -p "Trace ID from the trial session: " BEACON_TRACE_ID
beacon endpoint traces show "$BEACON_TRACE_ID" --limit 150

सूची में मिला वास्तविक ID चुनें और पुष्टि करें कि उसके इवेंट में बताया गया नियम मौजूद है। फिर मंज़ूरी के लिए एक प्रस्तावित रिकॉर्ड बनाएँ:

beacon memory candidates create \
  --trace "$BEACON_TRACE_ID" \
  --kind convention \
  --title "Dependency upgrades require release-note review" \
  --applicability "Before changing a dependency version in this repository" \
  --body "Check the dependency's official release notes and run the affected component's tests before proposing the upgrade."
read -r -p "Candidate ID returned above: " BEACON_CANDIDATE_ID
beacon memory candidates show "$BEACON_CANDIDATE_ID"

प्रस्तावित रिकॉर्ड और उसके स्रोत की जाँच करें। उसमें लिखे निष्कर्ष से सहमत होने के बाद ही उसे मंज़ूर करें:

beacon memory candidates approve "$BEACON_CANDIDATE_ID" \
  --reason "Reviewed against the source trace"

इस तरीके में प्रस्तावित रिकॉर्ड का टेक्स्ट आप देते हैं और किसी मूल्यांकनकर्ता को कॉल नहीं किया जाता। Beacon का वैकल्पिक मूल्यांकनकर्ता सेशन रिकॉर्ड को स्कोर देता है; वह निष्कर्ष का पूरा टेक्स्ट नहीं लिखता। दोनों तरीके मेमोरी कमांड के संदर्भ दस्तावेज़ में समझाए गए हैं।

अब उसी रिपॉज़िटरी में काम कर रहे दूसरे एजेंट से यह चलाने को कहें:

beacon memory list -q "dependency upgrades" --json

उससे मिला हुआ मेमोरी ID beacon memory show को देने और यह समझाने को कहें कि नियम कब लागू होता है। अपेक्षित परिणाम इस प्रोजेक्ट से जुड़ा मंज़ूर किया गया निष्कर्ष है। परिणाम खाली हो तो मंज़ूरी की स्थिति, प्रोजेक्ट का दायरा और खोज के शब्द जाँचें; Beacon की लोकल खोज में हर खोज-शब्द का मिलना ज़रूरी है।

CLI वाले इस तरीके में MCP आवश्यक नहीं है। एजेंट के टूल से जानकारी वापस पढ़ने के लिए Beacon का अलग लोकल MCP सर्वर search_memory, get_memory और get_memory_context देता है। यह मंज़ूर की गई लोकल मेमोरी पढ़ता है। Beacon Cloud का स्टोर अलग है; डिवाइस कनेक्ट करने से दोनों मेमोरी स्टोर सिंक नहीं होते।

गलत निष्कर्षों, निजी डेटा और लागत को नियंत्रण में रखें

स्पष्ट दायरे वाले निष्कर्ष उनके आधार के साथ सहेजें और वापस मिले टेक्स्ट को पिछली घटनाओं की जानकारी मानें। कोई तरीका असफल होने का कारण अस्थायी सेवा बाधा या गलत ब्रांच हो सकती है, न कि प्रोजेक्ट का स्थायी नियम। लागू परिस्थिति, मूल काम या कमिट, जाँच का परिणाम और समीक्षा की तारीख़ लिखें; संबंधित व्यवहार बदलने पर नोट सुधारें या हटाएँ।

मंज़ूरी एक प्रक्रिया है, इस बात का प्रमाण नहीं कि किसी इंसान ने सामग्री जाँची है। Beacon में रिकॉर्ड सुझाने वाला एजेंट और उसे जाँचने वाला व्यक्ति अलग रखें। सहेजे गए निर्देशों को मौजूदा आवश्यकताओं या अनुमतियों पर हावी न होने दें।

कैप्चर से यह भी बदलता है कि निजी जानकारी कहाँ बनी रहती है। .ai-memory.toml में ai-memory के [capture] ignore_paths नियम समर्थित पाथ-आधारित इवेंट बाहर रख सकते हैं, लेकिन इसके उपयोग के दस्तावेज़ स्पष्ट करते हैं कि यह प्रॉम्प्ट और आउटपुट में डेटा लीक रोकने वाला सामान्य फ़िल्टर नहीं है। दोबारा इस्तेमाल होने वाले नोट में क्रेडेंशियल या ग्राहक डेटा न रखें; मौजूदा Markdown पेज हटाने के बाद भी Git में उसके पुराने संस्करण रह सकते हैं।

काम के सेशन Beacon Cloud को भेजने से पहले मौजूदा गोपनीयता नीति देखें। 2026-10-21 की स्थिति के अनुसार, रिसर्च और मॉडल ट्रेनिंग के लिए उपयोग डिफ़ॉल्ट रूप से चालू है, हालाँकि आप इसे बंद कर सकते हैं; केवल मेटाडेटा भेजने में भी पाथ और कमांड लाइन जैसी जानकारी शामिल रहती है। लोकल स्टोरेज से क्लाउड कोडिंग मॉडल लोकल नहीं बन जाता: उसके संदर्भ में लाई गई मेमोरी उस मॉडल का इनपुट बनती है।

पूरे काम की लागत का हिसाब रखें। ai-memory के डिफ़ॉल्ट मेमोरी तरीके में जनरेटिव मॉडल की API कुंजी आवश्यक नहीं है, हालाँकि उसका डिफ़ॉल्ट लोकल एम्बेडिंग मॉडल पहली बार शुरू होने पर डाउनलोड हो सकता है। Beacon में निष्कर्ष का टेक्स्ट खुद देने वाला तरीका मूल्यांकनकर्ता की कॉल से बचता है।

कोडिंग एजेंट का सामान्य उपयोग, मेमोरी से आया अतिरिक्त इनपुट, वैकल्पिक क्लाउड प्रोसेसिंग, स्टोरेज और समीक्षा में लगने वाला समय फिर भी लागत का हिस्सा हैं। किसी भी समाधान का ढाँचा अपने आप कम कुल लागत साबित नहीं करता।

सभी प्रोजेक्ट में मेमोरी लेयर अपनाने से पहले एक बार वास्तविक काम में टूल बदलकर देखें: सही फ़ैसला वापस पढ़ें, अधूरी कार्रवाई पहचानें, उसका आधार जाँचें और मौजूदा वर्किंग कॉपी के अनुसार काम आगे बढ़ाएँ। यह न हो पाए तो और मेमोरी जमा करने से पहले लोडिंग, प्रोजेक्ट का दायरा या कैप्चर ठीक करें।