چرا راهاندازی Codex با همهی IDEهای دیگر فرق دارد
Claude Code، Cursor، Windsurf و Gemini CLI همه تنظیمات سرور MCP را بهشکل JSON میگیرند، فقط با نام کلیدهای متفاوت داخلش. Codex CLI شرکت OpenAI استثناست: فایل تنظیماتش TOML است، و یک قطعهی JSON که عیناً چسبانده شود پارس نمیشود. اگر قبلاً MCP را در ابزار دیگری وصل کردهاید و همان بلوک را در ~/.codex/config.toml کپی کنید، بلافاصله شکست میخورد — نه چون URL یا کلید اشتباه است، بلکه چون فرمت فایل اشتباه است.
تنظیمات واقعی: ~/.codex/config.toml
[mcp_servers.wkfgo]
url = "https://YOUR_INSTANCE/api/mcp"
http_headers = { "Authorization" = "Bearer wk_YOUR_KEY" }
همین کل بلوک است. mcp_servers.wkfgo یک سرتیتر جدول است — هرچه زیرش تا سرتیتر بعدی [...] بیاید، متعلق به همین سرور است. کلید wk_… را از Settings → Integrations → Connect your AI IDE در ویکیافگو بگیرید؛ این یک کلید شخصی محدود به FeatureAccess خودتان است، نه یک اعتبار ادمین برای اشتراک در کل تیم.
اولین فراخوانی
codex را در پوشهی پروژه اجرا کنید و مستقیم از ابزار بخواهید:
«list_tasks را صدا بزن و تسکهای تخصیصدادهشده به من در پروژهی Backend را نشان بده.»
اگر Codex گزارش داد هیچ ابزار wkfgoای در دسترس نیست، دلیل معمول یک خطای نحوی TOML است — یک نقلقول جاافتاده یا یک کاما اضافهی کپیشده از مثال JSON کافی است کل فایل پارس نشود، که بیصدا هر سروری تعریفشده در آن را حذف میکند، نه فقط همین یکی. پیش از فرضکردن اینکه سمت ویکیافگو خراب است، فایل را با یک linter توآلامال اعتبارسنجی کنید.
این کجای یک جریان کاری ترمینالمحور جا میگیرد
مدل Codex CLI با یک پنل چت داخل ادیتور فرق دارد — به یک عامل اسکریپتشده نزدیکتر است که یک تسک نشانش میدهید و میگذارید اجرا شود. این تعیین میکند کدام ابزارهای ویکیافگو بیشتر اهمیت دارند:
get_context_packدر ابتدای جلسه، تا Codex قبل از تغییر فایلها معیار پذیرش را داشته باشد، نه بعدش.update_progressدر نقاط طبیعی توقف — یک جلسهی ترمینالی بدون بورد قابلمشاهده یعنی پیشرفت نامرئی است مگر چیزی گزارشش کند.submit_for_reviewدر پایان، تا یک اجرای کاملاً بدونناظر هم یک رد قابلبازبینی بگذارد، نه فقط یک diff و یک شانهبالاانداختن.
الگویی مفید برای جلسات طولانیتر بدون ناظر: شروع با get_task برای گرفتن توضیح کامل و کامنتها، نه فقط عنوان — جلسات Codex CLI معمولاً بین توقفهای انسانی طولانیتر از یک IDE با پنل چت اجرا میشوند، پس پرکردن زمینه از قبل اینجا بیشتر از Cursor یا Windsurf اهمیت دارد.
اشتباهات رایج
چسباندن JSON در یک فایل TOML. این رایجترین شکست است و هیچ خطای مفیدی از سمت ویکیافگو تولید نمیکند — فایل بهسادگی پارس نمیشود. بلوک TOML بالا را کپی کنید، نه یک بلوک JSON از مستندات IDE دیگر.
فراموشکردن نقلقول دور مقدار سرتیتر. http_headers = { "Authorization" = "Bearer ..." } نیاز دارد کلیدهای داخلی هم نقلقولدار باشند؛ جدولهای درونخطیِ TOML در این مورد از JSON سختگیرترند.
اجرای جلسات طولانی بدونناظر بدون get_context_pack اول. مدلی که بدون معیار پذیرش شروع به ویرایش میکند کدی مینویسد که بهنظر قابلقبول میآید اما با آنچه تسک واقعاً خواسته یکی نیست — هزینهی این عدمتطابق در یک جلسهی ترمینالیِ بدونناظر بیشتر از یک چت تعاملی است که یک انسان میتواند وسط راه مسیر را عوض کند.
سؤالات متداول
آیا Codex CLI برای بهروزرسانی واقعی تسکها به دسترسی نوشتن نیاز دارد، یا فقط میتواند بخواند؟ هر دو همان یک اتصالاند — آنچه کلید میتواند انجام دهد را FeatureAccess روی پروژه تعیین میکند، مثل یک ورود انسانی. اگر میخواهید Codex اول فقط ناظر باشد، با یک نقش فقطخواندنی شروع کنید.
آیا سرور MCP بین Codex، Cursor و Claude Code فرق دارد؟
نه — برای هر کلاینت همان نقطهپایانی /api/mcp و همان فهرست ابزار است؛ فقط فرمت فایل تنظیمات بین IDEها فرق دارد.
میتوانم Codex را روی یک نمونهی self-hosted ویکیافگو اجرا کنم؟
بله، url در TOML به نقطهپایانی /api/mcp نمونهی شما اشاره میکند — ابری یا self-hosted برای Codex فرقی ندارد.