सबडायरेक्टरी की CLAUDE.md और AGENTS.md कब पढ़ी जाती हैं? मोनोरेपो में AI से नियम कैसे मनवाएँ

एक ही रिपॉज़िटरी में कई साइटें रखें और हर साइट के फ़ोल्डर में AI के नियम (CLAUDE.md या AGENTS.md) डाल दें, तो AI उस साइट के नियम मानेगा—यह मान लेना स्वाभाविक है, लेकिन Claude Code और Codex दोनों में से कोई भी निचले फ़ोल्डरों के नियम "हमेशा पढ़ता" नहीं है। रिपॉज़िटरी की रूट से शुरू करने पर Claude Code उन्हें तब तक नहीं पढ़ता जब तक वह उस फ़ोल्डर की फ़ाइलों को छूता नहीं, और Codex उन्हें अपने-आप नहीं पढ़ता (AI ख़ुद उन्हें खोल सकता है, पर इसकी कोई गारंटी नहीं)। यह लेख दोनों टूल के आधिकारिक दस्तावेज़ों के आधार पर एक-एक बिंदु मिलाकर बताता है कि ये फ़ाइलें कब पढ़ी जाती हैं और कैसे जाँचें कि वे पढ़ी गईं, फिर दिखाता है कि नियमों को दस्तावेज़ों के बजाय स्वचालित जाँच से कैसे लागू करवाएँ। यह उस अनुभव से निकला है जो हमें ऐसे माहौल में यह व्यवस्था डिज़ाइन करते हुए मिला, जहाँ AI एजेंट सर्वर का संचालन और कई प्रोजेक्ट सँभालते हैं।

स्रोत: Anthropic का How Claude remembers your project और OpenAI का Custom instructions with AGENTS.md (दोनों 1 नवंबर 2026 को जाँचे गए)।

1. हर साइट के फ़ोल्डर में नियम रखने से हमने क्या सीखा

ऐसे माहौल में जहाँ AI एजेंट सर्वर का संचालन और कई साइटें सँभालते हैं, हमने एक डिज़ाइन पर विचार किया: कई साइटें एक रिपॉज़िटरी में रखें और हर साइट के नियम उसी साइट के फ़ोल्डर में रखें (जगह या नाम पहचानने लायक़ ब्योरे छोड़ दिए गए हैं, और तकनीकी बातों को सामान्य रूप में लिखा गया है)। लक्ष्य था काम का बँटवारा: blog का ज़िम्मेदार AI केवल blog के नियम पढ़े और shop को कभी न छुए।

लेकिन दोनों टूल के आधिकारिक दस्तावेज़ देखने पर पता चला कि रखे गए नियमों के काम शुरू होने से पहले पढ़े जाने की कोई गारंटी नहीं थी। कौन-से नियम पढ़े जाएँगे, यह इस पर निर्भर करता है कि आप किस फ़ोल्डर से शुरू करते हैं। इसके अलावा, Claude Code के दस्तावेज़ CLAUDE.md को लागू करवाई जाने वाली सेटिंग नहीं, बल्कि संदर्भ (context) बताते हैं। नियम पढ़ लिए जाएँ, तब भी उनके पालन की कोई गारंटी नहीं।

1. !

   फ़ोल्डरों में नियम रखना ज़िम्मेदारियाँ बाँटने के लिए काफ़ी नहीं

   जोखिम

   रूट से शुरू हुआ AI उस साइट के नियम पढ़े बिना, या पढ़ने से पहले ही, फ़ाइलें बदल देता है

   उपाय

   साइट का काम साइट के फ़ोल्डर से शुरू करें, और दायरे से बाहर के बदलाव रिलीज़ से पहले की जाँच से रोकें (खंड 4)

   जाँच

   टूल से पक्का करें कि कौन-से नियम पढ़े गए (खंड 3), और जान-बूझकर दायरे के बाहर कुछ बदलकर देखें कि रिलीज़ रुकती है या नहीं

AI के नियमों को नज़रअंदाज़ करने के सामान्य कारण और उनके उपाय "AI आपके .md नियम क्यों नज़रअंदाज़ करता है — लोडिंग की जाँच, Hooks और CI से सुधार" में हैं। यह लेख इस पर केंद्रित है कि जब आप नियमों को फ़ोल्डरों में बाँटते हैं तब क्या होता है। उसी माहौल से, AI को कई रिपॉज़िटरी सौंपने से जुड़ी दो और सावधानियाँ खंड 5 में हैं।

2. फ़ोल्डर-वार नियम कब पढ़े जाते हैं?

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

स्रोत: Anthropic का How Claude remembers your project और Monorepos and large repos, तथा OpenAI का Custom instructions with AGENTS.md (1 नवंबर 2026 को जाँचे गए)। Claude Code में निचले फ़ोल्डरों की यह सीमा v2.1.309 से लागू है। 1M-टोकन संदर्भ के साथ यह 150,000 अक्षर है (Opus 4.6 और Sonnet 4.6 के लिए 200,000)। Claude Code v2.1.277 से AGENTS.md को सीधे पढ़ता है; किसी निचले फ़ोल्डर की AGENTS.md तब पढ़ी जाती है जब उस फ़ोल्डर में CLAUDE.md न हो और Claude वहाँ की कोई फ़ाइल Read टूल से खोले। दोनों पढ़वाने के लिए /config में Project instructions को claude-md-and-agents-md पर सेट करें।

कहाँ से शुरू करते हैं, इससे पढ़े जाने वाले नियम बदलते हैं

एक ही रिपॉज़िटरी में भी नतीजा इस पर निर्भर करता है कि आप कहाँ से शुरू करते हैं। साइट के फ़ोल्डर से शुरू करें, तो दोनों टूल शुरू से ही उस साइट के नियम पढ़ते हैं।

जो बात आसानी से छूट जाती है वह है "छूने पर पढ़ा जाता है" में "छूना" किसे माना जाता है। Claude Code के दस्तावेज़ जिसे पढ़ना मानते हैं, वह है टूल से किसी फ़ाइल को पढ़ना, लिखना या संपादित करना, और साथ में cat या head जैसे एक फ़ाइल दिखाने वाले कमांड। फ़ाइलें दूसरे तरीक़ों से बदलने वाले काम, जैसे कई साइटों के फ़ोल्डरों में एक साथ खोजकर-बदलना, इस सूची में नहीं हैं। किसी साइट के नियम पढ़े जाने से पहले ही उसकी फ़ाइलें बदल सकती हैं।

Codex में, अगर आप रिपॉज़िटरी की रूट से शुरू करके "blog और shop दोनों ठीक करो" कहें, तो किसी भी साइट की AGENTS.md अपने-आप नहीं पढ़ी जाती। दस्तावेज़ कहते हैं कि Codex मौजूदा वर्किंग डायरेक्टरी तक पहुँचकर खोज रोक देता है, इसलिए किसी निचले फ़ोल्डर के नियम शुरुआत में पक्के तौर पर तभी शामिल होते हैं जब आप उसी फ़ोल्डर या उसके नीचे से शुरू करें।

हालाँकि, Codex रिपॉज़िटरी के डिफ़ॉल्ट निर्देश (base_instructions/default.md) मॉडल से कहते हैं कि मौजूदा वर्किंग डायरेक्टरी के नीचे या बाहर काम करते समय लागू होने वाली AGENTS.md फ़ाइलें देख ले। AI किसी साइट की AGENTS.md ख़ुद खोल सकता है, पर यह AI का अपना फ़ैसला है, पढ़ने की व्यवस्था की गारंटी नहीं।

फ़ोल्डर-वार सेटिंग फ़ाइलें भी अलग ढंग से विरासत में मिलती हैं

नियम-दस्तावेज़ों के अलावा, अनुमतियों जैसी सेटिंग फ़ाइलों के फ़ोल्डरों को सँभालने में भी दोनों टूल अलग हैं।

स्रोत: Anthropic का Claude Code settings और Monorepos and large repos, तथा OpenAI का Config basics (1 नवंबर 2026 को जाँचे गए)।

3. नियम पढ़े गए या नहीं, कैसे जाँचें

नियम रख देने के बाद, शुरू करके जाँचें कि वे सच में पढ़े गए या नहीं। तरीक़ा टूल के हिसाब से अलग है, और Claude Code में शुरुआत में पढ़े गए नियम और बाद में पढ़े गए नियम अलग-अलग जगह दिखते हैं।

स्रोत: Anthropic के How Claude remembers your project का समस्या-निवारण वाला हिस्सा और OpenAI के Custom instructions with AGENTS.md का "Verify your setup" (1 नवंबर 2026 को जाँचे गए)। लॉग फ़ोल्डर को .gitignore में जोड़ें ताकि वह git में न जाए।

Claude Code में नई जोड़ी गई निचले फ़ोल्डर की नियम-फ़ाइल परखने के लिए दस्तावेज़ की सलाह मानें: नियम-फ़ाइल AI से लिखवाने के बजाय शेल में बनाएँ, फिर AI से उस फ़ोल्डर की कोई फ़ाइल पढ़वाएँ और देखें कि Loaded पंक्ति दिखती है या नहीं।

4. नियम दस्तावेज़ों से नहीं, स्वचालित जाँच से लागू करवाएँ

जैसा खंड 2 में दिखा, फ़ोल्डरों में रखे नियम शुरुआत की जगह और टूल के हिसाब से शायद पढ़े ही न जाएँ। और पढ़े जाएँ, तब भी पालन की गारंटी नहीं। इसलिए लागू करवाने को तीन परतों में सोचें।

इस माहौल में हमने सबसे निचली परत, यानी रिलीज़ जाँच, को निर्णायक सुरक्षा बनाया। AI टूल बदलें या कोई व्यक्ति ख़ुद काम करे, सब कुछ उसी जाँच से गुज़रता है।

हर एजेंट का दायरा worktree-वार सेटिंग से तय करें

हर साइट को उसका अपना worktree (git worktree) दें, और worktree के सबसे ऊपर एक छोटी सेटिंग फ़ाइल (.agent-owner) रखें जिसमें वे फ़ोल्डर लिखे हों जिन्हें वहाँ काम करने वाला एजेंट बदल सकता है। अगर दायरा रिपॉज़िटरी के अंदर किसी नियम-दस्तावेज़ में लिखें, तो वह हर worktree में एक जैसा होगा और जगह के हिसाब से बदल नहीं पाएगा। सेटिंग फ़ाइल को git से बाहर रखें (.git/info/exclude में जोड़ें), और worktree बनाते समय उसे लिखें।

ध्यान दें कि AI को worktree के सबसे ऊपर से नहीं, बल्कि उसके अंदर के साइट फ़ोल्डर से शुरू करना है। worktree का सबसे ऊपरी हिस्सा रिपॉज़िटरी की रूट जैसा ही है, इसलिए वहाँ से शुरू करने पर नतीजा खंड 2 की "रिपॉज़िटरी की रूट" जैसा ही होता है।

# मुख्य checkout (/srv/repo) से, /srv/work-blog पर sites/blog के लिए worktree बनाएँ
cd /srv/repo
git worktree add /srv/work-blog -b blog-work
printf 'sites/blog/\n' > /srv/work-blog/.agent-owner
echo '.agent-owner' >> .git/info/exclude

# AI को worktree के अंदर sites/blog/ से शुरू करें
cd /srv/work-blog/sites/blog
claude        # Codex के लिए codex

# रिलीज़ से पहले, worktree के सबसे ऊपर, मुख्य checkout वाली जाँच चलाएँ
cd /srv/work-blog
bash /srv/repo/tools/check-owner.sh origin/main

जाँच की स्क्रिप्ट worktree के अंदर वाली कॉपी से नहीं, मुख्य checkout (जहाँ AI काम नहीं करता) या CI से चलाएँ। worktree वाली कॉपी चलाएँ तो जाँच की स्क्रिप्ट को ही बदल देने वाला AI सीधे निकल जाएगा।

दायरे के बाहर कुछ भी बदले तो रिलीज़ रोकें

नीचे की जाँच (ऊपर का tools/check-owner.sh) रिलीज़ प्रक्रिया की शुरुआत में रखें। यह मानकर चलती है कि रिलीज़ केवल commits से होती है: commit न किए गए बदलाव बचे हों तो रुकती है, और आधार (origin/main आदि) से commit किए गए diff में सौंपे गए फ़ोल्डरों के बाहर की एक भी फ़ाइल हो तो रुकती है। यह .agent-owner पढ़ती है, इसलिए इसे worktree के सबसे ऊपर चलाएँ।

#!/usr/bin/env bash
# रिलीज़ से पहले worktree के सबसे ऊपर चलाएँ: सौंपे गए फ़ोल्डरों के बाहर कुछ बदला हो तो रोकें
set -euo pipefail

base="${1:-origin/main}"
owner_file=".agent-owner"   # worktree के सबसे ऊपर, git से बाहर

if [ ! -s "$owner_file" ]; then
  echo "दायरे की फ़ाइल ($owner_file) नहीं है। रिलीज़ रोकी जा रही है" >&2
  exit 1
fi

# commit न किए गए बदलाव बचे हों तो रोकें (रिलीज़ केवल commits से)
if [ -n "$(git status --porcelain)" ]; then
  echo "commit न किए गए बदलाव हैं। रिलीज़ रोकी जा रही है" >&2
  exit 1
fi

# --no-renames: दूसरे फ़ोल्डर से हटाई गई फ़ाइल को हटाना और जोड़ना दोनों गिनें
# दायरे की हर प्रविष्टि के अंत में / जोड़ें (ताकि sites/blog, sites/blog-old से मेल न खाए)
# gawk (Git Bash) से परखा गया। -v के मान में नई पंक्ति हो तो BSD awk विफल हो सकता है
outside=$(git diff --name-only --no-renames "$base"...HEAD |
  awk -v list="$(tr -d '\r' < "$owner_file")" '
    BEGIN { n = split(list, own, "\n")
            for (i = 1; i <= n; i++) if (own[i] != "" && substr(own[i], length(own[i])) != "/") own[i] = own[i] "/" }
    { ok = 0; for (i = 1; i <= n; i++) if (own[i] != "" && index($0, own[i]) == 1) ok = 1
      if (!ok) print }')

if [ -n "$outside" ]; then
  echo "दायरे के बाहर की फ़ाइलें बदली हैं। रिलीज़ रोकी जा रही है:" >&2
  echo "$outside" >&2
  exit 1
fi
echo "केवल दायरे के भीतर के बदलाव"

ये उस परीक्षण के नतीजे हैं जिसमें इस लेख को लिखने वाले Claude Code ने दो साइटों और एक साझा फ़ोल्डर वाली परीक्षण रिपॉज़िटरी बनाई और 1 नवंबर 2026 को Git 2.56 (Windows पर Git Bash) के साथ यह जाँच चलाई।

--no-renames ही वह चीज़ है जो फ़ाइल ले जाने वाले बदलावों को निकलने नहीं देती। इसके बिना git जिस बदलाव को स्थानांतरण मानता है उसे केवल नए नाम से दिखाता है, इसलिए दूसरी साइट से फ़ाइलें लाने वाला बदलाव पकड़ में नहीं आता। सेटिंग फ़ाइल न होने पर भी जाँच "पास" नहीं, "रुकी" होती है, ताकि जिस worktree का दायरा कभी तय ही नहीं हुआ वह निकल न जाए।

टूल गार्ड जोड़ें

केवल रिलीज़ से पहले रोकने का मतलब है कि आपको तब पता चलता है जब AI दायरे के बाहर कुछ बदल चुका होता है। लिखने से पहले ही रोकने के लिए टूल की अपनी सुविधाएँ जोड़ें।

स्रोत: Anthropic का Configure permissions और Hooks guide, तथा OpenAI का Hooks और Rules (1 नवंबर 2026 को जाँचे गए)।

Claude Code में, blog वाले worktree को दायरे की फ़ाइल (.agent-owner), जाँच की स्क्रिप्टें (tools/), रूट के नियम, shop और साझा फ़ोल्डर बदलने से रोकने वाली सेटिंग ऐसी दिखती है (मानकर कि worktree /srv/work-blog पर है)। // से शुरू होने वाले पाथ absolute पाथ हैं। worktree की जगह हर मशीन पर अलग होती है, इसलिए इन्हें रिपॉज़िटरी में शामिल सेटिंग में नहीं, बल्कि worktree बनाते समय उस मशीन की यूज़र सेटिंग (~/.claude/settings.json) में जोड़ें।

{
  "permissions": {
    "deny": [
      "Edit(//srv/work-blog/.agent-owner)",
      "Edit(//srv/work-blog/tools/**)",
      "Edit(//srv/work-blog/CLAUDE.md)",
      "Edit(//srv/work-blog/AGENTS.md)",
      "Edit(//srv/work-blog/sites/shop/**)",
      "Edit(//srv/work-blog/sites/shared/**)",
      "Edit(//srv/repo/**)"
    ]
  }
}

Codex में, जाँच की स्क्रिप्ट को hooks की सेटिंग (आपकी निजी ~/.codex/hooks.json, रिपॉज़िटरी की .codex/hooks.json आदि) में PreToolUse के अंतर्गत दर्ज करें, और matcher के रूप में apply_patch दें। जब तक आप Codex में /hooks से hooks की समीक्षा करके उन पर भरोसा न जताएँ, वे नहीं चलते (बदलने पर दोबारा भरोसा जताना पड़ता है)।

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "^apply_patch$",
        "hooks": [ { "type": "command", "command": "python3 ~/.codex/hooks/owner_guard.py" } ] }
    ]
  }
}

जाँच की स्क्रिप्ट apply_patch के इनपुट की *** Add File:, *** Update File:, *** Delete File: और *** Move to: पंक्तियों से लक्ष्य पाथ निकालती है, और उनमें से कोई दायरे के बाहर या सुरक्षित हो तो deny लौटाती है। नीचे एक न्यूनतम उदाहरण है।

import json, posixpath, re, sys

# Codex PreToolUse hook: दायरे के बाहर या सुरक्षित फ़ाइलें बदलने वाले apply_patch को रोकें
OWN = ["/srv/work-blog/sites/blog/"]                  # दायरा (अंत में / शामिल करें)
PROTECT = ["/srv/work-blog/.agent-owner", "/srv/work-blog/tools/"]

event = json.load(sys.stdin)
command = event.get("tool_input", {}).get("command", "")
if isinstance(command, list):
    command = "\n".join(command)

bad = []
for m in re.finditer(r"^\*\*\* (?:Add File|Update File|Delete File|Move to): (.+)$", command, re.M):
    path = posixpath.normpath(posixpath.join(event.get("cwd", ""), m.group(1).strip()))
    if not any(path.startswith(o) for o in OWN) or any(path.startswith(p) for p in PROTECT):
        bad.append(path)

if bad:
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": "दायरे के बाहर की फ़ाइलें: " + ", ".join(bad)}}, ensure_ascii=False))

इस लेख को लिखने वाले Claude Code ने यह स्क्रिप्ट Codex जिस रूप में इनपुट देता है उसी रूप में हाथ से बनाए इनपुट (दायरे के भीतर, shop, .agent-owner, shared में ले जाना, और tools/ के नीचे हटाना) पर चलाई और पक्का किया कि केवल दायरे के भीतर का बदलाव पास हुआ। इसे Codex के अंदर नहीं चलाया गया है।

Bash कमांड कई तरह से लिखे जा सकते हैं, इसलिए hook पूरी तरह तय नहीं कर सकता कि वे कहाँ लिखेंगे। OpenAI ख़ुद hooks को "a useful guardrail, not a complete enforcement boundary" कहता है। जिन कमांड को रोकना है, जैसे rm, उन्हें decision = "forbidden" वाले नियम से रोकें, और बाक़ी को रिलीज़ जाँच पकड़े। नियम किसी config परत के rules/ फ़ोल्डर में जाते हैं, जैसे ~/.codex/rules/default.rules। प्रोजेक्ट का .codex/rules/ केवल तब पढ़ा जाता है जब वह प्रोजेक्ट भरोसेमंद हो।

टूल गार्ड हर टूल के लिए दोबारा लिखने पड़ते हैं, और शुरुआत की जगह व trust सेटिंग के हिसाब से शायद लागू न हों। इसलिए आधार रिलीज़ जाँच को बनाएँ, जिससे हर बदलाव को आख़िर में गुज़रना ही है, और समस्याएँ पहले पकड़ने के लिए उसके ऊपर टूल गार्ड लगाएँ। Claude Code के hooks लिखने के लिए "Claude Code hooks क्या हैं? shell कमांड डिटरमिनिस्टिक रूप से चलाएँ" देखें; केवल-पढ़ने वाली सेटिंग के लिए "Codex और Claude Code को read-only में कैसे चलाएँ: केवल जाँच और सलाह के लिए" देखें।

5. इनका भी ध्यान रखें: रिपॉज़िटरी और एनवायरनमेंट वेरिएबल की गड़बड़ी

उसी माहौल में, AI को कई रिपॉज़िटरी सौंपने पर दो और बातें हुईं। दोनों गंभीर घटना बनने से पहले पकड़ ली गईं, लेकिन नियम रखने के तरीक़े से अलग, इनके लिए भी प्रक्रिया बनाएँ।

मिलते-जुलते नाम वाली रिपॉज़िटरी को remote URL से पहचानें

एक AI ने बहुत मिलते-जुलते नाम वाली एक दूसरी सेवा की रिपॉज़िटरी को "उसी सेवा की पुरानी कॉपी" मान लिया और उसे कहीं और ले गया (उसे तुरंत वापस रख दिया गया, सामग्री में कोई बदलाव नहीं हुआ था)। उसका तर्क था "कोई स्थानीय बदलाव नहीं, और आख़िरी अपडेट पुराना है", पर इससे केवल यह पता चलता है कि "कुछ भी बदलाव के बीच में नहीं है" और "हाल में किसी ने इसे संपादित नहीं किया"। कोई सेवा जितनी स्थिर चलती है, उतनी ही कम अपडेट होती है।

कुछ भी ले जाने या हटाने से पहले, लक्ष्य फ़ोल्डर और प्रोडक्शन में इस्तेमाल होने वाले फ़ोल्डर दोनों में नीचे के कमांड चलाएँ और नतीजे साथ-साथ मिलाएँ।

# Remote URL (दिखाने से पहले URL में जुड़ा कोई token या password हटा दें)
git -C <folder> remote get-url origin | sed -E 's#://[^/@]+@#://#'

# पहले जाँचें कि यह shallow clone नहीं है (true हो तो अगला नतीजा भरोसेमंद नहीं)
git -C <folder> rev-parse --is-shallow-repository

# Root commit (एक ही इतिहास से निकली कॉपियों में यह एक जैसा होता है)
git -C <folder> rev-list --max-parents=0 HEAD

• remote URL को होस्ट और रिपॉज़िटरी पाथ से मिलाएँ: https://github.com/org/app.git और git@github.com:org/app.git एक ही रिपॉज़िटरी के अलग-अलग लिखे रूप हैं; उलटे, mirror या होस्ट alias होने पर एक ही रिपॉज़िटरी अलग दिख सकती है
• shallow clone में root commit असली पहला commit नहीं होता: --depth 1 से लिए गए clone में आपको लाया गया सबसे पुराना commit मिलता है (हमारे परीक्षण में ख़ुद HEAD)
• URL में जुड़े token न दिखाएँ: remote URL में प्रमाणीकरण token हो सकता है, और उसे जैसे का तैसा छापने से गोपनीय मान आउटपुट में लीक हो जाता है, ठीक नीचे के एनवायरनमेंट वेरिएबल की तरह

तुलना से "इस्तेमाल न होने वाली कॉपी" साबित हो जाए, तब भी उसे तुरंत न हटाएँ; पहले कहीं और ले जाएँ। लिख लें कि वह कहाँ गई, कहाँ थी और उसे वापस रखने का कमांड क्या है, और कुछ समय तक पक्का करने के बाद कि कुछ नहीं टूटा, तभी हटाएँ। इस माहौल में गड़बड़ी तुरंत इसीलिए ठीक हो सकी क्योंकि फ़ोल्डर हटाया नहीं गया था, बल्कि ले जाया गया था।

एनवायरनमेंट वेरिएबल के केवल नाम देखें

एक AI ने कंटेनर की सेटिंग देखने के लिए ऐसा कमांड चलाया जिसने एनवायरनमेंट वेरिएबल उनके मानों के साथ छाप दिए, और आउटपुट में डेटाबेस का कनेक्शन स्ट्रिंग (password सहित) आ गया। एक बार कोई मान आउटपुट में आ जाए, तो वह बातचीत के लॉग में रह जाता है और मॉडल को भी भेजा जाता है। अगर केवल यह देखना है कि क्या सेट है, तो नाम काफ़ी हैं।

docker inspect <container>
docker exec <container> printenv
docker exec <container> sh -c 'env | cut -d= -f1'

docker inspect --format '{{range .Config.Env}}{{index (split . "=") 0}}{{println}}{{end}}' <container>
docker exec <container> awk 'BEGIN{for(k in ENVIRON) print k}'

docker compose config

docker compose config --no-interpolate

env
printenv
Get-ChildItem Env:

compgen -e                  # bash
(Get-ChildItem Env:).Name   # PowerShell

ये उस परीक्षण के नतीजे हैं जिसमें इस लेख को लिखने वाले Claude Code ने 1 नवंबर 2026 को Docker 29.8 और Docker Compose v5.6 के साथ नक़ली मानों से परखा। ऐसे कंटेनर में जिसके एक मान में नई पंक्तियाँ थीं (key फ़ाइल की सामग्री देते समय इस्तेमाल होने वाला रूप), env | cut -d= -f1 चलाने पर मान की दूसरी और तीसरी पंक्ति वेरिएबल के नामों के बीच जैसी की तैसी छप गईं। awk के ENVIRON और docker inspect --format ने मान नहीं दिखाए। docker compose config ने .env और env_file में लिखे नक़ली मान दिखाए; --no-interpolate के साथ दोनों में से कोई नहीं दिखा, और केवल compose.yaml में सीधे लिखा मान दिखा।

पक्का करने के लिए, नियम-दस्तावेज़ों में "एनवायरनमेंट वेरिएबल के केवल नाम देखें" लिखें, और मान छापने वाले कमांड खंड 4 के टूल गार्ड से भी मना करें। अगर फिर भी कोई मान छप जाए, तो उसे "देखा जा चुका" मानें और तय करें कि उसे बदलना (rotate करना) है या नहीं। Codex की उस सेटिंग के लिए जो AI के कमांड तक एनवायरनमेंट वेरिएबल पहुँचने ही नहीं देती, "Codex को गोपनीय फ़ाइलें पढ़ने से कैसे रोकें: अनुमतियाँ, मंज़ूरी और नेटवर्क की सीमाएँ" का खंड 6 देखें।

6. काम सौंपने से पहले की चेकलिस्ट

• तय किया कि साइट का काम AI को worktree के अंदर साइट के फ़ोल्डर से शुरू करके होगा
• शुरू करने के बाद पक्का किया कि साइट के नियम शामिल हैं: Claude Code में /context की Memory files, Codex में सक्रिय निर्देश-फ़ाइलों की सूची
• रूट से शुरू होने वाले काम के लिए यह देखने का तरीक़ा तैयार किया कि सेशन के बीच निचले फ़ोल्डरों के नियम पढ़े गए या नहीं (Claude Code की Loaded पंक्ति, InstructionsLoaded hook)
• ऐसी जाँच जोड़ी जो सौंपे गए फ़ोल्डरों के बाहर कुछ बदलने पर रिलीज़ रोकती है, और जान-बूझकर दायरे के बाहर बदलाव करके उसे रुकते देखा
• हर worktree का दायरा अंत में स्लैश के साथ लिखा, और दायरे की फ़ाइल न होने पर जाँच को रोकने लायक़ बनाया
• दायरे के बाहर और दायरे की फ़ाइल में लिखना टूल गार्ड से मना किया
• नियमों में यह प्रक्रिया लिखी कि किसी फ़ोल्डर को ले जाने या हटाने से पहले उसका remote URL और root commit प्रोडक्शन से मिलाएँ, और हटाने के बजाय ले जाएँ
• नियमों में केवल एनवायरनमेंट वेरिएबल के नाम दिखाने वाले कमांड लिखे, और मान छापने वाले कमांड टूल गार्ड से मना किए

## कई प्रोजेक्ट के साथ काम करते समय के नियम
- इस worktree का दायरा केवल .agent-owner में लिखे फ़ोल्डर हैं। इसके बाहर की फ़ाइलें न बदलें
  (वहाँ के बदलाव रिलीज़ जाँच को रोक देते हैं)
- किसी फ़ोल्डर को ले जाने या हटाने से पहले git remote get-url origin और
  git rev-list --max-parents=0 HEAD को प्रोडक्शन से मिलाएँ (shallow clone से सावधान)।
  हटाने के बजाय ले जाएँ, और वापस रखने का तरीक़ा लिख लें
- एनवायरनमेंट वेरिएबल के केवल नाम देखें। env, printenv, docker inspect (--format के बिना) या
  docker compose config (--no-interpolate के बिना) इस्तेमाल न करें

सारांश

अक्सर पूछे जाने वाले सवाल

प्र. क्या सबडायरेक्टरी की CLAUDE.md पढ़ी जाती है?

उ. हाँ, पर शुरुआत में नहीं। Claude Code किसी फ़ोल्डर की CLAUDE.md तब पढ़ता है जब Claude उस फ़ोल्डर के अंदर की कोई फ़ाइल पढ़ता, लिखता या संपादित करता है। उस समय वह /context की Memory files में नहीं दिखती; इसके बजाय टर्मिनल में उसके पाथ के साथ Loaded पंक्ति दिखती है। अगर आप उसी फ़ोल्डर से शुरू करें, तो वह शुरुआत में पढ़ी जाती है और Memory files में दिखती है।

प्र. Codex से सबडायरेक्टरी की AGENTS.md कैसे पढ़वाएँ?

उ. Codex को उसी फ़ोल्डर से शुरू करें (CLI में codex --cd <folder>)। शुरुआत में Codex प्रोजेक्ट रूट से शुरुआत की डायरेक्टरी तक की AGENTS.md फ़ाइलें पढ़ता है, और उसके नीचे नहीं खोजता। रूट से शुरू करें, तो निचले फ़ोल्डर की AGENTS.md तभी पढ़ी जाती है जब AI ख़ुद उसे खोले, लेकिन आधिकारिक दस्तावेज़ इसे पक्के तौर पर पढ़वाने वाली कोई सेटिंग नहीं बताते।

प्र. मोनोरेपो में क्या नियम-दस्तावेज़ों को रूट की एक फ़ाइल में इकट्ठा कर देना चाहिए?

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

प्र. Claude Code से CLAUDE.md और AGENTS.md दोनों कैसे पढ़वाएँ?

उ. डिफ़ॉल्ट रूप से, अगर शुरुआत की डायरेक्टरी या उसके ऊपर CLAUDE.md, .claude/CLAUDE.md या CLAUDE.local.md हो, तो AGENTS.md नहीं पढ़ी जाती। या तो CLAUDE.md में एक पंक्ति @AGENTS.md से उसे import करें, या /config में Project instructions को claude-md-and-agents-md पर सेट करें।

स्रोत

• Anthropic: How Claude remembers your project, Monorepos and large repos, Claude Code settings, Configure permissions, Hooks guide
• OpenAI: Custom instructions with AGENTS.md, Config basics, Hooks, Rules, Sandboxing
• Docker: docker inspect, docker compose config