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

معنای تبادل پیام بین نشست‌های Claude Code

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

این قابلیت، پیام‌رسانی بین‌نشستی (cross-session messaging) نام دارد. از اوت 2026، این ویژگی به Claude Code نسخه v2.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هایی که این session به آن‌ها دسترسی دارد را به همراه نامی که هر کدام با آن پاسخ می‌دهند، چاپ می‌کند. اگر دستور اصلاً شناخته نشد، این session قابلیت پیام‌رسانی بین-session (cross-session messaging) را ندارد و هیچ فایل تنظیمی این وضعیت را تغییر نخواهد داد. دستور /status را تایپ کنید و به دنبال ردیف Peer address بگردید: این ردیف شامل آدرس inbox خودِ این session است که با uds: پیشوند شده است.

یک دام برای کاربران VPS وجود دارد. پیام‌رسانی بین-session به ارزیابی 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 جداشده (detached) ایجاد می‌کند که دقیقاً همان چیزی است که برای نشستی که به جای commit کردن، صرفاً مطالعه می‌کند، نیاز دارید. از آنجا که این دو نشست وظایف متفاوتی دارند، ارزشش را دارد که به بازبین یک سبک خروجی اختصاصی بدهید؛ این کار باعث تغییر system prompt آن نشست می‌شود و برخلاف دستوری که یک‌بار تایپ می‌کنید، در تمام طول گفتگو باقی می‌ماند.

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 پنجره‌ها را بر اساس نام فهرست می‌کند تا بتوانید یکی را انتخاب کنید. در پنجره سازنده، دستور /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 ارسال می‌کند متغیر است. در پنجره بازبین، پیام در گفتگو با نام فرستنده ظاهر می‌شود. اگر آن نشست در حالت بیکار (idle) باشد، Claude بلافاصله یک نوبت جدید روی آن شروع می‌کند. اگر در میانه یک نوبت باشد، پیام تا زمان بین فراخوانی ابزارها منتظر می‌ماند تا اجرای هیچ دستوری قطع نشود. هنگامی که Claude آن را خواند، پیام به یک ردیف Message from تک‌خطی تبدیل می‌شود که Ctrl+O آن را باز می‌کند. این جفت زمانی بهتر کار می‌کند که سازنده تغییرات خود را کوچک نگه دارد، زیرا یک diff محدود باعث تحویل کوتاه‌تر و بازبینی‌ای می‌شود که نشست دیگر می‌تواند در یک نوبت آن را به پایان برساند؛ این همان عادتی است که مهارت توسعه‌دهنده ارشد تنبل برای اعمال آن وجود دارد.

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

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

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

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

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

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

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

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

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

بنابراین، اولین گردش کاری که اکثر افراد می‌سازند، دقیقاً همان چیزی است که کار نمی‌کند. شما یک 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، یک سوکت صندوق ورودی را مانند یک نشست تعاملی متصل می‌کند و در لیست ظاهر می‌شود، اما نمی‌تواند پنجره تأیید را نمایش دهد. پیام نگه‌داشته شده در آنجا تا زمانی که تغییر حالت یا تنظیمات بعدی اجازه ندهد، در همان وضعیت باقی می‌ماند. خط --settings در بالا روشی است که به چنین worker اجازه می‌دهید پیام‌ها را دریافت کند. نشستی که در حالت bare شروع شود، هیچ سوکتی را متصل نمی‌کند، بنابراین نه می‌تواند پیام دریافت کند و نه در لیست ظاهر می‌شود.

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

حلقه‌های پیام به‌طور خودکار مدیریت می‌شوند. Claude Code نرخ ارسال پیام‌های تکراری توسط هر فرستنده را محدود می‌کند، پیام‌های تکراری یکسان که در یک بازه زمانی کوتاه برسند را حذف می‌کند و سقف پیام‌های پذیرفته‌شده‌ای که در انتظار خوانده شدن هستند را به 50 پیام در هر نشست محدود می‌کند تا دو نشست نتوانند تا ابد به یکدیگر پیام ارسال کنند. پیام‌های نگه‌داشته‌شده نیز به 100 مورد محدود شده‌اند و پس از آن، قدیمی‌ترین پیام‌ها حذف می‌شوند.

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

این نشست از قابلیت پیام‌رسانی بین‌نشستی (cross-session) برخوردار نیست. ابتدا claude --version را با نسخه 2.1.224 مقایسه کنید، زیرا این قابلیت به این نسخه یا بالاتر نیاز دارد. سپس پلتفرم خود را بررسی کنید؛ این ویژگی روی macOS و Linux اجرا می‌شود و در ویندوز بومی (native) در دسترس نیست. همچنین این قابلیت در Amazon Bedrock، Claude Platform روی AWS، پلتفرم Agent گوگل‌کلاد و Microsoft Foundry پشتیبانی نمی‌شود. اگر این موارد مشکلی ندارند، شل خود را برای وجود 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 در تنظیمات پروژه یا محلی به دلیل مقدار آزادتر (looser) نادیده گرفته می‌شود.

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

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

آیا پیام دریافتی از یک نشست دیگر Claude Code برای اقدام ایمن است؟

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

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

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