# Claude Code के 29 Tools बनाम Codex के 7 Tools: Design Philosophy बिल्कुल उलट है > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/hi/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ > Reading time: 9 minutes > Language: hi > Tags: claude-code, codex, ai-agents, developer-tools, ai-coding, security ## Canonical https://tonylee.im/hi/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Rollout Alternates en: https://tonylee.im/en/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ko: https://tonylee.im/ko/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ja: https://tonylee.im/ja/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-CN: https://tonylee.im/zh-CN/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ zh-TW: https://tonylee.im/zh-TW/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Description मैंने दोनों tools के SDK type definitions और system prompts को खंगाला। 29 बनाम 7 का अंतर feature count का नहीं है। यह उसी सवाल के दो बुनियादी तौर पर अलग जवाब हैं: एक AI coding agent को आपके system के साथ कैसे interact करना चाहिए? ## Summary Claude Code के 29 Tools बनाम Codex के 7 Tools: Design Philosophy बिल्कुल उलट है is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - Tool Granularity एक Security का फैसला है - Skill Deployment Ecosystem को अलग करता है - Session Diagnostics वह जगह है जहां असली फर्क दिखता है - Team Architectures अलग-अलग assumptions से शुरू होते हैं - Hook Granularity Automation की गहराई तय करती है - Architecture चुनें, Feature List नहीं ## Content Claude Code और Codex दोनों के weekly updates को track करते-करते थक गया था, तो मैं first principles पर वापस गया। मैंने हर SDK type definition, हर system prompt, हर settings schema खोला जो मुझे मिल सका। मैं यह समझना चाहता था कि हर tool क्या करता है, बल्कि यह भी कि tool counts इतने नाटकीय रूप से क्यों अलग हैं। Claude Code 29 tools expose करता है। Codex 7 tools। यह ratio मुझे परेशान करता रहा, क्योंकि यह महज़ एक feature gap नहीं हो सकता। दो well-funded teams जिनमें top-tier engineers हों, वे गलती से 4:1 के ratio पर नहीं पहुंचतीं। यह अंतर जानबूझकर है, और इसके पीछे की सोच दो genuinely अलग philosophies को उजागर करती है कि AI को आपके development environment के साथ कैसे interact करना चाहिए। ## Tool Granularity एक Security का फैसला है सबसे striking अंतर यह है कि हर tool file operations को कैसे handle करता है। Claude Code file manipulation को चार अलग tools में बांटता है: Read, Write, Edit, और MultiEdit। Search को भी अपने dedicated tools मिलते हैं, Grep और Glob पूरी तरह Bash से independent हैं। इसका मतलब है कि आप `settings.json` को इस तरह configure कर सकते हैं कि Read allow हो लेकिन Write block हो। आप agent को अपना codebase search करने दे सकते हैं बिना उसे कोई file modify करने की permission दिए। Permission control tool level पर होता है। Codex अलग रास्ता लेता है। यह agent को core primitives के रूप में `shell`, `apply_patch`, और `file_read` देता है। बाकी सब कुछ shell से होकर जाता है। Files search करना है? वह एक shell command है। Directories list करनी हैं? फिर shell। Security tool-level permissions से नहीं बल्कि `execpolicy` rules से आती है जो specific shell commands के खिलाफ pattern-match करते हैं, उन्हें allow, prompt, या block categories में classify करते हैं। कोई भी approach गलत नहीं है। Claude Code का model आपको fine-grained locks देता है लेकिन एक बड़ी tool surface बनाए रखने की जरूरत होती है। Codex का model reason करने में आसान है लेकिन security enforcement को shell commands पर string-matching में धकेल देता है, जो तब नाजुक हो जाता है जब commands creative हो जाती हैं। मैंने ऐसे cases देखे हैं जहां एक well-crafted pipe chain उस execpolicy rule को bypass कर देती है जो उसी command के straightforward version के लिए लिखी गई थी। पूरा breakdown: - Claude Code (29 tools): 4 file tools (Read/Write/Edit/MultiEdit), 3 search tools (Glob/Grep/LS), 2 web tools, 3 cron tools, 4 MCP tools, Bash, और अन्य - Codex (7 tools): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl ## Skill Deployment Ecosystem को अलग करता है दोनों tools ने Agent Skills open standard को adopt किया, जहां एक single `SKILL.md` file एक skill का behavior define करती है। Structure identical है। Distribution model नहीं है। Codex ने एक centralized distribution system बनाया। `$skill-installer` चलाने से OpenAI की official skills repository से curated skills pull होती हैं। GitHub URL pass करें और third-party skills भी install हो सकती हैं। `$skill-creator` भी है जो conversation के जरिए नई skills interactively generate करता है। Experience npm जैसा लगता है: एक command, एक registry, instant availability। Claude Code दूसरी दिशा में गया। आप `SKILL.md` files को `.claude/skills/` में manually बनाते हैं, या `/plugin marketplace add` के जरिए git repositories से bundles install करते हैं। कोई single official registry नहीं है। Skills community repos, shared links, और word of mouth से discover होती हैं। शुरू में मुझे Codex का centralized model बेहतर लगा क्योंकि discoverability अच्छी है। लेकिन कई हफ्तों तक दोनों use करने के बाद, decentralized approach का एक genuine फायदा है: मैं session के बीच में ही एक skill file edit कर सकता हूं और बिना restart किए changes तुरंत apply हो जाते हैं। Codex की installed skills के साथ, changes के लिए reinstallation चाहिए। जब आप एक custom workflow पर iterate कर रहे होते हैं, तो यह अंतर उतना ज़्यादा मायने रखता है जितना मैंने expect किया था। एक नज़र में comparison: - Invocation: Claude Code `/skill-name` use करता है, Codex `$skill-name` - Storage: `.claude/skills/` बनाम `.agents/skills/` - Built-in skills: Claude Code `/simplify`, `/batch`, `/loop`, `/claude-api` ship करता है; Codex `$skill-installer`, `$skill-creator` ship करता है - Distribution: Decentralized marketplace बनाम centralized repository ## Session Diagnostics वह जगह है जहां असली फर्क दिखता है दोनों tools basics share करते हैं: `/model`, `/plan`, `/review`, `/clear`, `/fast`। अंतर session introspection में आता है। Claude Code ने आपको यह समझने देने में भारी निवेश किया है कि आपके session के अंदर क्या हो रहा है। `/compact` manually context compression trigger करता है। `/context` दिखाता है कि क्या load है। `/cost` real time में token spend track करता है। `/doctor` configuration problems diagnose करता है। `/rewind` पिछली conversation state पर वापस ले जाता है। `/insights` एक महीने के usage patterns analyze करता है और improvements suggest करता है। `/usage` sessions में cumulative consumption दिखाता है। यह सात commands हैं जो पूरी तरह session state को समझने और manage करने के लिए dedicated हैं। Codex ने अपना focus कहीं और रखा। `/personality` agent की communication style adjust करता है। `/theme` visual appearance बदलता है। `/apps` connected applications manage करता है। ये UX customization features हैं, diagnostic tools नहीं। यह एक गहरे philosophical split को दर्शाता है। Claude Code session को कुछ ऐसा मानता है जिसे आपको actively monitor और steer करना चाहिए। Codex इसे कुछ ऐसा मानता है जो background में बस काम करना चाहिए जबकि आप experience को customize करने पर focus करें। महीनों के use के बाद, मुझे दोनों चाहिए। Diagnostics मुझे तब बचाते हैं जब कोई session गड़बड़ा जाता है, लेकिन मुझे detailed architecture work और quick bug fixes के बीच switch करते समय personality adjust करने की क्षमता भी अच्छी लगती है। - Claude Code (~35 commands + 4 bundled skills): session diagnostics पर heavy जैसे `/compact`, `/context`, `/cost`, `/doctor`, `/rewind`, `/insights`, `/usage` - Codex (~19 commands): UX customization में stronger जैसे `/personality`, `/theme`, `/copy`, `/apps`, `/skills`, `/agent`, `/tools` ## Team Architectures अलग-अलग assumptions से शुरू होते हैं Multi-agent collaboration को हर tool कैसे handle करता है, शायद यही सबसे गहरा design difference reveal करता है। Claude Code के Agent Teams peer-to-peer communication use करते हैं। Teammates एक lead agent के जरिए route किए बिना सीधे एक-दूसरे को messages भेजते हैं। वे एक task list share करते हैं और autonomously coordinate करते हैं। आप 2 से 16 agents run कर सकते हैं, और वे आपस में negotiate करेंगे कि कौन क्या handle करेगा। मैंने एक refactoring task पर तीन agents के साथ यह test किया, और token consumption उसी काम को करने वाले एक single session से 3 से 7 गुना ज़्यादा था। Coordination overhead वास्तविक है। लेकिन जब task genuinely parallel exploration से benefit करता है (जैसे एक race condition debug करना जहां आप agents को एक साथ अलग-अलग hypotheses probe करते देखना चाहते हैं), तो P2P model जवाब ज़्यादा तेज़ी से ढूंढता है। Codex एक hub-spoke model use करता है। Child agents केवल parent को report करते हैं। कोई lateral communication नहीं है। `spawn_agents_on_csv` command एक CSV file से bulk में agents create करता है, जो embarrassingly parallel tasks के लिए optimized है जहां काम की हर unit independent है। सोचिए: "इस migration को 200 files पर apply करो" या "इस list के हर endpoint के खिलाफ यह check run करो।" P2P universally बेहतर नहीं है। मैंने एक straightforward batch task पर significant tokens waste किए क्योंकि Claude Code के agents एक-दूसरे के साथ अपने overlapping काम के बारे में बात करते रहे। Codex का hub-spoke उस particular job के लिए सही choice होता। - Claude Code: shared task list के साथ P2P messaging, 2 से 16 agents, tmux split-pane support - Codex: Hub-spoke architecture, `spawn_agents_on_csv` के जरिए CSV-based bulk agent spawning ## Hook Granularity Automation की गहराई तय करती है Claude Code आपको tool execution को multiple lifecycle points पर intercept करने देता है। `PreToolUse` किसी tool के run होने से पहले fire होता है, जिससे आप call को validate या modify कर सकते हैं। `PostToolUse` बाद में fire होता है, इसलिए आप एक formatter attach कर सकते हैं जो हर file save पर auto-run हो। `Notification` hooks agent communications capture करते हैं। `PreCompact` context compression से पहले fire होता है, जो आपको critical information preserve करने का मौका देता है। HTTP Hooks external URLs पर JSON POST कर सकते हैं, Claude Code को CI pipelines, Slack, या custom dashboards से connect करते हैं। Codex इसे simple रखता है। एक `execpolicy` file जिसमें shell commands पर apply होने वाले allow/prompt/block rules हैं। यही agent behavior control करने की पूरी extensibility surface है। मैंने एक `PostToolUse` hook setup किया जो हर Write operation के बाद Prettier run करता है। इसमें पांच मिनट लगे और formatting-related follow-up prompts की पूरी category खत्म हो गई। इस तरह की surgical automation Codex के model में possible नहीं है, जहां आपको हर prompt में "and run prettier after writing" include करना होगा या इसे एक skill में build करना होगा। लेकिन Codex की simplicity की भी value है। मैंने कभी misconfigured hook से अपना Codex setup accidentally नहीं तोड़ा। Claude Code के साथ मैंने यह दो बार किया है, एक बार PreToolUse hook से जो silently legitimate file reads block कर रहा था और बीस मिनट के confused debugging का कारण बना। - Claude Code: PreToolUse, PostToolUse, Notification, PreCompact, और HTTP Hooks - Codex: तीन levels (allow/prompt/block) के साथ execpolicy rule file ## Architecture चुनें, Feature List नहीं 29 बनाम 7 की तुलना यह नहीं है कि एक tool दूसरे से ज़्यादा capable है। यह उसी design question के दो अलग जवाब हैं: एक AI coding agent को अपनी capabilities को individually controllable units में कितना decompose करना चाहिए? Claude Code कहता है "सब कुछ।" हर operation को अपना tool, अपनी permission surface, अपने hook points मिलते हैं। यह आपको maximum control देता है configuration complexity की कीमत पर। Codex कहता है "केवल essentials।" Core operations को dedicated tools मिलते हैं; बाकी सब policy-based guardrails के साथ shell से होकर जाता है। यह आपको simplicity देता है granularity की कीमत पर। जब मैं किसी दिए गए project के लिए कौन सा tool use करना है यह चुनता हूं, तो feature list से कोई फर्क नहीं पड़ता। जो मायने रखता है वह यह है कि project को fine-grained permission control चाहिए (regulated codebase, अलग-अलग access levels वाले multiple contributors) या lightweight simplicity (solo project, fast iteration, minimal setup)। जिस architecture के ऊपर आप build करते हैं वह बाद के हर workflow decision को shape करती है। ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/hi/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/hi/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/hi/blog/codex-folder-structure-why-config-breaks/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/hi/blog/claude-code-29-vs-codex-7-design-philosophy-comparison/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/hi/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.