كيفية تبادل الرسائل بين جلسات Claude Code

معنى أن تتبادل جلسات Claude Code الرسائل

يمكن لجلسَتَي Claude Code تبادل الرسائل عندما تعملان على الجهاز نفسه وتحت مستخدم نظام التشغيل نفسه. الرسالة هي نص عادي يكتبه Claude لإرساله إلى جلسة أخرى. ولا تتضمن سجل المحادثة أو أي ملفات. يعثر Claude على الجلسة الأخرى باستخدام أداة ListAgents، ويسلّمها النص باستخدام SendMessage، لذلك لا تستدعي أيّاً من الأداتين يدوياً. حدّد ما تحتاج الجلسة الأخرى إلى معرفته، وسيكتب Claude الرسالة بنفسه.

تُسمّى هذه الميزة المراسلة بين الجلسات. اعتباراً من August 2026، تتطلب Claude Code v2.1.224 أو إصداراً أحدث، وتعمل على macOS وLinux، بما في ذلك Linux داخل WSL 2. لا يتوفر دعم أصلي لـWindows، كما أنها غير متاحة على Amazon Bedrock أو Claude Platform on AWS أو Google Cloud's Agent Platform أو Microsoft Foundry. عندما تستوفي الجلسة هذه المتطلبات، تكون المراسلة مفعّلة تلقائياً ولا تحتاج إلى أي إعداد. يستند السلوك الموضح أدناه إلى وثائق Anthropic الخاصة بالمراسلة بين الجلسات.

تظهر أهمية ذلك على VPS، لأن الجلسات على VPS تستمر مدة كافية لتستحق توجيه الرسائل إليها. على الحاسوب المحمول، تغلق الغطاء. أما على خادم يعمل عليه tmux، فالجلسة التي بدأتها يوم Monday قد تظل قيد التشغيل يوم Thursday، مع احتفاظها بسياق مستودع واحد. وعندما تصبح لديك جلستان من هذا النوع، لن يعود أسلوب تواصلهما مسألة نظرية. إذا لم تكن قد أعددت ذلك بعد، فابدأ بـتشغيل Claude Code على VPS باستخدام tmux، إذ يشرح ذلك إعداد الجلسات الذي يفترضه هذا الدليل.

متى تستحق جلسة ثانية التكلفة

ابدأ بالتكلفة. كل جلسة هي مثيل مستقل من Claude مع نافذة سياق خاصة بها، لذلك تكلف جلستان ضعف تكلفة جلسة واحدة تقريباً خلال الفترة نفسها. تُحتسب الرسالة المُرسلة ضمن الاستخدام تماماً مثل prompt تكتبه بنفسك. التنسيق ليس مجانياً، والعمل الذي يتكوّن فعلياً من سلسلة خطوات واحدة يصبح أبطأ وأكثر تكلفة عند تقسيمه بين جلسات متعددة.

تشترك الحالات التي تبرر تكلفة جلسة ثانية في نمط واحد. يعمل جزءان من العمل في الوقت نفسه من دون انتظار أحدهما للآخر، ويتعلم أحدهما أثناء المهمة شيئاً يحتاج إليه الآخر.

• تعثر جلسة على تغيير يكسر التوافق بينما تواصل الجلسة الأخرى البناء على الكود الذي كسره التغيير. تلخّص Claude التغيير وترسله بدلاً من أن تعيد كتابته بنفسك في الطرفية الأخرى.
• تعمل جلستان على المستودع نفسه ضمن git worktrees منفصلة، وتحتاج إحداهما إلى معرفة ما تم دمجه.
• ترسل عملية ترحيل أو اختبار طويلة نتيجتها إلى الجلسة التي تراقبها.
• تعمل جلسة للبناء وأخرى للمراجعة، حيث تقرأ جلسة المراجعة ما أنتجته جلسة البناء وترسل ما توصلت إليه.

عندما يكون العمل متسلسلاً، أو عندما تعدّل الجلستان الملفات نفسها، استخدم جلسة واحدة. عندما تريد مجموعة منسقة تنشئها Claude وتشرف عليها ضمن مهمة واحدة، فهذه هي agent teams، وهي ميزة منفصلة وما زالت تجريبية. عندما تريد فقط المحادثة نفسها في طرفية أخرى، استأنف الجلسة بدلاً من ذلك. تُستخدم المراسلة بين الجلسات للجلسات المستقلة التي تبدأها وتوجّهها بنفسك.

تحقّق من توفر الميزة قبل أن تبني إعداداتك عليها

أولاً، تحقّق من الإصدار:

claude --version

قارن الرقم مع 2.1.224. ثم اكتب داخل الجلسة /list-agents، وهو يقبل أيضاً /peers. يعرض الأمر كل وكيل يمكن لهذه الجلسة الوصول إليه، مع الاسم الذي يستجيب له كل وكيل. إذا لم يتعرّف النظام على الأمر إطلاقاً، فلا تملك هذه الجلسة إمكانية المراسلة بين الجلسات، ولن يغيّر أي ملف إعدادات ذلك. اكتب /status وابحث عن صف Peer address: فهو يحتوي على عنوان صندوق الوارد الخاص بهذه الجلسة، مسبوقاً بـuds:.

توجد مشكلة تؤثر خصوصاً في مستخدمي VPS. تعتمد المراسلة بين الجلسات على تقييم أعلام الميزات، وتؤدي عدة متغيرات للخصوصية إلى إيقاف هذا التقييم، فتظل الميزة في حالتها الافتراضية المعطّلة. جميع المتغيرات DO_NOT_TRACK وDISABLE_TELEMETRY وCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC وDISABLE_GROWTHBOOK تفعل ذلك. يعزّز المستخدمون أمان خادم جديد بلصق هذه المتغيرات في ~/.bashrc، ثم يتساءلون عن سبب عدم وجود /list-agents. ويمكن أن تصل القيم نفسها من الخريطة env في ملف إعدادات أو من إعدادات مُدارة، لذلك افحص الصدفة أولاً.

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

ألغِ ضبط أي متغير يعرض قيمة. بالنسبة إلى DISABLE_TELEMETRY وCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC، تؤدي أي قيمة غير فارغة إلى تفعيل السلوك، بما في ذلك السلسلة 0، ولذلك لا يفعل DISABLE_TELEMETRY=0 ما يبدو أنه يفعله. لإيقاف السلوك، ألغِ ضبط المتغير أو اضبطه على سلسلة فارغة.

سمِّ جلساتك، وإلا فلن يتمكن Claude من مخاطبتها

يخاطب Claude رسالةً إلى جلسة باستخدام اسمها. عيِّن الاسم عند بدء الجلسة:

claude --name builder-api

يمكنك أيضاً تعيينه باستخدام /rename داخل جلسة قيد التشغيل. إذا لم تعيّن اسماً، يستخرج Claude Code اسماً من اسم مجلد دليل العمل، مثل myapp-3f. هذا مناسب لجلسة واحدة، لكنه يسبب الالتباس عند استخدام أربع جلسات، وقد ينتهي الأمر بحصول جلستين على الاسم نفسه. يعرض خرج /list-agents دليل العمل لكل جلسة محلية، ما يميّز بين الجلسات التي تحمل الاسم نفسه، كما تضيف قائمة Claude نفسها معرّفاً مختصراً إلى العنوان عند تعارض الأسماء. تسمية الجلسات بنفسك أوفر من قراءة المعرّفات.

تخطيط tmux من جلستين يمكنك إعادة إنشائه

هذه جلسة بناء وجلسة مراجعة على مستودع واحد. تعمل جلسة المراجعة في git worktree منفصل، لذلك لا تكتب الجلستان في الملف نفسه مطلقاً. يوفّر git worktree add مع HEAD نسخة checkout منفصلة، وهذا ما تحتاج إليه لجلسة تقرأ بدلاً من تنفيذ 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 يختلف من مرة إلى أخرى. تظهر الرسالة في نافذة المراجعة ضمن المحادثة مع اسم المُرسل. إذا كانت الجلسة خاملة، يبدأ Claude دوراً جديداً فيها فوراً. وإذا كانت في منتصف دور، تنتظر الرسالة حتى الفاصل بين استدعاءات الأدوات، لذلك لا يُقاطَع أمر قيد التشغيل. بعد أن يقرأها Claude، تنكمش الرسالة إلى صف Message from من سطر واحد، ويوسّعه Ctrl+O. يعمل الزوج بصورة أفضل عندما يحافظ البنّاء على صغر تغييراته، لأن diff محدوداً ينتج تسليماً أقصر ومراجعة تستطيع الجلسة الأخرى إنهاءها في دور واحد. وهذه هي العادة التي وُجدت مهارة المطوّر الخبير الكسول لفرضها.

من يمكنه رؤية من على VPS واحد

لا تمرّ عملية التسليم بين الجلسات على الجهاز نفسه عبر خوادم Anthropic. تكتب كل جلسة ملفات التسجيل على القرص، وتربط socket الوارد الخاص بها، ويقرأ Claude Code هذه الملفات للعثور على جلساتك الأخرى. وينتج عن ذلك أمران، وكلاهما يسبب مشكلات على الخادم.

يقتصر الوصول إلى socket على مستخدم نظام التشغيل الذي يشغّل الجلسة. لا يمكن لجلسة بدأتها بصفتك root ولجلسة بدأتها بصفتك deploy رؤية إحداهما الأخرى، حتى إذا كانتا تعملان جنباً إلى جنب في خادم tmux نفسه، لأن جلسات أحد المستخدمين لا يمكنها الوصول إلى socket الخاص بمستخدم آخر. شغّل الجلستين باستخدام المستخدم نفسه.

للحاوية نظام ملفات خاص بها. لا يمكن لجلسة داخل Docker وجلسة على المضيف الوصول إلى إحداهما الأخرى، لأنهما لا تقرآن ملفات التسجيل نفسها. ويمكن لجلسَتين داخل الحاوية نفسها تبادل الرسائل بشكل طبيعي. إذا كنت تُبقي الوكلاء داخل حاويات للعزل، كما في تشغيل وكلاء البرمجة في VM مؤقتة، فتوقّع أن يعمل تبادل الرسائل داخل الحاوية، لا عبر حدود الحاوية.

تظهر جلساتك على الأجهزة الأخرى وعلى الويب في القائمة فقط أثناء اتصال Remote Control، وتُوسَم وفقاً لذلك. لا يستطيع Claude هنا الرد إلا على رسالة وصلت من إحدى تلك الجلسات. ولا يستطيع بدء هذا التبادل.

لماذا لم تصل رسالتك

السبب المعتاد لا علاقة له بالشبكة. تحدد جلسة الاستقبال الإجراء الذي ستتخذه بشأن الرسالة، ولم يكن القرار هو تسليمها. تنتهي كل رسالة واردة في إحدى ثلاث نتائج: التسليم، أو الاحتجاز (وضعها جانباً من دون تسليمها إلى أن توافق عليها)، أو الرفض (إسقاطها من دون تسليم).

عندما لا تنطبق قيمة crossSessionInbound، يحدد Claude Code الإجراء لكل رسالة من خلال مقارنة وضعي الأذونات في الجلستين. ويضع الجلسات التي تتجاوز مطالبات الأذونات في فئة واحدة، وكل الجلسات الأخرى في الفئة الثانية. وتُعد auto وacceptEdits وdontAsk أوضاعاً تطلب الأذونات. ويُعد Plan mode وضعاً يتجاوز المطالبات في الجلسة التي تتوفر فيها أذونات التجاوز. إذا لم تكن متأكداً من الفئة التي تنتمي إليها جلسة ما، فاقرأ أولاً ما الذي يفعله كل وضع أذونات فعلياً، لأن auto هو الوضع الذي تبدأ به معظم الجلسات الآن، وهو يقع في جانب طلب الأذونات من هذا التقسيم. وتكون القاعدة متماثلة في الاتجاهين:

• تُسلِّم جلسة استقبال تطلب الأذونات كل رسالة تصلها. ولا تحتجز الرسالة إلا عندما تعرّف جلسة الإرسال نفسها بأنها تتجاوز مطالبات الأذونات.
• تحتجز جلسة استقبال تتجاوز مطالبات الأذونات كل رسالة بانتظار موافقتك. ولا تسلّم الرسالة إلا عندما تتجاوز جلسة الإرسال أيضاً مطالبات الأذونات.

لذلك فإن أول سير عمل ينشئه معظم الأشخاص هو بالضبط سير العمل الذي لا يعمل. تبدأ builder باستخدام --permission-mode bypassPermissions لأنك تريدها أن تعمل من دون تدخل، وتُبقي reviewer على الإعدادات الافتراضية، فتنتظر كل رسالة ترسلها builder في مربع حوار موافقة لا يراقبه أحد. يُغلق مربع الحوار بعد مهلة dialogExpiry، التي تكون قيمتها الافتراضية 5m، فتُسقط الرسالة. على الجهاز نفسه، تتلقى جلسة الإرسال إشعاراً عند احتجاز رسالتها، ثم إشعاراً لاحقاً عندما تسلّمها جلسة الاستقبال أو ترفضها أو تنتهي مهلة الانتظار. لذلك اقرأ شاشة المرسل قبل أن تلقي اللوم على الـsocket.

لجعل جلسة تستقبل الرسائل من دون تدخل، اضبط crossSessionInbound على accept. ويحدد موضع ضبط هذا الخيار نطاق تطبيقه. يقرأ Claude Code الإعدادات المُدارة أولاً، ثم الخيار --settings، ثم إعدادات المستخدم، ويطبّق أول قيمة يعثر عليها. ولا ينطبق أيٌّ من إعدادات المشروع أو الإعدادات المحلية إلا عندما يكون أكثر تقييداً، وفق السلم accept < hold < refuse. وتكون قيمة accept في .claude/settings.json أقل تقييداً من أي شيء، لذلك يتم تجاهلها عندما يضبط مصدر موثوق قيمة. ضعها في ~/.claude/settings.json، أو مرّرها لجلسة واحدة:

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

يربط عامل claude -p الذي يعمل دون واجهة اتصال inbox مثل الجلسة التفاعلية، ويظهر في القائمة، لكنه لا يستطيع عرض مربع حوار للموافقة. وتبقى الرسالة المحتجزة فيه محتجزة إلى أن يسمح تغيير لاحق في الوضع أو الإعدادات باستقبالها. ويوضح السطر --settings أعلاه كيفية السماح لهذا العامل باستقبال الرسائل. أما الجلسة التي تبدأ في bare mode فلا تربط أي socket، ولذلك لا يمكنها استقبال الرسائل أو الظهور في القائمة.

عندما تصل عمليات التسليم إلى طريق مسدود

تُعالَج حلقات الرسائل تلقائياً. يفرض Claude Code حداً لمعدل الرسائل المتكررة من كل مرسل، ويتجاهل التكرارات المتطابقة التي تصل خلال فترة زمنية قصيرة، ويحدّ الرسائل المقبولة التي تنتظر القراءة إلى 50 رسالة لكل جلسة، لذلك لا يمكن لجلسيتين تبادل الرسائل إلى ما لا نهاية. ويُحدَّد عدد الرسائل المحتجزة بـ100 رسالة، ثم تُحذف أقدم الرسائل عند تجاوز هذا الحد.

الفشل الذي يحدث فعلياً أكثر هدوءاً، وهو عملية تسليم وليست حلقة. تطرح Session A سؤالاً على Session B وتحتاج إلى إجابته قبل أن تتمكن من المتابعة، ثم تصبح خاملة. قد تحتفظ B بالرسالة، أو تكون في منتصف دورة طويلة لمعالجة أمر آخر، أو تجيب عن سؤال لم تطرحه A فعلياً. تنتظر A. ثم تعود بعد ساعة لتجد جلستين خامدتين من دون إنجاز أي عمل.

اكتب عمليات التسليم بحيث لا تحتاج إلى رد. تحمل الرسالة الجيدة حقيقة أو قراراً: ما الذي تغيّر، وما النتيجة. أما الرسالة السيئة فتطلب من الجلسة الأخرى الإذن، أو تطلب إجابة يتوقف عليها المرسل. وقد تم توجيه Claude مسبقاً إلى عدم مطالبة جلسة أخرى بتنفيذ إجراء تمنعه إعدادات أذوناتها، وإعادة توجيه هذا العمل إليك بدلاً من ذلك. عمّم هذه القاعدة بنفسك. إذا لم تتمكن جلسة من التقدم دون إجابة، فأنت من ينبغي أن يجيب عنها. ويساعدك ضبط السياق هنا أيضاً، لأن الجلسة التي فقدت تسلسل العمل تكتب رسائل غامضة؛ يشرح إدارة السياق في Claude Code هذا الجانب.

عامِل الرسالة الواردة كمدخل غير موثوق

يُخبر Claude Code جلسة Claude المستقبِلة بأن الرسالة جاءت من جلسة أخرى وليست منك، ويحدّ مما يمكن لهذه الرسالة فعله. يُطبَّق هذا التقييد في البرنامج المحيط بالنموذج، وليس في استعداد النموذج للامتثال، وهذا هو الفرق العملي الذي يوفّره غلاف الوكيل. لا يمكن للرسالة الإجابة نيابةً عنك عن مطالبة إذن معلّقة، لأن موافقة جلسة أخرى ليست موافقتك. ولا يمكنها تغيير إعدادات الأذونات أو CLAUDE.md أو أي إعدادات أخرى لأن جلسة أخرى طلبت ذلك. يصل الأمر المسبوق بشرطة مائلة داخل النص، مثل /compact، كنص عادي ولا يُنفَّذ مطلقاً. إذا كان تنفيذ الإجراء المطلوب من الرسالة يحتاج إلى إذن لا تملكه الجلسة المستقبِلة، فسترى المطالبة نفسها التي تراها عند تنفيذ أي عمل آخر. في الوضع التلقائي، يراجع المصنّف كل رسالة أيضاً قبل تسليمها، ولا تصل الرسالة التي يحظرها إلى المستلم. تبقى هذه القيود سارية في أوضاع السماح، ولذلك تحجز الجلسة التي تتجاوز القيود الرسائل الواردة افتراضياً بدلاً من الوثوق بها.

هذا يغطّي الأذونات، لكنه لا يغطّي المحتوى. قد تكون الجلسة المرسِلة قد قرأت وصف pull request أو صفحة ويب أو README لتبعية أو تعليقاً على issue كتبه شخص غير معروف، وما قرأته يمكن أن يؤثر في النص الذي تكتبه لجلسة أخرى لديك. الرسالة بيانات. ويجب التعامل معها بالشك نفسه الذي تتعامل به مع أي نص آخر دخل إلى جلسة من خارجها. هذا هو المبدأ الموضّح في إبعاد الأسرار عن وكلاء الذكاء الاصطناعي: افترض أن أي شيء عبر حدود الثقة قد يكون خاطئاً، ولا تسمح له مطلقاً بمنح نفسه صلاحية.

يوجد إعدادان إذا أردت تقليل ذلك. يؤدي ضبط crossSessionInbound على refuse إلى إسقاط رسائل الأقران الواردة دون تسليمها، ومن إعدادات المشروع أو الإعدادات المحلية، يسري ذلك على كل مصدر آخر، لأنه الخيار الأكثر تشدداً في التسلسل. ولمنع هذه الجلسة من الإرسال أو العرض، أضف قواعد رفض للأذونات تسمّي SendMessage وListAgents، ويُكتب كلاهما كاسم أداة مجرد دون محدِّد. يتطلب ضبط isolatePeerMachines على true موافقتك الصريحة قبل وصول أي رسالة إلى جلسة خارج هذا الجهاز، وتبقى هذه الموافقة مطلوبة حتى في وضع bypassPermissions.

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

يؤدي رفض SendMessage أيضاً إلى إزالة المراسلة مع الوكلاء الفرعيين، لأن الأداة نفسها تخدم الغرضين. لا تُظهر الجلسة الرافضة أي تغيير مرئي في /status الخاص بها أو في قوائم الجلسات الأخرى، ولذلك تحقّق من الإعداد من تكوين الجلسة بدلاً من الاعتماد على الشاشة.

خوادم MCP للجسور والذاكرة المشتركة

ظهرت عدة مشاريع من جهات خارجية خلال الفترة نفسها، وتقدم وظائف قريبة من ذلك: جسور محلية بين الوكلاء لترحيل النصوص بين الوكلاء قيد التشغيل، وخوادم MCP (بروتوكول سياق النموذج) تمنح عدة وكلاء مخزناً مشتركاً للقراءة والكتابة. تعامل معها باعتبارها بنية مختلفة، لا منافساً، وتحقق من أي أمر تثبيت في README الخاص بالمشروع قبل تشغيله. تعتمد المراسلة على الدفع، لأن المرسل يضع النص في دور المستقبل. أما المخزن المشترك فيعتمد على السحب، لأن أياً من الطرفين لا يتلقى مقاطعة، وترى الجلسة الملاحظة عندما تبحث عنها في المرة التالية. يكون السحب أكثر هدوءاً عند التعامل مع حالة تتغير ببطء، لكنه لا يعمل إلا عندما تبحث الجلسة فعلياً عن الملاحظة.

إذا اخترت هذا المسار، فتركّز الأسئلة المهمة على العملية لا على قائمة الميزات. ما المستخدم الذي يعمل الخادم باسمه، وما الذي يمكنه قراءته على الخادم. يشرح تشغيل خوادم MCP على VPS هذا الإعداد. ويشرح مشاركة مهارات الوكلاء بين المستودعات الحالة الأبسط، عندما تكون التعليمات هي ما تريد مشاركته بين الجلسات بدلاً من الحالة المباشرة، كما أنه يقلل كثيراً من الرسائل التي كنت سترسلها خلاف ذلك. وللاطلاع على الصورة الأوسع، ابدأ من تشغيل وكيل برمجي على VPS.

FAQ

لماذا لا يتعرّف النظام على /list-agents في جلستي؟

لا تتوفر في الجلسة ميزة المراسلة بين الجلسات. تحقّق أولاً من claude --version مقابل الإصدار 2.1.224، لأن الميزة تحتاج إلى هذا الإصدار أو إصدار أحدث. ثم تحقّق من النظام الأساسي، لأن الميزة تعمل على macOS وLinux، ولا تعمل على Windows الأصلي، كما أنها غير متاحة على Amazon Bedrock وClaude Platform on AWS وGoogle Cloud's Agent Platform وMicrosoft Foundry. إذا كان كلا الشرطين مستوفى، فتحقّق من shell بحثاً عن DO_NOT_TRACK أو DISABLE_TELEMETRY أو CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC أو DISABLE_GROWTHBOOK، لأن كل واحد منها يمنع تقييم feature flag الذي تعتمد عليه الميزة، ويتركها معطّلة.

لماذا لم تصل رسالتي إلى الجلسة الأخرى؟

إذا كان /list-agents يعمل، فالمراسلة مفعّلة، وقد أوقف هذه الرسالة سبب أكثر تحديداً. السبب الشائع هو أوضاع الأذونات. الجلسة التي تتجاوز مطالبات الأذونات تحتفظ بكل رسالة واردة إلى أن توافق عليها، ما لم يتجاوز المرسل مطالبات الأذونات أيضاً. ويُسقط مربع حوار الموافقة بعد انتهاء مهلة dialogExpiry، التي تبلغ خمس دقائق افتراضياً. تحقّق من الجلسة المرسلة بحثاً عن إشعار بالاحتفاظ بالرسالة. لإصلاح ذلك، عيّن crossSessionInbound إلى accept في ~/.claude/settings.json، أو مرّرها باستخدام --settings، لأن قيمة accept في إعدادات المشروع أو الإعدادات المحلية يتم تجاهلها باعتبارها القيمة الأقل تقييداً.

هل يمكن لجلسة Claude Code داخل Docker مراسلة جلسة على المضيف؟

لا. تتعرّف الجلسات إلى بعضها من خلال ملفات تسجيل على القرص وsocket لصندوق وارد خاص بكل جلسة. ولأن الحاوية تملك نظام ملفات خاصاً بها، فلا يمكن للجلسـتين رؤية الملفات نفسها. يمكن لجلسـتين داخل الحاوية نفسها تبادل الرسائل بشكل طبيعي. وتفسّر القاعدة نفسها سبب عدم تمكّن جلسة تعمل باسم root وجلسة تعمل باسم مستخدمك العادي من الوصول إلى بعضهما: إذ يقتصر socket على مستخدم نظام التشغيل الذي يملكه.

هل من الآمن تنفيذ إجراء بناءً على رسالة من جلسة Claude Code أخرى؟

تعامل مع النص على أنه إدخال غير موثوق، لأن الجلسة المرسلة قد تكون قرأت صفحة ويب أو README أو تعليقاً على issue كتبه شخص آخر. يوقف Claude Code الرسالة بالفعل قبل أن تتخذ إجراءً من تلقاء نفسها: فلا يمكنها الموافقة على مطالبة إذن معلّقة، ولا يمكنها تغيير إعدادات الأذونات أو CLAUDE.md استجابةً للطلب، كما أن slash command الوارد في النص يصل كنص عادي ولا يُنفَّذ مطلقاً. تغطي هذه الحماية الأذونات، ولا تغطي الحكم على المحتوى؛ لذلك اقرأ الرسالة الواردة قبل أن تطلب من الجلسة المستقبِلة تنفيذ إجراء بناءً عليها.

هل ترسل المراسلة بين الجلسات الشيفرة الخاصة بي إلى Anthropic؟

لا، عندما تكون الجلستان على الجهاز نفسه. تنتقل الرسالة عبر socket خاص بكل جلسة على ذلك الجهاز، ولا تمر عبر خوادم Anthropic. ولا يُرسل سوى النص الذي كتبه Claude، من دون سجل المحادثة أو الملفات. أما الرسائل المرسلة إلى جلسة على جهاز آخر تملكه، أو إلى جلسة على الويب، فتمر عبر خوادم Anthropic باستخدام اتصال Remote Control. وفي هذا الاتجاه، لا يستطيع Claude إلا الرد على رسالة وصلت إليه، ولا يستطيع بدء رسالة. عيّن isolatePeerMachines إلى true لطلب موافقتك قبل مغادرة أي شيء للجهاز.