BBT for BBT हिन्दी

Posted on Nov 7

Codex CLI को MCP के ज़रिए osFoundry के notes और knowledge bases कैसे पढ़वाएं

#codex #mcp #osfoundry #tutorial

इस guide के अंत तक Codex CLI आपकी repository में काम करते हुए आपके किसी osFoundry project का spec Note, support knowledge base और bug Records खुद देख पाएगा। वह इन्हें osFoundry के MCP server के ज़रिए पढ़ता है, कुछ भी लिखने से पहले आपसे पूछता है, और उसकी हर call osFoundry में connection के Recent activity (हाल की गतिविधि) में दर्ज होती है। Setup में बस तीन चीज़ें हैं: ~/.codex/config.toml में एक table, browser में एक बार sign-in, और connection को project में जोड़ने के लिए एक click।

कौन क्या करता है

	Codex की तरफ़	osFoundry की तरफ़
Login	आपका सामान्य Codex sign-in, बिना बदलाव। osFoundry का OAuth token Codex रखता है	आपका osFoundry account connection को एक बार, एक workspace के लिए approve करता है
Model कौन चलाता है	Codex, आपकी machine पर, आपके अपने Codex plan से	कोई नहीं। इस रास्ते में न कोई model है, न provider key
Tools कहां चलते हैं	Codex tool call को HTTPS पर भेजता है	`api.osfoundry.io` पहले access जांचता है, फिर उसे चलाता है
Codex को कौन से tools दिखते हैं	`config.toml` में `enabled_tools` / `disabled_tools`	Connection की Tools checklist
वह कहां तक पहुंच सकता है	जो कुछ server लौटाए	वे projects जिनमें आपने connection जोड़ा, और वे channels जिनमें आपने उसे invite किया
Approvals	Codex का अपना prompt, जो `default_tools_approval_mode` से तय होता है	GitNest और Room के बदलाव "Needs your approval" (आपकी मंज़ूरी चाहिए) में इंतज़ार करते हैं
Data कहां रहता है	जवाब और diffs आपके Codex session में रहते हैं	Notes, records और articles osFoundry में रहते हैं। Local-only items कभी device से बाहर नहीं जाते

Setup

1. osFoundry में connection बनाएं

osFoundry header में key icon पर click करें और Connected tab खोलें ("Connected agents", जिसके नीचे मौजूदा workspace का नाम होता है)। "Connect in three steps" के नीचे वाले form में:

Assistant: Other MCP client
Display name: कोई ऐसा नाम जिसे आप पहचान सकें, जैसे Codex CLI
Add assistant (assistant जोड़ें) पर click करें

Connection "Setup pending. This assistant cannot read or change anything yet." के रूप में दिखेगा। Server address copy कर लें:

https://api.osfoundry.io/api/v1/external-mcp

उदाहरण: Codex CLI connection चुना हुआ Connected tab

2. Codex में server जोड़ें

OpenAI के Codex MCP documentation से एक लाइन का command:

codex mcp add osfoundry --url https://api.osfoundry.io/api/v1/external-mcp

यह एक [mcp_servers.osfoundry] table लिख देता है। ~/.codex/config.toml खोलें और इसे कस दें। नीचे की हर key उसी documentation में है:

[mcp_servers.osfoundry]
url = "https://api.osfoundry.io/api/v1/external-mcp"
scopes = ["osfoundry:read", "osfoundry:write"]
default_tools_approval_mode = "writes"
enabled_tools = [
  "list_granted_resources",
  "list_project_resources",
  "list_note_tabs",
  "read_note_tab",
  "read_sheet_range",
  "search_knowledge_base",
  "read_knowledge_article",
  "list_record_items",
  "read_record_item",
  "edit_record_item",
]

हर लाइन क्या करती है:

scopes server की पेशकश की जगह लेता है। इसके बिना Codex scopes server के challenge या उसके protected-resource metadata से लेता है, और osFoundry के metadata में चार scopes हैं, जिनमें osfoundry:run भी है। जो coding assistant सिर्फ़ records पढ़ता और update करता है, उसे sessions चलाने की ज़रूरत नहीं।
default_tools_approval_mode = "writes" से Codex हर उस tool के लिए पूछता है जिस पर read-only का निशान नहीं है। osFoundry अपने tools पर readOnlyHint लगाता है, इसलिए नौ read tools बिना prompt के चलते हैं और edit_record_item पहले पूछता है।
enabled_tools tool list को छोटा रखता है। Server 59 tools advertise करता है; यह list दस की है। नाम raw MCP tool names हैं, बिना किसी prefix के। गलत spelling वाला नाम error नहीं देता। बस वह tool मौजूद नहीं होता।

अगर server सिर्फ़ एक repository में लागू होना चाहिए, तो यही table उस repository की .codex/config.toml में रखें। Codex project config सिर्फ़ उन projects के लिए पढ़ता है जिन्हें आपने trusted mark किया है।

3. Sign in करें

codex mcp login osfoundry

Browser https://osfoundry.io/external-assistant-authorize खोलता है, जिसका title "Connect an agent" है। इसमें Assistant client और "Returns to" दिखते हैं। "Returns to" एक local address है, क्योंकि Codex callback आपकी machine पर ही पकड़ता है। फिर:

Workspace to connect: एक चुनें। दूसरे workspace के लिए अलग connection चाहिए।
Requested capabilities: ऊपर वाले scopes के साथ आपको दो लाइनें दिखेंगी, "Read supported resources in projects you add" और "Change supported resources where you have edit access"।
Connection: "Use pending: Codex CLI" चुनें ताकि sign-in step 1 वाले connection से जुड़ जाए।
"I approve connecting this assistant to " पर tick करें और Connect पर click करें।

SSH पर किसी remote machine में codex mcp login osfoundry --no-browser इसकी जगह URL print करता है। आप उसे अपने laptop पर खोलते हैं और पूरा redirect URL वापस terminal में paste कर देते हैं।

osFoundry के server में registration endpoint है और वह public clients स्वीकार करता है, इसलिए Codex खुद को register कर लेता है। कोई client ID paste नहीं करना पड़ता।

4. Connection को project में जोड़ें

वापस key icon → Connected में connection अब "Connected." दिखाता है। Projects के नीचे project चुनें और Add to project (project में जोड़ें) पर click करें। इससे उस project के synced Notes, knowledge bases, Record channels, cloud Rooms, assigned GitNest repositories और उसका discussion channel खुल जाते हैं, बाद में जोड़ी गई चीज़ों समेत। बाकी Message channels के लिए हर एक में अलग Invite (आमंत्रण) चाहिए।

Tools section "All supported tools are on by default." से शुरू होता है। जो कुछ यह connection कभी call न करे, उसे untick करें, भले ही बाद में कोई config.toml edit कर दे, और Save tools (tools save करें) पर click करें।

उदाहरण: सिर्फ़ read tools ticked वाली Tools checklist, फिर Save tools

5. Codex से जांचें

codex TUI में /mcp active servers की list दिखाता है। उसमें osfoundry होना चाहिए। फिर सीधे सामान्य शब्दों में पूछें।

एक असली run

जिस machine पर यह लिखा गया, उस पर Codex installed नहीं है, इसलिए नीचे का session एक simulated उदाहरण है। Tool names वही हैं जो live server tools/list से लौटाता है। Codex का source model को दिखने वाले नामों में MCP tools के आगे mcp__<server>__ लगाता है, इसलिए यहां वे इसी रूप में दिखते हैं। Prompt, project और जवाब demo content हैं।

उदाहरण (simulated)

> tests/test_refund.py में fail हो रहा test 14 दिन की window मान रहा है।
  कुछ भी बदलने से पहले osFoundry का spec और support KB check करो।

• mcp__osfoundry__list_granted_resources {}
  ← 1 project: "Billing v2"
• mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "note", "search": "refund"}
  ← Note "Refund नियम (spec)"
• mcp__osfoundry__list_note_tabs {"note_id": "…"}
  ← tabs: Note (text), Sheet "Edge cases"
• mcp__osfoundry__read_note_tab {"note_id": "…", "tab_id": "…"}
  ← "Refund invoice की तारीख से 30 दिनों के भीतर स्वीकार किए जाते हैं…"
• mcp__osfoundry__search_knowledge_base {"knowledge_base_id": "…", "query": "refund window"}
  ← article "Refund policy", 2 दिन पहले update हुआ: 30 दिन
• edited src/billing/refund.py, tests/test_refund.py
• mcp__osfoundry__edit_record_item {"record_channel_id": "…", "item_id": "…",
      "values": {"status": "Fixed"}, "expected_version": "…", "idempotency_key": "…"}
  [Codex पूछता है: इस tool call की अनुमति दें? → हां]
  ← saved

गलती code में नहीं, test में थी। Spec Note और KB article दोनों 30 दिन
कहते हैं। मैंने test और constant का comment बदला, pytest चलाया
(12 passed), और "Refund window 16 दिन से गलत" record को Fixed कर दिया।

edit_record_item वह version साथ ले जाता है जो read_record_item या list_record_items ने लौटाया था, इसलिए जिस record को इस बीच किसी ने बदल दिया हो, वह overwrite होने के बजाय reject हो जाता है। दोहराया गया idempotency_key पहला result लौटाता है, इसलिए retry की गई call दो बार नहीं लिखती। बीच का approval prompt osFoundry से नहीं, Codex से आता है, और वह default_tools_approval_mode = "writes" की वजह से है।

सीमा कहां है

Codex osFoundry को पढ़ता है, osFoundry Codex को नहीं पढ़ता। यह connection Codex को तब tools call करने देता है जब वह खुद तय करे। osFoundry हर call को Recent activity में tool name, access decision और समय के साथ दर्ज करता है, लेकिन वह आपका Codex session, repository या terminal नहीं खोल सकता। आपका source code कहीं नहीं जाता, जब तक Codex उसे किसी tool argument में न डाल दे, जैसे किसी record का comment।

दोनों filters अलग काम करते हैं। config.toml में enabled_tools तय करता है कि model को क्या offer किया जाए, जिससे prompt छोटा और विकल्प साफ़ रहते हैं। osFoundry की Tools checklist owner का switch है, और local file में चाहे जो लिखा हो, वह लागू रहती है। इनमें से कोई भी किसी चीज़ का access नहीं देता। वह काम project membership का है।

Access हर call पर तय होता है। हर call को connection के status, उसके workspace, मौजूदा project membership, item अभी जिस project में है, और उस पर आपकी अपनी role के सामने जांचा जाता है। किसी Note को दूसरे project में ले जाएं, project हटा दें, या Revoke connection (connection रद्द करें) पर click करें, तो Codex की अगली call reject हो जाती है, भले ही उसका token expire न हुआ हो।

कुछ writes proposals होते हैं। GitNest work, change sets, file imports और pull requests propose_… tools से होकर जाते हैं और Connected tab में "Needs your approval" के नीचे target और files की list के साथ तब तक इंतज़ार करते हैं, जब तक आप Approve या Decline पर click न करें। Codex को आपके Git provider का token कभी नहीं मिलता। ऊपर का example config वैसे भी इन tools को बाहर रखता है, क्योंकि Codex के पास आपका local checkout पहले से है।

Local-only data local ही रहता है। Server का initialize reply यही कहता है: "Local-only data is unavailable to cloud clients." Local Rooms, local Graph sessions और जो कुछ sync नहीं हुआ है, वह इस connection से नहीं दिखता।

आगे क्या

Codex को किसी ऐसे knowledge base की ओर इशारा करें जिससे आप पहले से सवालों के जवाब देते हैं, और उससे किसी docstring या error message को उसके सामने मिलाने को कहें, जैसे "क्या इस error के लिए KB की wording वही है जो code print करता है?"। search_knowledge_base article ID और आखिरी update का समय लौटाता है, इसलिए source verify करना आसान है। osFoundry इन्हें कैसे organise करता है, यह knowledge bases page पर है।

DEV Community