Codex में Subagents का सपोर्ट शुरू

• OpenAI Codex अब subagent workflow को सपोर्ट करता है, जिससे जटिल कामों को कई विशेषज्ञ agents में parallel बाँटकर उनके नतीजों को एक जवाब में जोड़ा जा सकता है
• Codex केवल तब subagents बनाता है जब उपयोगकर्ता स्पष्ट रूप से अनुरोध करे, और हर agent अपने मॉडल व tools को स्वतंत्र रूप से इस्तेमाल करता है, इसलिए token खपत single-agent की तुलना में बढ़ती है
• Custom agents को TOML फ़ाइलों में परिभाषित किया जा सकता है, जिससे model, sandbox mode, MCP server आदि को हर agent के लिए अलग-अलग सेट किया जा सकता है
• CSV फ़ाइल की हर row को एक task unit मानकर worker agents को bulk में बनाने वाली spawn_agents_on_csv नाम की experimental सुविधा भी शामिल है
• आधिकारिक docs में code review, frontend debugging जैसे वास्तविक scenarios के लिए custom agent combinations के patterns सीधे बताए गए हैं

---

Subagents का अवलोकन और उपलब्धता

• Codex subagent workflow को सपोर्ट करता है, जो विशेषज्ञ agents को parallel में spawn करके उनके नतीजों को एक जवाब में इकट्ठा करता है
• यह codebase exploration या multi-step feature implementation planning जैसे उच्च parallelism वाले जटिल कामों में खास तौर पर उपयोगी है
• Subagent workflow में task के अनुसार अलग model settings और instructions वाले custom agents भी परिभाषित किए जा सकते हैं
• मौजूदा Codex release में subagent workflow default रूप से enabled है
• Subagent activity अभी Codex app और CLI में देखी जा सकती है, और IDE Extension में visibility जल्द जोड़ी जाएगी
• Codex केवल तब subagents बनाता है जब उपयोगकर्ता स्पष्ट रूप से अनुरोध करे, और हर subagent अपना model व tools चलाता है, इसलिए single-agent execution की तुलना में token खपत अधिक होती है

सामान्य workflow

• Agents के बीच orchestration Codex संभालता है: नए subagents बनाना, follow-up instructions route करना, results का इंतज़ार करना, और agent threads बंद करना
• जब कई agents चल रहे हों, Codex सभी requests के results तैयार होने तक इंतज़ार करता है और फिर combined response लौटाता है
• उदाहरण prompt: मौजूदा PR के लिए security issues, code quality, bugs, race conditions, test flakiness और maintainability पर हर एक के लिए अलग agent बनाकर कुल नतीजों का सार देने के लिए कहना

Subagent प्रबंधन

• CLI में /agent कमांड से active agent threads के बीच switch किया जा सकता है और चल रहे threads की जाँच की जा सकती है
• Codex से सीधे कहकर चल रहे subagents को guide, stop, या completed threads को terminate किया जा सकता है

Approvals और sandbox control

• Subagents उपयोगकर्ता की मौजूदा sandbox policy inherit करते हैं
• Interactive CLI session में inactive agent threads के approval requests, main thread इस्तेमाल होने पर भी दिख सकते हैं, और approval overlay में source thread label दिखाई देता है
  • o दबाकर उस thread को खोला जा सकता है, और approve, reject या respond किया जा सकता है
• Non-interactive flow में नए approvals दिखाए नहीं जा सकते, इसलिए approval माँगने वाले tasks fail हो जाते हैं और error ऊपर वाले workflow तक पहुँचता है
• Child agent बनाते समय parent turn के live runtime overrides दोबारा लागू होते हैं: जैसे /approvals बदलाव या --yolo जैसी interactive settings
  • भले ही चुनी गई custom agent file में अलग defaults सेट हों, parent की settings को प्राथमिकता मिलती है
• हर custom agent के लिए sandbox settings को अलग से override किया जा सकता है, जैसे किसी खास agent को read-only mode देना

Custom agents

• Codex में default रूप से built-in agents के 3 प्रकार दिए गए हैं
  • default: सामान्य उपयोग का fallback agent
  • worker: implementation और fixes पर केंद्रित execution-oriented agent
  • explorer: codebase exploration के लिए read-oriented agent
• Custom agents परिभाषित करने के लिए ~/.codex/agents/ (personal) या .codex/agents/ (project scope) में अलग TOML files जोड़ी जाती हैं
• हर file एक custom agent को परिभाषित करती है, और Codex इसे creation session की configuration layer के रूप में load करता है
• सभी custom agent files में ये required fields होना अनिवार्य है:
  • name, description, developer_instructions
• Optional fields जैसे nickname_candidates, model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config आदि छोड़ने पर parent session से inherit होते हैं

Global settings

• Subagents की global settings configuration file के [agents] section में परिभाषित होती हैं
• agents.max_threads: एक साथ खुले agent threads की ऊपरी सीमा (default 6)
• agents.max_depth: बने हुए agents की nesting depth (default 1, यानी केवल direct child agents की अनुमति, उससे गहरी nesting रोकी जाती है)
• agents.job_max_runtime_seconds: spawn_agents_on_csv jobs में प्रति worker default timeout (अगर unset हो तो प्रति call default 1800 seconds)
• अगर किसी custom agent का नाम explorer जैसे built-in agent से समान हो, तो custom agent को प्राथमिकता मिलती है

Custom agent file schema

• name (string, required): agent का नाम जिसे Codex agent को बनाते या refer करते समय इस्तेमाल करता है
• description (string, required): Codex को यह बताने वाला human-facing guide कि इस agent का उपयोग कब करना चाहिए
• developer_instructions (string, required): agent के व्यवहार को परिभाषित करने वाले मुख्य निर्देश
• nickname_candidates (string[], optional): बने हुए agent के display nicknames का pool
• config.toml की अन्य supported keys भी शामिल की जा सकती हैं: model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config आदि
• Codex agent की पहचान name field से करता है; filename और agent name को एक जैसा रखना सबसे आसान convention है, लेकिन असल source of truth name field ही है

Display nicknames

• nickname_candidates का उपयोग तब UI में अलग पहचान वाले labels दिखाने के लिए होता है जब एक ही custom agent की कई instances चल रही हों
• Nickname केवल display के लिए होता है; Codex agent की पहचान और creation अब भी name से ही करता है
• Nickname candidates खाली न होने वाली unique names की list होनी चाहिए, और इनमें ASCII letters, numbers, spaces, hyphens और underscores इस्तेमाल किए जा सकते हैं
• उदाहरण: अगर reviewer agent के लिए ["Atlas", "Delta", "Echo"] nicknames सेट किए जाएँ, तो app और CLI में nicknames दिखेंगे, लेकिन base agent type reviewer ही रहेगा

उदाहरण 1: PR review pattern

• Review को तीन विशेषीकृत custom agents में बाँटने का pattern
  • pr_explorer: codebase को map करने और evidence इकट्ठा करने वाला read-only agent (model: gpt-5.3-codex-spark, reasoning effort: medium)
  • reviewer: correctness, security और test risk ढूँढने वाला PR reviewer (model: gpt-5.4, reasoning effort: high)
  • docs_researcher: dedicated MCP server के ज़रिए framework या API documentation verify करने वाला docs specialist (model: gpt-5.3-codex-spark, read-only)
• Project settings: max_threads = 6, max_depth = 1
• pr_explorer के instructions: exploration mode बनाए रखना, असली execution paths trace करना, files और symbols को cite करना, और जब तक parent agent न कहे fix suggestions देने से बचना
• reviewer के instructions: owner के नज़रिए से review करना, correctness, security, behavioral regressions और missing test coverage को प्राथमिकता देना, संभव हो तो reproduction steps शामिल करना, और style-only comments से बचना जब तक वे असली bug को न छिपा रहे हों
• docs_researcher के instructions: docs MCP server से API, options और version-specific behavior verify करना, और links या सटीक references के साथ संक्षिप्त जवाब देना; code changes नहीं करना
• उपयोग उदाहरण prompt: "इस branch का main के साथ comparison review करो। pr_explorer प्रभावित code paths को map करे, reviewer वास्तविक risks ढूँढे, और docs_researcher patch जिन framework APIs पर निर्भर है उन्हें verify करे"

CSV batch processing: spawn_agents_on_csv (experimental)

• यह experimental feature है और भविष्य में बदल सकता है
• जब बहुत सारे मिलते-जुलते tasks हों, तो CSV की एक row को एक task unit मानकर worker subagents bulk में बनाए जा सकते हैं
• Codex CSV पढ़ता है, हर row के लिए worker agent बनाता है, पूरे batch के पूरा होने का इंतज़ार करता है, और फिर results को CSV में export करता है
• उपयुक्त use cases:
  • हर row में दिए गए file, package या service का review
  • incidents, PRs या migration targets की list की जाँच
  • बड़ी संख्या में मिलते-जुलते inputs के लिए structured summaries बनाना
• Tool input parameters: csv_path (source CSV), instruction (worker prompt template, जिसमें {column_name} placeholder इस्तेमाल होता है), id_column (stable item ID), output_schema (fixed JSON shape), output_csv_path, max_concurrency, max_runtime_seconds
• हर worker को report_agent_job_result ठीक एक बार call करना होता है; result report किए बिना खत्म होने पर उस row को error के रूप में चिह्नित किया जाता है
• codex exec से चलाने पर batch के दौरान stderr में एक-पंक्ति progress updates दिखाई जाती हैं
• Export की गई CSV में original row data के साथ job_id, item_id, status, last_error, result_json जैसी metadata भी शामिल होती है
• संबंधित runtime settings: agents.max_threads (concurrent threads limit), agents.job_max_runtime_seconds (प्रति worker timeout; प्रति-call max_runtime_seconds को प्राथमिकता), sqlite_home (agent jobs और export results के लिए इस्तेमाल होने वाला SQLite state storage path)

उदाहरण 2: Frontend integration debugging pattern

• UI regressions, flaky browser flows, और application code तथा running product को एक साथ प्रभावित करने वाले integration bugs के लिए उपयोगी pattern
• तीन custom agents का संयोजन:
  • code_mapper: संबंधित frontend और backend code paths ढूँढने वाला read-only exploration agent (model: gpt-5.3-codex-spark, reasoning effort: medium)
  • browser_debugger: browser tools से issue reproduce करके evidence capture करने वाला UI debugger (model: gpt-5.4, reasoning effort: high, sandbox: workspace-write)
    • screenshots, console output और network evidence के लिए browser tools का उपयोग, लेकिन application code edit नहीं करना
    • Chrome DevTools MCP server connection (http://localhost:3000/mcp, startup_timeout_sec: 20)
  • ui_fixer: issue समझ आने के बाद छोटा और targeted fix करने वाला implementation-focused agent (model: gpt-5.3-codex-spark, reasoning effort: medium)
    • सबसे छोटा defensible change करना, unrelated files को न छूना, और सिर्फ बदले गए behavior को validate करना
• उपयोग उदाहरण prompt: "जाँचो कि settings modal save क्यों नहीं कर रहा। browser_debugger reproduction करे, code_mapper संबंधित code path trace करे, और ui_fixer failure mode समझने के बाद न्यूनतम fix implement करे"