نصب

Control Center به دو شکل اجرا می‌شود: به‌صورت یک برنامهٔ وب در app.usectrl.dev، بدون چیزی برای دانلود، یا به‌صورت یک برنامهٔ رومیزی که نصب می‌کنید. هر دو یک برنامه با همان قابلیت‌ها هستند. تنها تفاوت این است که سرور کجا اجرا می‌شود — و برنامهٔ وب نمی‌تواند یکی برایتان اجرا کند.

استفاده از آن در مرورگرتان

app.usectrl.dev همین برنامه است که برای مرورگر کامپایل شده. چیزی برای نصب، چیزی برای به‌روزرسانی. بازش کنید و متصل شوید.

کاری که یک تب مرورگر نمی‌تواند بکند بودنِ سرور است. هر کلاینت — رومیزی، وب، تلفن — یک رندرکنندهٔ نازک روی یک cc_server بدون رابط است که مالک پایگاه داده است و کار را انجام می‌دهد، پس برنامهٔ وب همیشه با سروری که شما اجرا می‌کنید حرف می‌زند. دو راه برای دادن یکی به آن هست:

یک سرور روی ماشین خودتان. cc_server را به‌صورت محلی اجرا کنید و برنامهٔ وب را به ws://localhost:9030 نشانه بگیرید. مرورگرها localhost را قابل‌اعتماد می‌دانند، پس این به گواهی و تونل نیازی ندارد. سریع‌ترین راه امتحان برنامهٔ وب است و داده‌هایتان هرگز ماشینتان را ترک نمی‌کند.

یک سرور روی ماشینی دیگر. چون app.usectrl.dev از روی HTTPS سرو می‌شود، یک سرور غیرمحلی باید از راه wss:// و با گواهی‌ای که مرورگر از قبل به آن اعتماد دارد قابل‌دسترس باشد. cc_server از بایند کردن نشانی غیرلوپ‌بک بدون TLS سر باز می‌زند، پس یکی از این‌ها را انتخاب کنید:

• مستقیماً به آن گواهی بدهید، با --tls-cert و --tls-key
• آن را پشت یک پروکسی معکوس پایان‌دهندهٔ TLS بگذارید و با --insecure اجرا کنید
• آن را از راه یک تونل یا VPN که گواهی را تأمین می‌کند در دسترس بگذارید — Tailscale، cloudflared یا مشابه. تنظیمات → سرور → اتصال و وضعیت انتخاب تونل داخلی را تحت اشتراک این سرور دارد.

هر زمان سرور پشت پروکسی، NAT یا تونلی می‌نشیند، --public-url را روی نشانی‌ای تنظیم کنید که کلاینت‌ها واقعاً باید بگیرند. مقدار پیش‌فرضش بایند محلی است، پس بدون آن کلاینت‌ها میزبان اشتباه را امتحان می‌کنند.

نسخهٔ خودتان از کلاینت وب را میزبانی می‌کنید؟

cc_server مبدأهای مرورگر را فقط روی فهرست --allowed-origins خود می‌پذیرد که مقدار پیش‌فرضش https://app.usectrl.dev است. اگر ساخت وب را خودمیزبان می‌کنید، مبدأ خودتان را آنجا اضافه کنید. کلاینت‌های لوپ‌بک و بومی صرف‌نظر از آن فهرست همیشه مجازند.

چند چیز فقط مخصوص رومیزی می‌ماند، چون به پنجرهٔ بومی یا دستگاه‌های صوتی خودِ ماشین نیاز دارند: قرص شناور حالت تمرکز، اعلان‌های بازشوی سیستم‌عامل (مرکز اعلان درون‌برنامه‌ای همه‌جا کار می‌کند)، «شروع ضبط و پیوند» از یک رویداد تقویم، و اجرای دوبارهٔ خلاصهٔ یک جلسه. همه‌چیز دیگر — فضاها، عامل‌ها، بازبینی pull request، پایپ‌لاین‌ها، تیکت‌ها، حافظه و خودِ ضبط جلسه — یکسان رفتار می‌کند.

برای اتصال برنامهٔ وب به یک سرور، اتصال به سرور راه دور را دنبال کنید. برای میزبانی سرور، اجرای سرور بدون رابط را دنبال کنید.

نیازمندی‌های سامانهٔ رومیزی

نیازمندی	macOS	Windows	Linux
نسخهٔ سیستم‌عامل	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ یا توزیع دیگری با glibc 2.35+ و GTK 3
معماری	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	لازم	لازم	لازم
فضای دیسک	حدود ۲۰۰ مگابایت برای برنامه، به‌علاوهٔ پوشهٔ دادهٔ سرور	حدود ۲۰۰ مگابایت	حدود ۲۰۰ مگابایت

مک‌های Intel دانلود پیش‌ساخته ندارند. به‌جایش از منبع بسازید.

پوشهٔ دادهٔ سرور از خود برنامه بزرگ‌تر می‌شود. cc_server در نخستین اجرا مدل‌های روی دستگاه را به‌زور نصب می‌کند — امبدینگ متنی (حدود ۹۰ مگابایت)، تفکیک گوینده (حدود ۳۵ مگابایت) و مدل گفتار انتخاب‌شده (به‌طور پیش‌فرض Parakeet TDT v3، حدود ۶۰۰ مگابایت؛ گونه‌های Whisper ۱۹۸–۶۲۶ مگابایت) — به‌علاوهٔ یک نسخهٔ تعبیه‌شدهٔ code-server، و هر گفتگوی عامل یک worktree کپی‌روی-نوشتن از مخزن‌هایی که رویشان کار می‌کند می‌گیرد (git worktree ساده روی Windows). گفتار اختیاری نیست: بدون مدل ASR، عملیات جلسه و دیکته سرو نمی‌شود. نخستین دانلود مدل گفتار هنوز پیش از روشن‌شدن ضبط به یک راه‌اندازی دوباره نیاز دارد.

رومیزی سرورش را به پوشهٔ پشتیبانی برنامهٔ هر کاربر سیستم‌عامل نشانه می‌گیرد. یک cc_server که دستی و بدون --data-dir اجرا شده، به‌طور پیش‌فرض <application data>/control-center است — ~/Library/Application Support/control-center روی macOS، %APPDATA%\control-center روی Windows، $XDG_DATA_HOME/control-center (یا ~/.local/share/control-center) روی Linux.

دانلود

هر آرتیفکت زیر از GitHub Releases می‌آید.

macOS (Apple Silicon)

Control-Center-<version>-arm64.dmg را دانلود کنید، بازش کنید و Control Center را به Applications بکشید. ساخت با یک Developer ID امضا و توسط Apple تأیید شده است، پس به‌طور عادی باز می‌شود.

Windows (x64, ARM64)

• Control-Center-<version>-x64-setup.exe: یک نصب‌کنندهٔ هر کاربر.
• Control-Center-<version>-windows-x64.zip: یک zip قابل حمل.
• Control-Center-<version>-arm64-setup.exe: یک نصب‌کنندهٔ هر کاربر.
• Control-Center-<version>-windows-arm64.zip: یک zip قابل حمل.

Windows برای واکشی‌های فضا از git worktree استفاده می‌کند (بدون copy-on-write).

Linux (x86_64)

• Control-Center-<version>-x86_64.AppImage
• Control-Center-<version>-linux-x64.tar.gz

AppImage اطلاعات به‌روزرسانی را همراه دارد، پس AppImageUpdate یا appimaged می‌تواند آن را در جا به آخرین انتشار برساند و فقط چیزهای تغییرکرده را دانلود کند.

هر دو روی Ubuntu 22.04 ساخته شده‌اند و روی آن یا هر چیز تازه‌تر اجرا می‌شوند (Debian 12، Fedora 36 و بعدتر): به glibc 2.35 و libstdc++ مربوط به GCC 12 پیوند می‌خورند و GTK 3 را از سیستم می‌گیرند. چند کتابخانهٔ معدودی که ممکن است یک رومیزی استاندارد نداشته باشد داخلشان سفر می‌کند، پس چیز دیگری نیازی به نصب ندارد. صدا — پخش جلسه، منظرهٔ صوتی، صدای ریگ و زنگ‌های اعلان — از راه libmpv سیستم پخش می‌شود (libmpv1 روی Ubuntu 22.04، libmpv2 روی Ubuntu و Debian تازه‌تر، mpv-libs روی Fedora)؛ بدون آن برنامه با پنهان‌بودن آن کنترل‌ها شروع می‌شود.

سرور مستقل

هر انتشار سرور بدون رابط را هم جداگانه همراه دارد — cc_server-<version>-macos-arm64.tar.gz، cc_server-<version>-linux-x64.tar.gz، cc_server-<version>-windows-x64.zip، cc_server-<version>-windows-arm64.zip — در کنار ایمیج‌های cc-server، cc-webapp و cc-remote روی GHCR. به اجرای سرور بدون رابط نگاه کنید.

بایگانی Linux روی Ubuntu 22.04 ساخته شده و کتابخانه‌های بومیِ همراه آن به glibc 2.35 و libstdc++ مربوط به GCC 12 پیوند می‌خورند، پس به میزبانی دست‌کم به همان تازگی نیاز دارد (Ubuntu 22.04، Debian 12، Fedora 36 یا بعدتر). روی یک توزیع قدیمی‌تر به‌جایش ایمیج cc-server را اجرا کنید — یک کانتینر فضای کاربر خودش را همراه می‌آورد، پس فقط کرنل باید از آنِ شما باشد.

بک‌اند عامل

Control Center عامل‌ها را از راه آداپتورها اعزام می‌کند. دو تا از آن‌ها هست، فهرست ثابت است و خودکار شناسایی می‌شوند — راهی برای ثبت یکی دیگر وجود ندارد.

آداپتور Control Center (built-in) به CLI بیرونی نیازی ندارد: حلقهٔ عامل درون سرور اجرا می‌شود و از راه HTTP با ارائه‌دهندگان مدل حرف می‌زند، پس همیشه در دسترس است. یک ارائه‌دهنده را تحت تنظیمات → سرور → ارائه‌دهندگان مدل وصل کنید. OpenAI، Codex، Cursor و Kimi Code ورود از مرورگر ارائه می‌دهند؛ Anthropic، OpenRouter، Google Gemini، DeepSeek، Mistral، xAI، z.ai و Moonshot کلید API می‌گیرند. Codex و Cursor ارائه‌دهنده‌هایی روی این اجراکننده‌اند، نه CLI جداگانه. z.ai عمداً دو بار فهرست شده است: z.ai پلتفرم باز پرداخت‌به‌ازای‌مصرف است که از موجودی حساب شما کسر می‌شود، در حالی که z.ai GLM Coding Plan اشتراک است. کلید حساب یکی است، اما z.ai این طرح را از میزبانی دیگر سرو می‌کند — یک کلید طرح کدنویسی را در کاشی سادهٔ z.ai جای‌گذاری کنید و هر درخواست با 429 … "Insufficient balance or no resource package" برمی‌گردد، چون طرح موجودی‌ای برای خرج‌کردن ندارد. اشتراک Claude Pro/Max ورود API مربوط به Anthropic نیست؛ به‌جایش آن طرح را از راه آداپتور Claude Code به‌دست آورید. آنچه می‌توانید در آن صفحه اضافه کنید یک ارائه‌دهندهٔ سفارشی است — هر نقطهٔ پایانی سازگار با OpenAI یا Anthropic (Ollama، LM Studio، vLLM، یک استقرار خصوصی) تحت ارائه‌دهندگان سفارشی → افزودن ارائه‌دهنده.

آداپتور دیگر یک CLI بیرونی را بسته‌بندی می‌کند:

• Claude Code (claude): npm install -g @anthropic-ai/claude-code

شناسایی، PATH ماشینی را که cc_server را اجرا می‌کند می‌کاود — همان ماشین وقتی رومیزی سرور خودش را اجرا می‌کند، وگرنه میزبان راه دور. CLI مربوط به Claude Code را آنجا نصب کنید، نه روی کلاینت. دکمهٔ تازه‌سازی در آن صفحه کاوش را دوباره اجرا می‌کند.

فهرست‌های مدل به‌صورت زنده توسط هر ارائه‌دهندهٔ متصل سرو می‌شوند؛ models.dev فقط فرادادهٔ قیمت و پنجرهٔ بافت را تأمین می‌کند. به مدیریت آداپتورها و مدل‌ها نگاه کنید.

احراز هویت GitHub

اعتبارنامهٔ GitHub از آنِ شماست و روی سرور زندگی می‌کند، با شناسهٔ کاربری شما کلید شده — نه در جاکلیدی سیستم‌عامل کلاینت. هر دستگاهی که از آن وارد می‌شوید همان را به کار می‌برد و هیچ عضو دیگری نمی‌تواند آن را بخواند.

اگر سرور یک GitHub App ثبت‌شده داشته باشد (ایجاد GitHub App)، تنظیمات → فضای کاری → نمایه و هویت → میزبانی کد گزینهٔ ورود با GitHub را ارائه می‌دهد (یک جریان دستگاه که سرور اجرا می‌کند). در غیر این صورت یک توکن دسترسی شخصی جای‌گذاری کنید:

• کلاسیک: repo و read:org
• ریزدانه: Contents و Pull requests (خواندن و نوشتن)، Checks و Actions (خواندن)

یکی در GitHub → Settings → Developer settings → Personal access tokens بسازید. سرور توکن را همان‌گونه که ذخیره شده برای نام حساب می‌کاود، پس ردیف می‌تواند «واردشده به‌عنوان …» بگوید؛ کاوش ناموفق باز هم توکن را ذخیره می‌کند و یک غلط تایپی یا دامنهٔ ناموجود بعداً به‌صورت یک درخواست ناموفق ظاهر می‌شود.

نخستین گام آنبردینگ همین اتصال است. بعد از آن، همان کارت جایی است که آن را جایگزین یا پاک می‌کنید. GitLab و Bitbucket از همان کارت استفاده می‌کنند؛ به اتصال میزبان کد نگاه کنید.

انتخاب کنید سرور کجا اجرا شود

Control Center یک کلاینت نازک روی فرایند cc_server بدون رابط است که مالک پایگاه داده است و همهٔ کار را انجام می‌دهد؛ استقرار و کلاینت‌ها توضیح می‌دهد این تفکیک برای رومیزی، وب و تلفن چه معنایی دارد.

رومیزی در نخستین اجرا می‌پرسد «Control Center چطور اجرا شود؟»:

• اجرا در این برنامه: رومیزی یک cc_server روی این ماشین می‌زاید و نظارت می‌کند و از راه لوپ‌بک با آن حرف می‌زند. چیز دیگری برای پیکربندی نیست. این همان راه‌اندازی‌ای است که شروع سریع فرض می‌گیرد.
• اتصال به یک نمونهٔ راه دور: رومیزی را با نشانی WebSocket آن، یک شناسهٔ دستگاه، و یا یک کلید جفت‌سازی یا یک کد دعوت یک‌بارمصرف به یک cc_server که جای دیگر اجرا می‌شود نشانه بگیرید. آن سرور مالک داده است؛ این رومیزی فقط آن را رندر می‌کند.

سرورها را بعداً تحت تنظیمات → سرور → اتصال و وضعیت اضافه یا عوض کنید. عوض‌کردن در جا دوباره وصل می‌شود — بدون راه‌اندازی دوباره. یک مرورگر نمی‌تواند سروری اجرا کند، پس کلاینت وب همیشه راه دور است؛ به اتصال به سرور راه دور نگاه کنید.

برای میزبانی خودتان سرور، اجرای سرور بدون رابط را دنبال کنید. ساخت باینری، ضرب یک کلید جفت‌سازی پیش از نخستین اجرا و پرچم‌های --data-dir / --port / --bind را پوشش می‌دهد.

راه‌اندازی خود را بررسی کنید

1. تنظیمات → سرور → ارائه‌دهندگان مدل هر دو آداپتور را فهرست می‌کند. ورودی «Control Center (built-in)» با نسخهٔ built-in «یافت‌شده» نمایش داده می‌شود؛ ورودی Claude Code در صورتی «یافت‌شده» نمایش داده می‌شود که CLI آن روی PATH میزبان سرور باشد. اگر نیست، تازه‌سازی را فشار دهید.
2. تنظیمات → فضای کاری → مخزن‌ها مخزن‌های این فضای کاری را فهرست می‌کند و افزودن مخزن پوشه‌های میزبان سرور را مرور می‌کند.
3. تنظیمات → فضای کاری → عامل‌ها پنج عاملی که نخستین فضای کاری‌تان کاشت را فهرست می‌کند. هر یک پیش از آنکه بتواند اجرا شود به یک آداپتور و یک مدل تنظیم‌شده نیاز دارد.
4. تنظیمات → سرور → تشخیص و حریم خصوصی بک‌اندهای سندباکسی که این میزبان ارائه می‌دهد، وضعیت مدل امبدینگ و ثبت وقایع را گزارش می‌دهد.

ساخت از منبع

کتابخانه‌های بومی لازم‌اند و حالت تنزل‌نیافته وجود ندارد: نبودن یکی، شکست سخت در راه‌اندازی است، نه مسیری کندتر. آن‌ها را پیش از هر چیز آماده کنید. هر دستور Flutter و Dart از fvm می‌گذرد، چون نسخهٔ SDK را مخزن پین کرده است.

git clone https://github.com/SamuelAlev/control-center.git
cd control-center
scripts/natives/build_natives.sh
fvm flutter pub get
fvm flutter pub run build_runner build --delete-conflicting-outputs
fvm flutter gen-l10n
fvm flutter run -d macos  # or -d windows, -d linux

روی macOS، ذخیره‌سازی امن (ورود GitHub، Linear و Google) به امضاشدن برنامه توسط یک تیم Apple نیاز دارد — یک Apple ID رایگان کافی است و راه‌اندازی‌ای یک‌باره است که در امضای توسعهٔ محلی توضیح داده شده. بدون آن برنامه باز هم راه می‌افتد؛ فقط ذخیره‌سازی امن در دسترس نیست. Windows و Linux به امضا نیازی ندارند.

برای ساخت باینری سرور بدون رابط، نخست natives را به همان شیوه آماده کنید، سپس:

cd apps/cc_server
fvm dart build cli

قلاب ساخت هر چه از قبل در build/natives/ باشد را به بسته کپی می‌کند، پس ساخت پیش از آماده‌سازی بسته‌ای بدون natives و سروری پدید می‌آورد که از راه افتادن سر باز می‌زند.

برای کلاینت وب از scripts/build_web.sh استفاده کنید (--target remote برای PWA تلفن). همین است که CI اجرا می‌کند: یک flutter build web ساده مُهر هویت ساخت، بازتولید Web Worker، مانیفست استقرار و بررسی بودجهٔ دارایی را رد می‌کند.