آموزش ارسال پیام بین نشست‌های Claude Code

معنای پیام‌رسانی نشست‌های Claude Code به یکدیگر

دو نشست Claude Code زمانی می‌توانند به یکدیگر پیام دهند که روی یک ماشین و تحت یک کاربر سیستم‌عامل یکسان اجرا شوند. هر پیام، یک قطعه متن ساده است که یک Claude برای دیگری می‌نویسد. این پیام فاقد تاریخچه گفتگو و فایل است. Claude نشست دیگر را با ابزار ListAgents پیدا کرده و متن را با SendMessage ارسال می‌کند، بنابراین شما هرگز نیازی ندارید این ابزارها را به‌صورت دستی فراخوانی کنید. شما فقط آنچه را که نشست دیگر باید بداند بیان می‌کنید و خود Claude پیام را می‌نویسد.

این قابلیت، پیام‌رسانی بین‌نشستی (cross-session messaging) نامیده می‌شود. از اوت 2026، این قابلیت به Claude Code نسخه 2.1.224 یا بالاتر نیاز دارد و روی macOS و Linux، از جمله Linux در WSL 2 اجرا می‌شود. پشتیبانی بومی برای Windows وجود ندارد و این قابلیت در Amazon Bedrock، Claude Platform روی AWS، پلتفرم Agent گوگل‌کلاد یا Microsoft Foundry در دسترس نیست. هنگامی که یک نشست این پیش‌نیازها را داشته باشد، پیام‌رسانی به‌صورت خودکار فعال است و نیازی به تنظیمات اضافی ندارد. رفتار شرح‌داده‌شده در زیر، برگرفته از مستندات Anthropic برای پیام‌رسانی بین‌نشستی است.

یک VPS جایی است که این موضوع اهمیت پیدا می‌کند، زیرا در VPS نشست‌ها آن‌قدر طولانی‌مدت فعال می‌مانند که ارزش آدرس‌دهی داشته باشند. روی لپ‌تاپ، شما درِ دستگاه را می‌بندید. روی سروری که تحت tmux است، نشستی که دوشنبه شروع کرده‌اید، پنجشنبه همچنان در حال اجراست و کانتکست یک مخزن (repository) را حفظ کرده است. وقتی دو مورد از این نشست‌ها داشته باشید، نحوه ارتباط آن‌ها از حالت تئوری خارج می‌شود. اگر هنوز این مورد را تنظیم نکرده‌اید، با اجرای Claude Code روی VPS تحت tmux شروع کنید که زیرساخت‌های نشست مورد نیاز این راهنما را پوشش می‌دهد.

چه زمانی استفاده از نشست دوم ارزش هزینه را دارد

با هزینه شروع کنید. هر نشست یک نمونه مجزای Claude با پنجره متنی (context window) اختصاصی است، بنابراین هزینه دو نشست تقریباً دو برابر هزینه یک نشست در همان بازه زمانی است. هر پیام ارسالی دقیقاً مانند پرامپتی که تایپ می‌کنید، در محاسبه میزان مصرف لحاظ می‌شود. هماهنگی رایگان نیست و کاری که در واقع یک توالی از مراحل است، با تقسیم شدن بین نشست‌ها کندتر و پرهزینه‌تر می‌شود.

مواردی که نشست دوم در آن‌ها توجیه اقتصادی دارد، ویژگی مشترکی دارند. دو بخش از کار به‌طور هم‌زمان و بدون انتظار برای یکدیگر اجرا می‌شوند و یکی از آن‌ها در میانه کار، اطلاعاتی را به دست می‌آورد که دیگری به آن نیاز دارد.

• یک نشست یک تغییر ناسازگار (breaking change) را پیدا می‌کند، در حالی که نشست دیگر در حال توسعه بر اساس کدی است که تغییر کرده است. Claude تغییر را خلاصه کرده و ارسال می‌کند، به‌جای اینکه شما آن را دوباره در ترمینال دیگر تایپ کنید.
• دو نشست روی یک مخزن (repository) در git worktreeهای جداگانه کار می‌کنند و یکی از آن‌ها باید بداند چه چیزی نهایی شده است.
• یک عملیات طولانی مهاجرت یا اجرای تست، نتیجه خود را به نشستی که در حال نظارت بر آن هستید گزارش می‌دهد.
• یک نشست سازنده (builder) و یک نشست بازبین (reviewer)؛ جایی که بازبین آنچه سازنده تولید کرده را می‌خواند و یافته‌های خود را بازمی‌گرداند.

زمانی که کارها متوالی هستند، یا زمانی که هر دو نشست قرار است فایل‌های یکسانی را ویرایش کنند، از یک نشست استفاده کنید. زمانی که به یک گروه هماهنگ نیاز دارید که Claude آن را در یک وظیفه واحد ایجاد و نظارت کند، از تیم‌های عامل (agent teams) استفاده کنید که قابلیتی جداگانه و همچنان آزمایشی است. زمانی که فقط می‌خواهید همان گفتگو را در ترمینال دیگری داشته باشید، نشست را از سر بگیرید (resume). پیام‌رسانی بین‌نشستی برای نشست‌های مستقلی است که خودتان شروع و هدایت می‌کنید.

پیش از برنامه‌ریزی، از وجود قابلیت اطمینان حاصل کنید

ابتدا نسخه را بررسی کنید:

claude --version

شماره نسخه را با 2.1.224 مقایسه کنید. سپس، در داخل یک نشست (session)، دستور /list-agents را تایپ کنید که با /peers نیز پاسخ می‌دهد. این دستور تمام عامل‌هایی (agent) که این نشست به آن‌ها دسترسی دارد را به همراه نامی که هر کدام با آن پاسخ می‌دهند، چاپ می‌کند. اگر دستور اصلاً شناخته نشد، این نشست از قابلیت پیام‌رسانی بین‌نشستی (cross-session messaging) پشتیبانی نمی‌کند و هیچ فایل تنظیمی این وضعیت را تغییر نخواهد داد. دستور /status را تایپ کنید و به دنبال ردیف Peer address بگردید: این ردیف شامل آدرس صندوق ورودی (inbox) همین نشست است که با uds: پیشوند شده است.

یک دام برای کاربران VPS وجود دارد که به‌طور خاص آن‌ها را درگیر می‌کند. پیام‌رسانی بین‌نشستی به ارزیابی پرچم‌های قابلیت (feature-flag) وابسته است و چندین متغیر حریم خصوصی، این ارزیابی را غیرفعال می‌کنند که باعث می‌شود قابلیت در وضعیت پیش‌فرض «خاموش» باقی بماند. DO_NOT_TRACK، DISABLE_TELEMETRY، CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC و DISABLE_GROWTHBOOK همگی این کار را انجام می‌دهند. کاربران برای امن‌سازی یک سرور تازه، این موارد را در ~/.bashrc کپی می‌کنند و سپس تعجب می‌کنند که چرا /list-agents وجود ندارد. همین مقادیر ممکن است از طریق نقشه env در یک فایل تنظیمات یا از طریق تنظیمات مدیریت‌شده اعمال شوند، بنابراین ابتدا shell را بررسی کنید.

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

هر کدام از این متغیرها که مقداری را چاپ کرد، unset کنید. برای DISABLE_TELEMETRY و CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC، هر مقدار غیرخالی (از جمله رشته 0) این رفتار را فعال می‌کند، بنابراین DISABLE_TELEMETRY=0 آن‌طور که به نظر می‌رسد عمل نمی‌کند. شما باید با unset کردن متغیر یا تنظیم آن روی یک رشته خالی، آن را غیرفعال کنید.

نام‌گذاری نشست‌ها، در غیر این صورت Claude نمی‌تواند آن‌ها را خطاب قرار دهد

Claude پیام را با نام به یک نشست ارجاع می‌دهد. هنگام شروع نشست، نام آن را تعیین کنید:

claude --name builder-api

همچنین می‌توانید این کار را با /rename در حین اجرای یک نشست انجام دهید. اگر نامی تعیین نکنید، Claude Code نامی را از نام پوشهٔ دایرکتوری کاری استخراج می‌کند، مانند myapp-3f. این برای یک نشست مناسب است اما برای چهار نشست گیج‌کننده خواهد بود، و ممکن است دو نشست در نهایت نام یکسانی پیدا کنند. خروجی /list-agents دایرکتوری کاری هر نشست محلی را نشان می‌دهد که باعث تمایز نشست‌های هم‌نام می‌شود، و فهرست خودِ Claude نیز هنگام تداخل نام‌ها، یک شناسهٔ کوتاه به آدرس اضافه می‌کند. نام‌گذاری دستی توسط شما، کم‌هزینه‌تر از خواندن شناسه‌هاست.

یک چیدمان tmux با دو نشست که می‌توانید بازتولید کنید

این یک نشست برای توسعه‌دهنده (builder) و یک نشست برای بازبین (reviewer) روی یک مخزن واحد است. بازبین در یک git worktree جداگانه کار می‌کند، بنابراین این دو هرگز روی یک فایل یکسان نمی‌نویسند. استفاده از git worktree add به همراه HEAD یک checkout جداگانه ایجاد می‌کند که دقیقاً همان چیزی است که برای نشستی که بیشتر می‌خواند تا اینکه commit کند، نیاز دارید.

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

سپس Ctrl+b و w پنجره‌ها را بر اساس نام فهرست می‌کنند تا بتوانید یکی را انتخاب کنید. در پنجره builder، دستور /list-agents را اجرا کنید. باید reviewer-api را با دایرکتوری کاری ~/src/api-review مشاهده کنید. اگر این مورد وجود ندارد، نشست بازبین هنوز راه‌اندازی نشده است یا یکی از دو مشکل بخش بعدی رخ داده است. سپس چیزی را با زبان ساده تحویل دهید:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude خلاصه را می‌نویسد و ارسال می‌کند. شما متن پیام را نمی‌نویسید و آنچه Claude ارسال می‌کند متغیر است. در پنجره بازبین، پیام در گفتگو با نام فرستنده ظاهر می‌شود. اگر آن نشست غیرفعال باشد، Claude بلافاصله یک نوبت جدید در آن شروع می‌کند. اگر در میانه یک نوبت باشد، پیام تا زمان بین فراخوانی ابزارها منتظر می‌ماند، بنابراین دستور در حال اجرا هرگز قطع نمی‌شود. هنگامی که Claude آن را خواند، پیام به یک ردیف Message from تک‌خطی تبدیل می‌شود که Ctrl+O آن را باز می‌کند. این جفت زمانی بهتر کار می‌کند که builder تغییرات خود را کوچک نگه دارد، زیرا یک diff محدود باعث تحویل کوتاه‌تر و بازبینی‌ای می‌شود که نشست دیگر می‌تواند در یک نوبت آن را تمام کند؛ این همان عادتی است که مهارت توسعه‌دهنده ارشد تنبل برای اعمال آن وجود دارد.

چه کسی در یک VPS می‌تواند چه کسی را ببیند

ارسال پیام در یک ماشین واحد، هرگز از سرورهای Anthropic عبور نمی‌کند. هر نشست، فایل‌های ثبت را روی دیسک می‌نویسد و سوکت صندوق ورودی اختصاصی خود را bind می‌کند؛ سپس Claude Code این فایل‌ها را می‌خواند تا نشست‌های دیگر شما را پیدا کند. این موضوع دو پیامد دارد که هر دو در محیط سرور تأثیرگذار هستند.

دسترسی به سوکت، محدود به کاربر سیستم‌عامل شماست. نشستی که با کاربر root شروع کرده‌اید و نشستی که با کاربر deploy آغاز شده است، نمی‌توانند یکدیگر را ببینند؛ حتی اگر در کنار هم در یک سرور tmux باشند، زیرا نشست‌های یک کاربر نمی‌توانند به سوکت کاربر دیگر دسترسی داشته باشند. هر دو نشست را با یک کاربر واحد اجرا کنید.

هر کانتینر فایل‌سیستم مخصوص به خود را دارد. یک نشست داخل Docker و یک نشست روی میزبان (host) نمی‌توانند به یکدیگر دسترسی داشته باشند، زیرا فایل‌های ثبت یکسانی را نمی‌خوانند. دو نشست داخل یک کانتینر می‌توانند به‌طور عادی با یکدیگر پیام رد و بدل کنند. اگر برای ایزوله‌سازی، عامل‌ها (agents) را در کانتینرها نگه می‌دارید، همان‌طور که در اجرای عامل‌های برنامه‌نویسی در یک ماشین مجازی موقت توضیح داده شده است، انتظار داشته باشید که پیام‌رسانی فقط در داخل یک کانتینر کار کند و از مرز کانتینر عبور نکند.

نشست‌های شما در ماشین‌های دیگر و در وب، تنها زمانی در لیست ظاهر می‌شوند که Remote Control متصل باشد و با برچسب مربوطه مشخص می‌شوند. Claude در اینجا فقط می‌تواند به پیامی پاسخ دهد که از یکی از آن نشست‌ها رسیده باشد. او نمی‌تواند خود آغازگر آن تبادل باشد.

چرا پیام شما هرگز نرسید

دلیل معمول این اتفاق هیچ ارتباطی به شبکه ندارد. نشست (session) دریافت‌کننده تصمیم می‌گیرد که با پیام چه کند، و تصمیم بر این بوده که پیام تحویل داده نشود. هر پیام ورودی به یکی از سه نتیجه ختم می‌شود: تحویل داده شده، نگه داشته شده (تا زمانی که شما آن را تأیید کنید، تحویل داده نمی‌شود)، یا رد شده (بدون تحویل حذف می‌شود).

هنگامی که هیچ مقدار crossSessionInbound اعمال نمی‌شود، Claude Code برای هر پیام با مقایسه حالت‌های مجوز دو نشست تصمیم‌گیری می‌کند. این ابزار نشست‌هایی را که از درخواست مجوز عبور می‌کنند (bypass) در یک گروه و سایر نشست‌ها را در گروه دیگر قرار می‌دهد. auto، acceptEdits و dontAsk به عنوان حالت‌های نیازمند پرسش (prompting) محسوب می‌شوند. حالت Plan در نشستی که مجوزهای bypass در دسترس دارد، به عنوان عبور از پرسش شمرده می‌شود. قاعده در اینجا متقارن است:

• نشست دریافت‌کننده‌ای که برای مجوزها پرسش می‌کند، هر پیام را تحویل می‌گیرد. این نشست تنها زمانی پیام را نگه می‌دارد که نشست فرستنده خود را به عنوان عبورکننده از پرسش‌ها معرفی کند.
• نشست دریافت‌کننده‌ای که از پرسش‌ها عبور می‌کند، هر پیام را برای تأیید شما نگه می‌دارد. این نشست تنها زمانی پیام را تحویل می‌دهد که فرستنده نیز در حال عبور از پرسش‌ها باشد.

بنابراین، اولین گردش کاری که اکثر افراد می‌سازند، دقیقاً همان چیزی است که کار نمی‌کند. شما یک builder را با --permission-mode bypassPermissions شروع می‌کنید چون می‌خواهید بدون نظارت اجرا شود، reviewer را روی تنظیمات پیش‌فرض رها می‌کنید، و هر پیامی که builder می‌فرستد در یک پنجره تأیید که کسی آن را نمی‌بیند، منتظر می‌ماند. آن پنجره پس از مهلت dialogExpiry بسته می‌شود که مقدار پیش‌فرض آن 5m است، و پیام حذف می‌شود. در همان ماشین، نشست فرستنده هنگامی که پیامش نگه داشته می‌شود یک اعلان دریافت می‌کند، و زمانی که گیرنده بعداً آن را تحویل می‌دهد، رد می‌کند یا منقضی می‌کند، یک اعلان پیگیری دریافت می‌کند؛ بنابراین پیش از آنکه سوکت را مقصر بدانید، صفحه نمایش فرستنده را بخوانید.

برای اینکه یک نشست پیام‌ها را بدون نظارت دریافت کند، crossSessionInbound را روی accept تنظیم کنید. اینکه کجا آن را تنظیم می‌کنید، تعیین می‌کند که آیا اعمال می‌شود یا خیر. Claude Code ابتدا تنظیمات مدیریت‌شده، سپس فلگ --settings و در نهایت تنظیمات کاربر را می‌خواند و اولین مقداری را که پیدا کند اعمال می‌کند. مقداری که در تنظیمات پروژه یا محلی قرار دارد تنها زمانی اعمال می‌شود که سخت‌گیرانه‌تر باشد، طبق نردبان accept < hold < refuse. یک accept در .claude/settings.json از هر چیزی آزادتر است، بنابراین هر زمان که یک منبع مورد اعتماد مقداری را تعیین کرده باشد، نادیده گرفته می‌شود. آن را در ~/.claude/settings.json قرار دهید، یا برای یک نشست خاص ارسال کنید:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

یک worker بدون رابط کاربری (headless) claude -p، یک سوکت ورودی را مانند یک نشست تعاملی bind می‌کند و در لیست ظاهر می‌شود، اما نمی‌تواند پنجره تأیید را نمایش دهد. پیام نگه داشته شده در آنجا تا زمانی که تغییر حالت یا تنظیمات بعدی اجازه ندهد، در همان وضعیت باقی می‌ماند. خط --settings در بالا روشی است که به چنین worker اجازه می‌دهید پیام‌ها را دریافت کند. نشستی که در حالت bare شروع می‌شود، هیچ سوکتی را bind نمی‌کند، بنابراین نه می‌تواند پیام دریافت کند و نه در لیست ظاهر شود.

مکان‌هایی که انتقال وظایف دچار بن‌بست می‌شود

حلقه‌های پیام به‌صورت خودکار مدیریت می‌شوند. Claude Code نرخ ارسال پیام‌های تکراری را برای هر فرستنده محدود می‌کند، تکرارهای مشابهی که در یک بازه زمانی کوتاه برسند را حذف می‌کند و تعداد پیام‌های پذیرفته‌شده در صف انتظار برای خوانده شدن را به 50 پیام در هر نشست محدود می‌سازد؛ بنابراین دو نشست نمی‌توانند تا ابد به یکدیگر پیام ارسال کنند (ping-pong). پیام‌های نگه‌داشته‌شده به 100 عدد محدود هستند و پس از آن، قدیمی‌ترین پیام‌ها حذف می‌شوند.

شکستی که واقعاً رخ می‌دهد، بی‌سروصداتر است و ماهیت آن «انتقال وظیفه» (hand-off) است، نه یک حلقه. نشست A از نشست B سوالی می‌پرسد که برای ادامه کار به پاسخ آن نیاز دارد، سپس به حالت بیکار (idle) می‌رود. نشست B پیام را نگه می‌دارد، یا در میانه یک پردازش طولانی است، یا به سوالی پاسخ می‌دهد که نشست A واقعاً نپرسیده است. نشست A منتظر می‌ماند. شما یک ساعت بعد بازمی‌گردید و با دو نشست بیکار مواجه می‌شوید که هیچ کاری انجام نداده‌اند.

انتقال وظایفی بنویسید که نیازی به پاسخ ندارند. یک پیام خوب حاوی یک واقعیت یا یک تصمیم است: چه چیزی تغییر کرده و نتیجه چه بوده است. یک پیام بد از نشست دیگر درخواست اجازه می‌کند، یا پاسخی می‌خواهد که فرستنده برای ادامه کار به آن وابسته است. به Claude دستور داده شده است که هرگز از نشست دیگری درخواستی نکند که تنظیمات دسترسی خودش آن را مسدود می‌کند، و در عوض آن کار را به شما ارجاع دهد. این قاعده را خودتان نیز گسترش دهید. اگر یک نشست بدون دریافت پاسخ نمی‌تواند پیشرفت کند، شما کسی هستید که باید به آن پاسخ دهید. انضباط در مدیریت کانتکست (context) نیز در اینجا کمک می‌کند، زیرا نشستی که رشته کار از دستش خارج شده باشد، پیام‌های مبهم می‌نویسد؛ مدیریت کانتکست در Claude Code این جنبه را پوشش می‌دهد.

رفتار با پیام‌های ورودی به‌عنوان ورودی غیرقابل‌اعتماد

Claude Code به Claude گیرنده اعلام می‌کند که پیام از نشست دیگری آمده و از طرف شما نیست؛ بنابراین، محدودیت‌هایی برای عملکرد آن پیام اعمال می‌کند. یک پیام نمی‌تواند از طرف شما به یک درخواست مجوز معلق پاسخ دهد، زیرا رضایت از یک نشست دیگر، رضایت شما محسوب نمی‌شود. این پیام نمی‌تواند تنظیمات مجوز، CLAUDE.md یا سایر پیکربندی‌ها را به درخواست یک نشست دیگر تغییر دهد. دستورات اسلش (slash command) داخل متن، مانند /compact، به‌عنوان متن ساده دریافت می‌شوند و هرگز اجرا نخواهند شد. اگر انجام عملیات بر اساس آن پیام نیازمند مجوزی باشد که نشست گیرنده آن را ندارد، شما همان درخواستی را مشاهده می‌کنید که برای هر کار دیگری می‌دیدید. در حالت auto، یک طبقه‌بندی‌کننده (classifier) نیز پیش از تحویل، هر پیام را بررسی می‌کند و پیامی که توسط آن مسدود شود، هرگز به گیرنده نمی‌رسد. این محدودیت‌ها حتی در حالت‌های permissive نیز برقرار می‌مانند؛ به همین دلیل است که یک نشست bypassکننده، پیام‌های ورودی را به‌طور پیش‌فرض نگه می‌دارد و به آن‌ها اعتماد نمی‌کند.

این موارد مربوط به مجوزها بود. محتوا شامل این موارد نمی‌شود. نشست فرستنده ممکن است توضیحات یک pull request، یک صفحه وب، فایل README یک dependency یا نظر یک غریبه در یک issue را خوانده باشد و هر آنچه خوانده است می‌تواند متن ارسالی به نشست دیگر شما را شکل دهد. پیام، داده است. این پیام مستحق همان بدگمانی است که نسبت به هر متن دیگری که از خارج وارد نشست شده، دارید. این همان انضباطی است که در دور نگه داشتن اسرار از عامل‌های هوش مصنوعی شرح داده شده است: فرض کنید هر چیزی که از مرز اعتماد عبور کرده ممکن است نادرست باشد و هرگز اجازه ندهید که خود را تأیید (authorise) کند.

اگر خواهان کنترل بیشتری هستید، دو راهکار وجود دارد. تنظیم crossSessionInbound روی refuse باعث می‌شود پیام‌های همتای ورودی بدون تحویل داده شدن، حذف شوند. این مقدار در تنظیمات پروژه یا تنظیمات محلی، بر هر منبع دیگری اولویت دارد، زیرا سخت‌گیرانه‌ترین گزینه در سلسله‌مراتب است. برای متوقف کردن ارسال یا فهرست‌کردن توسط این نشست، قوانین deny مجوز را با نام‌های SendMessage و ListAgents اضافه کنید؛ هر دو باید به‌عنوان نام ابزار خام و بدون مشخص‌کننده نوشته شوند. تنظیم isolatePeerMachines روی true نیازمند تأیید صریح شما پیش از رسیدن هر پیامی به نشستی خارج از این دستگاه است و این تأیید حتی در حالت bypassPermissions نیز الزامی است.

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

رد کردن SendMessage همچنین پیام‌رسانی به زیر-عامل‌ها (subagents) را حذف می‌کند، زیرا یک ابزار واحد برای هر دو مورد استفاده می‌شود. نشستی که درخواست را رد می‌کند، هیچ تغییر قابل‌مشاهده‌ای در /status خود یا در فهرست‌بندی سایر نشست‌ها نشان نمی‌دهد؛ بنابراین، تنظیمات را از طریق پیکربندی نشست تأیید کنید، نه از طریق صفحه نمایش.

پل‌ها و سرورهای MCP با حافظه مشترک

چندین پروژه شخص‌ثالث در همان دوره به کارهای مشابهی پرداختند: پل‌های محلی بین عامل‌ها (agent-to-agent) که متن را بین عامل‌های در حال اجرا منتقل می‌کنند، و سرورهای MCP (پروتکل زمینه مدل) که یک فضای ذخیره‌سازی مشترک برای خواندن و نوشتن در اختیار چندین عامل قرار می‌دهند. آن‌ها را به عنوان یک ساختار متفاوت در نظر بگیرید، نه به عنوان رقیب؛ و پیش از اجرای هر دستور نصب، آن را با فایل README همان پروژه تطبیق دهید. پیام‌رسانی از نوع push است، زیرا فرستنده متن را در نوبت گیرنده قرار می‌دهد. فضای ذخیره‌سازی مشترک از نوع pull است، زیرا هیچ‌کس وقفه دریافت نمی‌کند و یک نشست (session) زمانی یادداشت را می‌بیند که در نوبت بعدی به آن نگاه کند. مدل pull برای وضعیت‌هایی که به‌کندی تغییر می‌کنند آرام‌تر است و تنها زمانی کار می‌کند که نشست واقعاً به آن نگاه کند.

اگر این مسیر را انتخاب کردید، پرسش‌های ارزشمند به جای فهرست قابلیت‌ها، مربوط به فرآیند هستند. سرور با چه کاربری اجرا می‌شود و چه چیزهایی را روی سیستم می‌تواند بخواند؟ اجرای سرورهای MCP روی یک VPS این پیکربندی را پوشش می‌دهد. به‌اشتراک‌گذاری مهارت‌های عامل بین مخازن حالت ساده‌تری را پوشش می‌دهد که در آن هدف، به‌اشتراک‌گذاری دستورالعمل‌ها به جای وضعیت زنده (live state) بین نشست‌هاست؛ این کار بسیاری از پیام‌هایی را که در غیر این صورت باید ارسال می‌کردید، حذف می‌کند. برای دید کلی‌تر، اجرای یک عامل کدنویسی روی یک VPS نقطه شروع مناسبی است.

FAQ

چرا دستور /list-agents در نشست من شناسایی نمی‌شود؟

این نشست از قابلیت پیام‌رسانی بین‌نشستی پشتیبانی نمی‌کند. ابتدا claude --version را با نسخه 2.1.224 مقایسه کنید، زیرا این قابلیت به این نسخه یا بالاتر نیاز دارد. سپس پلتفرم خود را بررسی کنید؛ این قابلیت روی macOS و Linux اجرا می‌شود و در ویندوز بومی، Amazon Bedrock، Claude Platform روی AWS، پلتفرم Agent گوگل‌کلاود و Microsoft Foundry در دسترس نیست. اگر هر دو مورد صحیح هستند، پوسته (shell) خود را برای وجود DO_NOT_TRACK، DISABLE_TELEMETRY، CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC یا DISABLE_GROWTHBOOK بررسی کنید، زیرا هر یک از این موارد ارزیابی پرچم قابلیت (feature-flag) مورد نیاز را مسدود کرده و آن را غیرفعال نگه می‌دارند.

چرا پیام من به نشست دیگر هرگز نرسید؟

اگر /list-agents کار می‌کند، پیام‌رسانی فعال است و عامل محدودکننده‌تری مانع ارسال پیام شده است. دلیل رایج، حالت‌های دسترسی (permission modes) است. نشستی که درخواست‌های مجوز را دور می‌زند، تمام پیام‌های ورودی را تا زمان تأیید شما نگه می‌دارد، مگر اینکه فرستنده نیز مجوزها را دور زده باشد. آن پنجره تأیید پس از مهلت dialogExpiry، که به‌صورت پیش‌فرض 5 دقیقه است، حذف می‌شود. نشست فرستنده را برای مشاهده اعلان «در انتظار» بررسی کنید. برای رفع این مشکل، crossSessionInbound را در ~/.claude/settings.json روی accept تنظیم کنید یا آن را با --settings ارسال کنید، زیرا یک accept در تنظیمات پروژه یا محلی به دلیل مقدار آزادتر، نادیده گرفته می‌شود.

آیا یک نشست Claude Code در Docker می‌تواند به نشستی روی میزبان پیام دهد؟

خیر. نشست‌ها از طریق فایل‌های ثبت در دیسک و یک سوکت صندوق ورودی (inbox socket) اختصاصی یکدیگر را پیدا می‌کنند. از آنجا که کانتینر سیستم فایل مجزای خود را دارد، این دو نمی‌توانند فایل‌های یکسانی را ببینند. دو نشست درون یک کانتینر می‌توانند به‌طور عادی با هم پیام رد و بدل کنند. همین قاعده توضیح می‌دهد که چرا نشستی که با root اجرا می‌شود و نشستی که با کاربر عادی شما اجرا می‌شود نمی‌توانند به هم دسترسی داشته باشند: سوکت محدود به کاربر سیستم‌عاملی است که مالک آن است.

آیا عمل کردن به پیام یک نشست دیگر Claude Code ایمن است؟

متن را به عنوان ورودی غیرقابل‌اعتماد در نظر بگیرید، زیرا نشست فرستنده ممکن است یک صفحه وب، یک فایل README یا یک نظر در بخش issue که توسط شخص دیگری نوشته شده را خوانده باشد. Claude Code از قبل مانع از اجرای خودکار پیام می‌شود: این ابزار نمی‌تواند یک درخواست مجوز معلق را تأیید کند، نمی‌تواند تنظیمات مجوز یا CLAUDE.md را بنا به درخواست تغییر دهد و یک دستور اسلش (slash command) در متن، صرفاً به عنوان متن ساده دریافت شده و هرگز اجرا نمی‌شود. این محافظت‌ها مجوزها را پوشش می‌دهند، نه قضاوت شما را؛ بنابراین پیش از آنکه به نشست گیرنده دستور عمل کردن بدهید، محتوای دریافتی را مطالعه کنید.

آیا پیام‌رسانی بین‌نشستی، کد من را برای Anthropic ارسال می‌کند؟

خیر، بین دو نشست روی یک دستگاه، این اتفاق نمی‌افتد. پیام از طریق یک سوکت اختصاصی روی همان دستگاه منتقل می‌شود و هرگز از سرورهای Anthropic عبور نمی‌کند. تنها متنی که Claude نوشته است ارسال می‌شود و هرگز تاریخچه گفتگو یا فایل‌ها منتقل نمی‌شوند. پیام‌ها به نشستی روی دستگاه دیگر شما یا نشستی در وب، از طریق سرورهای Anthropic و اتصال Remote Control منتقل می‌شوند. در آن جهت، Claude تنها می‌تواند به پیامی که دریافت شده پاسخ دهد و نمی‌تواند خود آغازگر پیام باشد. برای الزام به تأیید شما پیش از خروج هرگونه داده از دستگاه، isolatePeerMachines را روی true تنظیم کنید.