كيفية إرسال الرسائل بين جلسات 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، لأن جلساته تستمر مدة تكفي لتبادل الرسائل بينها. على حاسوب محمول، تغلق الغطاء. أما على خادم يعمل عليه tmux، فقد تظل جلسة بدأتها يوم الاثنين قيد التشغيل يوم الخميس، محتفظة بسياق مستودع واحد. وعندما يصبح لديك جلستان من هذا النوع، لا يعود تواصلهما أمراً نظرياً. إذا لم تُعدّ ذلك بعد، فابدأ بـتشغيل Claude Code على VPS باستخدام tmux، إذ يشرح ذلك إعداد الجلسات الذي يفترضه هذا الدليل.

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

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

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

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

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

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

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

claude --version

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

توجد مشكلة تؤثر في مستخدمي VPS تحديداً. تعتمد المراسلة بين الجلسات على تقييم feature flags، وتوقف عدة متغيرات للخصوصية هذا التقييم، ما يُبقي الميزة في حالتها الافتراضية المعطّلة. تفعل 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'

ألغِ ضبط أي متغير يعرض قيمة. بالنسبة إلى 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.

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. يعمل هذا الأسلوب بصورة أفضل عندما يحافظ البنّاء على صغر تغييراته، لأن الفرق الضيق ينتج تسليماً أقصر ومراجعة تستطيع الجلسة الأخرى إنهاءها في دور واحد. وهذه هي العادة التي وُجدت مهارة المطوّر الخبير الكسول لترسيخها.

من يستطيع رؤية من على VPS واحد

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

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

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

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

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

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

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

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

لذلك فإن أول سير عمل يبنيه معظم الأشخاص هو بالضبط سير العمل الذي لا يعمل. تبدأ منشئاً باستخدام --permission-mode bypassPermissions لأنك تريده أن يعمل دون تدخل، وتترك المراجع على الإعدادات الافتراضية، فتظل كل رسالة يرسلها المنشئ منتظرة في مربع حوار موافقة لا يراقبه أحد. يُغلق مربع الحوار بعد انقضاء المهلة 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 عديم الواجهة socket لصندوق الوارد مثل الجلسة التفاعلية، ويظهر في القائمة، لكنه لا يستطيع عرض مربع حوار للموافقة. وتظل الرسالة المحتجزة لديه محتجزة حتى يسمح تغيير لاحق في النمط أو الإعدادات باستقبالها. ويبيّن سطر --settings أعلاه كيفية السماح لهذا العامل باستقبال الرسائل. أما الجلسة التي تبدأ في الوضع العاري فلا تربط أي socket، ولذلك لا يمكنها استقبال الرسائل أو الظهور في القائمة.

عندما تتعطل عمليات التسليم المتبادلة

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

الفشل الذي يحدث فعلاً أكثر هدوءاً، وهو عملية تسليم متبادلة لا حلقة. تطرح الجلسة A سؤالاً على الجلسة 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 لطلب موافقتك قبل خروج أي شيء من الجهاز.