Codex CLI से osFoundry के team या loop session में runs queue कैसे करवाएँ

यह सब हो जाने के बाद Codex CLI osFoundry के किसी team या loop session में Runner की seat पर बैठा होगा। Terminal से वह request_session_run के ज़रिए एक सीमित goal queue करता है। Session के अपने agents उस पर session के runtime पर काम करते हैं, और Codex read_session_task_result से result वापस पढ़ता है। फिर वह post_session_note से session के Team mail में एक note छोड़ता है और read_session_mail से agents के जवाब उठाता है। हर run पर किसी को कुछ click नहीं करना पड़ता: owner ने एक बार जो Runner seat दी, वही approval है।

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

	Codex CLI	osFoundry
Login	आपका Codex sign-in। osFoundry का OAuth token osfoundry:run scope के साथ Codex के पास रहता है	Owner connection को एक बार approve करता है और हर session के लिए seat चुनता है
वह क्या शुरू कर सकता है	हर call में एक goal, 10,000 characters तक, और max_rounds 1 से 10	उसे "Requested by an outside assistant" trigger वाले task के रूप में queue करता है और session के अपने agents, tools और model से चलाता है
काम कहाँ चलता है	आपकी machine पर कहीं नहीं। Codex बस इंतज़ार करता है और पढ़ता है	Session के runtime पर। Desktop runtime पर अगला poll task उठा लेता है, एक session में एक समय पर एक run
वापस क्या आता है	इस connection से शुरू हुए tasks का status और result, उसे भेजे गए notes, और उसके post किए notes	Agents का internal analysis session में ही रहता है
इसे कौन रोक सकता है	हर write tool से पहले Codex आपसे पूछता है (default_tools_approval_mode = "writes")	Owner Connected tab में seat हटा देता है या connection revoke कर देता है

Setup

1. Codex को run scope दें

Connection ख़ुद सामान्य तरीक़े से बनता है: header का key icon, Connected tab, Other MCP client, और Codex CLI जैसा कोई display name। Session के agents और owner हर run और हर note पर यही नाम देखते हैं, इसलिए ऐसा नाम चुनें जिसे लोग पहचान सकें।

Codex की तरफ़ server जोड़ें और उसे runner loop तक सीमित कर दें:

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

# ~/.codex/config.toml
[mcp_servers.osfoundry]
url = "https://api.osfoundry.io/api/v1/external-mcp"
scopes = ["osfoundry:read", "osfoundry:write", "osfoundry:run"]
default_tools_approval_mode = "writes"
enabled_tools = [
  "list_granted_resources",
  "list_project_resources",
  "read_session_state",
  "request_session_run",
  "read_session_task_result",
  "post_session_note",
  "read_session_mail",
]

फिर sign in करें:

codex mcp login osfoundry

osFoundry के "Connect an agent" page पर "Requested capabilities" में तीन lines दिखनी चाहिए। तीसरी, "Run sessions where you grant a runner role", वही है जिसके बारे में यह article है। अगर वह नहीं दिख रही, तो osfoundry:run scopes में नहीं है। File ठीक करें और दोबारा login करें।

"writes" के साथ Codex तीनों read tools बिना पूछे चलाता है और request_session_run व post_session_note से पहले रुकता है, यही दो tools हैं जिन पर read-only का निशान नहीं है।

2. Connection को session के project में जोड़ें

Connected tab में वापस आकर Projects के नीचे वह project चुनें जिसमें session है, और Add to project पर click करें। इससे project के sessions connection को दिखने लगते हैं। अभी वह इनमें से किसी में लिख नहीं सकता।

3. उसे Runner की seat दें

थोड़ा नीचे "Agent, Team, and Loop sessions" है। Help line roles को साफ़ बताती है: "Invite it to a session as Contributor to post notes and propose handoffs, or Runner to also request runs."

Session type चुनें (Agent session, Team session या Loop session), "Choose a session in this agent's projects" से session चुनें, role को Runner पर सेट करें और Save role पर click करें। Toast में "Session role saved" आता है, और seat एक line में दिखती है: type, session का नाम और role।

उदाहरण: Agent, Team, and Loop sessions section, जिसमें Codex CLI Triage desk team session में Runner है

तीन roles हैं, और Contributor से Runner तक का फ़र्क़ सिर्फ़ एक tool का है:

Role (dropdown में)	State, results, mail पढ़ना	Notes post करना	Runs queue करना
Viewer	हाँ	नहीं	नहीं
Contributor	हाँ	हाँ	नहीं
Runner	हाँ	हाँ	हाँ

उसी session के लिए दूसरा role save करने पर पुराना role बदल जाता है। Remove seat हटा देता है।

उसी panel में एक Tools section भी है ("All supported tools are on by default")। वहाँ किसी tool का tick हटाने पर वह osFoundry की तरफ़ से हट जाता है, चाहे Codex का enabled_tools कुछ भी कहे।

एक असली run

जिस machine पर यह लिखा गया, उस पर Codex installed नहीं है, इसलिए नीचे का session एक simulated Example है। Tool names और argument names live server के ही हैं, उस mcp__osfoundry__ prefix के साथ जो Codex जोड़ता है। Project, session, agents और सारी values demo content हैं।

Example (simulated)

> The duplicate-invoice email fix is in PR #231. Ask the osFoundry Triage desk
  which open tickets are about it, then tell them the fix ships Thursday.

• mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "team_session",
      "search": "triage"}
  ← team_session "Triage desk"
• mcp__osfoundry__read_session_state {"session_type": "team_session", "session_id": "…"}
  ← idle, agents @triager @writer
• mcp__osfoundry__request_session_run {
      "session_type": "team_session", "session_id": "…",
      "goal": "List open support tickets from the last 7 days that report getting the same invoice email twice. For each: ticket id, customer plan, one-line status. Background: the cause is a retry in the mail job, fixed in PR #231, not deployed yet. Do not reply to customers.",
      "max_rounds": 3, "idempotency_key": "codex-pr231-dupe-tickets"}
  [Codex asks: allow this tool call? → yes]
  ← queued, task_id "…"
• mcp__osfoundry__read_session_task_result {"session_type": "team_session",
      "session_id": "…", "task_id": "…"}
  ← pending
  … (Codex waits and asks again)
• mcp__osfoundry__read_session_task_result {…same…}
  ← completed: 4 tickets (#5512, #5518, #5530, #5541), all on the Team plan
• mcp__osfoundry__post_session_note {"session_type": "team_session", "session_id": "…",
      "subject": "Duplicate invoice emails: fix ships Thursday",
      "body": "Root cause was a retry in the mail job. PR #231 is merged and goes out Thursday. #5512, #5518, #5530 and #5541 can be told that.",
      "idempotency_key": "codex-pr231-note"}
  [Codex asks: allow this tool call? → yes]
• mcp__osfoundry__read_session_mail {"session_type": "team_session", "session_id": "…",
      "limit": 10}
  ← 2 notes: yours, and @writer: "Drafted replies for all four, holding until Thursday."

The Triage desk found four open tickets about the duplicate email, all on the
Team plan. I told the team the fix ships Thursday; @writer has replies drafted
and is holding them until then.

Background goal में ही जाता है। request_session_run में context के लिए कोई अलग field नहीं है, और schema ऐसे किसी भी argument को ठुकरा देता है जो उसकी list में नहीं है, इसलिए agents को जो भी जानना चाहिए वह goal के अंदर ही लिखें।

Owner की तरफ़ यह run किसी गुमनाम job की तरह नहीं दिखता। Session का Trigger tab ("What starts this session") इसे "Requested by an outside assistant" के रूप में दिखाता है, नीचे goal के साथ, फिर काम चलते समय "Running now." और पूरा होने पर "Last run:"।

उदाहरण: Triage desk session का Trigger tab, जिसमें किसी outside assistant का request किया हुआ run है

Note Team mail में connection के display name से पहुँचता है, "outside assistant" के निशान के साथ। Agents उसका जवाब दे सकते हैं, और वही जवाब read_session_mail Codex तक वापस लाता है।

उदाहरण: Team mail, जिसमें Codex CLI का outside assistant निशान वाला note और @writer का जवाब है

सीमा कहाँ है

Runner काम शुरू कर सकता है, लेकिन session को बदल नहीं सकता। Schema बंद है (additionalProperties: false), इसलिए Codex कोई model, tools की list या अतिरिक्त context नहीं भेज सकता। Session अपनी settings पर और अपने owner के runtime पर चलता है। max_rounds 10 पर रुक जाता है।

कोई भी queue नहीं तोड़ सकता। जब session owner के desktop app पर चलता है, तो काम रहने तक runtime हर 15 seconds में due tasks ढूँढता है। चार ख़ाली polls के बाद वह 30 seconds, फिर 60, फिर पाँच minutes तक धीमा हो जाता है, और app में कोई व्यक्ति कुछ भी करे तो वह तुरंत जाग जाता है। वह हर session में एक समय पर एक task चलाता है और अगले को तब तक रोके रखता है जब तक session ख़ाली न हो। इसीलिए tool कहता है कि runtime task को "when available" चलाता है। Codex को result के लिए poll करना चाहिए, एक ही call खुली रखकर इंतज़ार नहीं करना चाहिए।

बाहर से आया text बाहर का text ही माना जाता है। Desktop runtime के code में सिर्फ़ वह run operator input गिना जाता है जिसे owner ने हाथ से शुरू किया हो। किसी outside assistant का goal उसी तरह screen होता है जैसे webhook body। Goal को सीधे-सादे instructions की तरह लिखें, और उसमें ऐसा कुछ paste न करें जिसे आप screen होते नहीं देखना चाहेंगे।

Codex को results दिखते हैं, बातचीत नहीं। read_session_task_result सिर्फ़ उन tasks का जवाब देता है जो इस connection ने शुरू किए। read_session_mail connection को भेजे गए notes और उसके post किए notes लौटाता है, हर call में 1 से 20, और agents का internal analysis उसमें शामिल नहीं होता। Note कभी run शुरू नहीं करता। Tool description कहता है कि यह "does not trigger an automatic run", इसलिए अंदर आने का रास्ता अब भी सिर्फ़ seat है।

जो चीज़ें सिर्फ़ owner के desktop पर रहती हैं, वे पहुँच से बाहर रहती हैं। Server का initialize reply कहता है "Local-only data is unavailable to cloud clients."

आगे एक loop session आज़माएँ। Codex CLI को किसी ऐसे loop में Runner बनाएँ जिसे आप अभी हाथ से चलाते हैं, फिर हर merge के बाद Codex से loop का अगला pass queue करवाएँ, एक paragraph के goal के साथ जो बताए कि क्या बदला। Agent task queue दिखाता है कि ये runs कहाँ line में लगते हैं, और Agent Mail बताता है कि notes agents के बीच कैसे पहुँचते हैं।