Anthropic نے Claude Code کے لیے کراس-سیشن میسنجرنگ کا تجرباتی فیچر متعارف کرایا ہے، جو مختلف سیشنز کو براہ راست ایک دوسرے کو پیغامات بھیجنے کی اجازت دیتا ہے۔ یہ فیچر مکمل کنٹیکس نہیں بھیجتا، بلکہ صرف ٹاسک کے نتائج اور منحصر معلومات کو بھیجتا ہے، جو ListAgents اور SendMessage دو اندر کے ٹولز کے ذریعے حاصل ہوتے ہیں۔ ہر مقامی سیشن ڈسک پر رجسٹر ہوتا ہے اور Inbox Socket سے منسلک ہوتا ہے، جس کے ذریعے مقامی پیغامات براہ راست Socket کے ذریعے منتقل ہوتے ہیں، جبکہ دوسری مشینوں تک پیغامات Anthropic سرور کے ذریعے منتقل ہوتے ہیں۔ پیغامات سیشن کے آرام کے دوران نئے Turn کو فعال کرتے ہیں، جبکہ فعال Turn میں وہ Tool Call کے درمیان پڑھے جاتے ہیں۔ وصول کنندہ کراس-سیشن پیغامات کو صارف پیغامات سے الگ کرتا ہے، جو صارف کی اجازت کا متبادل نہیں ہوسکتے، اور ان میں accept/hold/refuse تین Inbound Control موڈز متعین کیے گئے ہیں۔ یہ فیچر Resume Session، Agent Teams، Worktree جیسے موجودہ صلاحیتوں کے ساتھ مل کر Claude Code کے لیے سیشنز کے درمیان ایک تنظیمی لیر فراہم کرتا ہے۔

مضمون کا مصنف، ذریعہ: Leifeng.com

چند دنوں سے، Anthropic نے Claude Code میں ایک نئی تجرباتی صلاحیت شامل کی ہے: Cross-session messaging، یعنی سیشن کے درمیان پیغام رسانی۔

بس اس سے آپ کئی Claude Code سیشنز کو ایک ساتھ چلائیں اور ان کے درمیان براہ راست پیغامات بھیج سکتے ہیں۔

مثلاً آپ نے 3 کلاؤڈ کوڈ سیشنز کھولے ہیں: ایک ڈیٹا بیس کے لیے، ایک بیک اینڈ API کے لیے، اور ایک ٹیسٹنگ کے لیے۔ پہلے یہ تینوں سیشنز ایک ساتھ کام کر سکتے تھے، لیکن وہ ایک دوسرے کے کام کے بارے میں نہیں جانتے تھے۔ ڈیٹا بیس سیشن کے بعد اسکیما میں تبدیلی کرنے پر، عام طور پر ڈویلپر کو دوسرے ٹرمینل پر جا کر تبدیلیوں کو بیک اینڈ سیشن کو دوبارہ بتانا پڑتا تھا۔

کراس سیشن میسج کو شامل کرنے کے بعد، یہ مرحلہ براہ راست کلاؤڈ کے ذریعے مکمل کیا جا سکتا ہے۔ ڈیٹا بیس سیشن بیک اینڈ سیشن کو اطلاع دے سکتا ہے کہ کون سے فیلڈز میں تبدیلی آئی ہے، ٹیسٹ سیشن جب انٹرفیس ریگریشن مسائل کا پتہ چلتا ہے، تو وہ متعلقہ کوڈ میں تبدیلی کر رہے سیشن کو نتائج بھیج سکتا ہے۔ کلاؤڈ خود فیصلہ کر سکتا ہے کہ کب دوسرے سیشن کو اطلاع دینا ضروری ہے، یا ڈویلپر کی درخواست پر مخصوص سیشن سے رابطہ کر سکتا ہے۔

اس کے کیا کام ہے، اسے سمجھنے کے لیے ایک پیغام کی مکمل راہ کو ٹریس کریں: یہ کیا بھیجتا ہے، ہدف تک کیسے پہنچتا ہے، پیغام کب کلاؤڈ میں داخل ہوتا ہے، اور وصول کنندہ کیوں براہ راست اسے نہیں کر سکتا۔

01

کراس سیشن میسیجنگ نے کلود کوڈ کے اصل سیشن آئیسلیشن کو تبدیل نہیں کیا۔

جب سیشن A، سیشن B کو پیغام بھیجتا ہے، تو اپنا مکالمہ کا تاریخہ، پڑھے گئے فائلیں یا پورا کنٹیکس ونڈو نہیں بھیجتا۔ عہدہ کے مطابق، سیشن کے درمیان صرف متن ہی منتقل ہوتا ہے۔ اگر آپ مکمل مکالمہ اور کنٹیکس کو دوسرے ٹرمنل پر منتقل کرنا چاہتے ہیں، تو آپ کو کراس-سیشن میسنجرنگ کے بجائے اصل سیشن کو دوبارہ شروع کرنا چاہئے۔

یہ کلیدی طور پر متعدد کلاؤڈ کے درمیان تعاون کا طریقہ طے کرتا ہے۔

فرض کریں کہ ڈیٹا بیس سیشن کو مائیگریشن مکمل کرنے کے لیے دہائیوں فائلیں پڑھنی پڑیں اور کئی منصوبوں کی کوشش کرنی پڑی، جس کے بعد یہ طے ہوا کہ کسی فیلڈ میں تبدیلی کی ضرورت ہے۔ بیک اینڈ سیشن کو پچھلے تمام تجزیاتی مراحل کے بارے میں علم ہونا ضروری نہیں، صرف آخری تبدیلیاں اور ان کا اپنے API پر کیا اثر ہوگا، یہ جاننا کافی ہے۔

اس لیے، Cross-session messaging کام کے نتائج اور انحصار کی معلومات منتقل کرتا ہے، مکمل ورک میموری نہیں۔

اس کا فائدہ یہ ہے کہ مختلف کاموں سے پیدا ہونے والی مقامی معلومات دوسرے سیشن میں لگاتار نہیں آئیں گی۔ ڈیٹا بیس سے متعلق تفصیلات ڈیٹا بیس سیشن میں رہ سکتی ہیں، ٹیسٹنگ کے عمل کو ٹیسٹ سیشن میں رہنے دیا جا سکتا ہے، اور صرف اس صورت میں جب کوئی تبدیلی دوسرے کاموں کو متاثر کرنے لگے تو متعلقہ معلومات سیشن کے حدود کو عبور کریں گی۔

یہ "تمام ایجینٹس ایک بڑا کنٹیکس شیئر کرتے ہیں" کے مختلف خیالات میں سے ایک ہے۔ کراس سیشن میسجنگ سیشنز کو الگ رکھنے کا انتخاب کرتی ہے اور صرف اس صورت میں ضروری حالت کو واضح طور پر سینکرن کرتی ہے جب کاموں میں منحصری پیدا ہو۔

چونکہ ایک واضح پیغام بھیجا جا رہا ہے، اگلا سوال یہ ہے کہ سیشن A، سیشن B کو کیسے تلاش کرے؟

02 دوسرے سیشن کو تلاش کرنا ہوگا

کلود کوڈ نے کراس سیشن میسجنگ کی سہولت فراہم کرنے والے سیشن کے لیے اپنا مواصلاتی دروازہ شامل کیا۔

ہر مقامی سیشن متعلقہ معلومات کو ڈسک پر رجسٹر کرتا ہے اور ایک ان بک سوکٹ سے جوڑتا ہے۔ کلوڈ ListAgents کے ذریعے موجودہ رابطہ کرنے کے قابل سیشنز تلاش کر سکتا ہے اور SendMessage کے ذریعے پیغام مخصوص مقصد کو بھیج سکتا ہے۔

صارف کو ان اندری ٹولز کو خود چلانے کی ضرورت نہیں، صرف کلوڈ کو بتائیں کہ وہ کس سیشن سے رابطہ کرنا چاہتے ہیں، یا اسے یہ کہیں کہ جب کوئی ٹاسک مзалہ بن جائے تو وہ خود بخود دوسرے کو نوٹیفائی کر دے۔

اس لیے سیشن کے نام کو بھی پتہ لگانے میں شامل کیا جاتا ہے۔ کلوڈ نام کے ذریعے مقصد کو تلاش کر سکتا ہے؛ اگر نام دہرایا جائے تو سسٹم مختصر شناخت کے ساتھ فرق کرتا ہے، جبکہ ہر سیشن کے لیے کام کرنے والے ڈائریکٹری کو ظاہر کرتا ہے تاکہ یہ طے کیا جا سکے کہ ہر سیشن کون سا پروجیکٹ یا ڈائریکٹری سنبھال رہا ہے۔

مقصد کو تلاش کرنے کے بعد، یہ پیغامات متعلقہ سیشن کے ذریعے سوکٹ پر ب без واسطہ بھیجے جاتے ہیں، اینتھروپک سرور کے ذریعہ نہیں۔ دوسری مشین یا کلوڈ کوڈ ویب پر موجود سیشنز صرف اینتھروپک سرور اور ریموٹ کنٹرول کنکشنز کے ذریعہ مواصلات کرتے ہیں۔

یہ دریافت کا نظام مقامی مواصلات کے حدود کو بھی طے کرتا ہے۔

کلود کوڈ کو دیگر سیشن کے ذریعہ ڈسک پر لکھے گئے رجسٹریشن کے معلومات کو پڑھنا ہوتا ہے، اس لیے دو کلود، چاہے وہ ایک ہی کمپیوٹر پر فزیکلی چل رہے ہوں، اگر فائل سسٹم آپس میں الگ ہوں تو ایک دوسرے کو تلاش نہیں کر سکتے۔ عام صورتحال ہوسٹ اور الگ کنٹینر ہوتی ہے؛ اگر دونوں سیشن ایک ہی کنٹینر میں چل رہے ہوں، تو وہ عام طور پر مکمل طور پر مواصلات کر سکتے ہیں۔

Inbox Socket کو آپریٹنگ سسٹم کے صارف اجازتوں کی حدود کے تحت رکھا گیا ہے، اس لیے شیئرڈ سرور پر دیگر OS صارفین آپ کے سیشن تک براہ راست رسائی نہیں رکھ سکتے۔

اس لیے یہاں "مقامی مواصلات" کا مطلب دراصل یہ ہے کہ رجسٹریشن کی معلومات دستیاب ہیں، سوکٹ دستیاب ہے، اور آپریٹنگ سسٹم رسائی کی اجازت دے رہا ہے۔

ابھی پیغام کو ہدف تک پہنچایا گیا ہے اور Inbox میں بھیج دیا گیا ہے، اب Claude Code کے Runtime کا دور آ گیا ہے کہ وہ اس پیغام کو ماڈل کو کب دے۔

03 معلومات کے ارسال کے بعد

فرض کریں کہ بیک اینڈ سیشن فائل کو تبدیل کر رہا ہے، اسی دوران ٹیسٹ سیشن نے پیغام بھیجا ہے جس میں بتایا گیا ہے کہ اس نے ایک انٹرفیس ریگریشن مسئلہ دریافت کیا ہے۔

کلود کوڈ کسی چل رہے ٹول کو فوراً نہیں روکے گا۔

اگر ہدف کا سیشن آرام کی حالت میں ہے، تو پیغام ایک نیا ٹرن شروع کر سکتا ہے؛ اگر کلود پہلے سے فعال ٹرن میں ہے، تو پیغام دو ٹول کال کے درمیان انتظار کرے گا۔

اس کا سبب اور Coding Agent کے عمل کا طریقہ ہے۔ کلوڈ فائل لکھ رہا ہو سکتا ہے، ٹیسٹ چلا رہا ہو سکتا ہے، مائیگریشن کر رہا ہو سکتا ہے یا دوسرے لمبے وقت لینے والے کاموں کو پورا کر رہا ہو سکتا ہے۔ اگر باہری پیغام کسی بھی وقت موجودہ عمل کو تبدیل کر سکتا ہے، تو اس سے یہ امکان بڑھ جاتا ہے کہ ٹول صرف ایک حصہ ہی انجام دے پائے اور ایجینٹ پہلے ہی نئی معلومات کے مطابق دوبارہ منصوبہ بندی شروع کر چکا ہو۔

اس لیے پیغام کا اثر کلود کے اگلے فیصلوں پر پڑتا ہے، جبکہ جاری عمل کو براہ راست نہیں روکتا۔

اس کا مطلب یہ بھی ہے کہ Cross-session messaging کو Claude Code کے Agentic Loop میں شامل کر دیا گیا ہے، جو ایک ای سینکرون ان پٹ ذریعہ بن گیا ہے۔ اور یہ دروازہ صرف دیگر Claude Session کے لیے ہی محدود نہیں ہے۔

کلود کوڈ موجودہ سیشن کا میسجنگ سوکٹ ہوک اور باش کے شروع کردہ بچہ پروسیس کو ظاہر کر دے گا۔ ایک لمبے عرصے تک چلنے والے بیک گراؤنڈ کام کے ختم ہونے کے بعد، وہ اپنا نتیجہ فوراً موجودہ سیشن میں بھیج سکتا ہے، جس سے کلود کو اس کے مکمل ہونے کا انتظار کرنے کی ضرورت نہیں پڑتی۔

یہ چینل خود معتبر میسج کیو نہیں ہے۔ دہرائے گئے میسجز پر ریٹ لِمٹ لگا ہے، اور ایک مختصر عرصے میں ایک جیسے مواد کو حذف کر دیا جا سکتا ہے؛ جو میسجز قبول کر لیے گئے ہیں لیکن Claude نے ابھی تک نہیں پڑھے، ان میں سے ہر سیشن کے لیے زیادہ سے زیادہ 50 میسجز محفوظ رکھے جاتے ہیں، جبکہ ہولڈ حالت میں داخل ہونے والے میسجز کے لیے الگ بفر استعمال کیا جاتا ہے جس میں زیادہ سے زیادہ 100 میسجز محفوظ رکھے جا سکتے ہیں۔

اس لیے یہ حالت کے تبدیلی، کام کے نتائج اور تعاونی اطلاعات بھیجنے کے لیے زیادہ مناسب ہے۔ جن حقائق کو لمبے عرصے تک محفوظ رکھنا ضروری ہے، وہ اب بھی Git، فائل، ڈیٹا بیس یا دیگر مستقل نظام میں ریکارڈ کیے جانے چاہئیں۔

میسج رن ٹائم میں داخل ہونے کے بعد، فوری طور پر ایک عمل میں تبدیل نہیں ہو سکتا، کیونکہ ریسیور کو پہلے یہ جاننا ہوگا کہ دوسرے کلاؤڈ سے آنے والی معلومات کا کتنی اجازت کا درجہ ہے۔

04 اجازتیں کیسے ورثہ میں ملتی ہیں

کلود کوڈ صارف پیغام اور پیئر سیشن پیغام کو واضح طور پر الگ کرتا ہے۔

دوسرا سیشن سے بھیجے گئے مواد کو صارف کی اجازت نہیں سمجھا جائے گا، اس لیے یہ صارف کے لیے اجازت پرامپٹ کو منظور نہیں کر سکتا، اور نہ ہی پیغام کے ذریعے接收方 کو اجازت سیٹنگز،CLAUDE.md یا دیگر ترتیبات تبدیل کرنے کا مطالبہ کر سکتا ہے۔ پیغام میں چاہے Claude Code Command شامل ہو، وہ صرف عام متن کے طور پر ہی سمجھا جائے گا۔

اگر سیشن A سیشن B سے ایک فائل کو حذف کرنے کا درخواست کرتا ہے، اور یہ عمل سیشن B میں صارف کی اجازت کی ضرورت رکھتا ہے، تو اصل اجازت درخواست اب بھی ظاہر ہوگی۔

کلود کوڈ دوسرے اجازت چھلانگ کے طریقے کو بھی محدود کرتا ہے: اگر کوئی آپریشن موجودہ سیشن میں اجازت سسٹم کے ذریعے مسترد ہو چکا ہے، تو کلود کو اپنے لیے دوسرے سیشن سے انجام دلانے کا درخواست نہیں کرنا چاہیے۔

ورنہ، صرف کچھ سیشنز کے اختیارات مختلف ہونے پر، کم اختیارات والے سیشن مسلسل اپنے کاموں کو زیادہ اختیارات والے سیشن کو منتقل کرتے رہیں گے، جس سے اصل اختیار کی سرحدیں ختم ہو جائیں گی۔

ایکسیس کے اختیارات کے باہر، پیغام خود میں ایک Inbound Control کا درجہ رکھتا ہے۔ وصول کنندہ کراس سیشن پیغامات کو accept،hold یا refuse کے طور پر سیٹ کر سکتا ہے: براہ راست Claude کو دے دیں، مزید تصدیق کے لیے عارضی طور پر محفوظ رکھیں، یا براہ راست حذف کر دیں۔

اگر صارف نے قواعد کو واضح طور پر ترتیب نہیں دیا ہے، تو کلوڈ کوڈ فریقین کے موجودہ اجازت موڈ کو بھی مدنظر رکھتا ہے۔ عام اجازت پرومپٹ کو دور کرنے والی سیشن، عام سیشن کے ساتھ ایک جیسے میسج سرچ کے طور پر نہیں سمجھی جاتی؛ جب接收端 کی اپنی اجازت زیادہ بلند ہو، تو باہری میسجز بھی Hold میں داخل ہو سکتے ہیں۔

یہاں دراصل دو جانچ ہیں: پہلے فیصلہ کریں کہ پیغام کلوڈ میں داخل ہو سکتا ہے یا نہیں، پھر فیصلہ کریں کہ کلوڈ اس پیغام کے مطابق انجام دینے کے لیے تیار کیا گیا ایکشن اس کے لیے اجازت رکھتا ہے یا نہیں۔

اس مرحلے تک، ایک کراس سیشن میسج کا مکمل راستہ مکمل ہو چکا ہے: میسج کی تخلیق، مقصد کی دریافت، ڈلیوری کا مکمل ہونا، Runtime کے ذریعہ میسج کو پڑھنا، اور پھر ریسیور کی اپنی اجازت کنٹرول سے گزرنا۔

05 سیشن کے درمیان کوآرڈینیشن لیئر

اس لنک کو کلود کوڈ کی موجودہ صلاحیتوں میں واپس رکھنا، کراس سیشن میسنجرنگ کی جگہ کو زیادہ واضح کر دے گا۔

سیشن کو جاری رکھنے کے لیے Resume Session استعمال کریں، ایجنٹ ٹیمز کو ایک معاون ایجنٹس کے گروپ بنانے اور ان کا انتظام کرنے کے لیے استعمال کریں، ورک ٹری مختلف سیشنز کے کوڈ میں تبدیلیوں کو الگ رکھتا ہے، اور ریموٹ کنٹرول دوسرے ڈیوائس سے سیشن پر کنٹرول جاری رکھنے کا حل فراہم کرتا ہے۔

کراس-سیشن میسجنگ ایک دوسری صورت حال کو سنبھالتا ہے: کچھ ایسے سیشن جو اصل میں الگ الگ چل رہے ہیں، لیکن ان کے کام کے دوران ایک دوسرے پر منحصر ہو جاتے ہیں، اور ان کے درمیان ضروری معلومات کیسے منتقل کی جائیں۔

پہلے، کلائیڈ کوڈ سیشنز کے متعدد انشیئرز کھولنا بنیادی طور پر متوازی مسئلہ حل کرنے کے لیے تھا، لیکن ڈیولپرز کو اب بھی مختلف ٹرمینلز کی پیشرفت کا مشاہدہ کرنا پڑتا تھا اور ان کے درمیان اور سیشنز کے درمیان مسلسل ٹاسک کی حالت کا تبادلہ کرنا پڑتا تھا۔ اب، انٹرفیس میں تبدیلی، ٹیسٹ نتائج، اور مائیگریشن مکمل ہونے جیسی معلومات براہ راست متاثرہ سیشنز تک بھیجی جا سکتی ہیں۔

کراس سیشن میسجنگ نے متعدد کلاؤڈ کو ایک ایجنٹ میں ضم نہیں کیا، بلکہ موجودہ کنٹیکس، ورکنگ ڈائریکٹری اور اجازت کے سرحد کے باہر ایک مواصلاتی صلاحیت شامل کی ہے۔

بڑے پروجیکٹ کے حوالے سے دیکھنے پر، یہ ڈیزائن ایک اور متعدد ایجنٹس کا طریقہ فراہم کرتا ہے: مختلف ایجنٹس کو بڑھتے ہوئے کنٹیکس کو شیئر کرنے کی ضرورت نہیں ہوتی، بلکہ وہ واضح مواصلات کے انٹرفیس کے ذریعے تعاون کر سکتے ہیں۔ جب ٹاسک، حالت اور اجازتیں الگ کر دی جائیں، تو سسٹم زیادہ آسانی سے وسعت پا سکتا ہے۔

جب ایجینٹس کی تعداد مزید بڑھتی جائے گی، تو سوال "ایک ایجینٹ کتنی باتیں کر سکتا ہے" سے آہستہ آہستہ "ان ایجینٹس کے درمیان حالتیں، انحصار اور ہاتھ بدلنا مستقل طور پر کیسے منتقل ہو سکتے ہیں" کی طرف منتقل ہو جائے گا۔

کراس سیشن میسیجنگ، ہاں، صرف ایک ہی ہنگامہ کو حل کرتی ہے، لیکن اب Claude Code کے متعدد سیشن کے طریقہ کار میں ایک زیادہ مکمل انجینئرنگ ساخت کا آغاز ہو چکا ہے۔ شاید مستقبل میں، اس مقامی نیٹ ورک کے اندر کراس سیشن میکانزم کو، مشینوں اور ایکوسسٹم کے درمیان ایجنٹ-ٹو-ایجنٹ مواصلات کے معاہدے میں تبدیل کر دیا جائے، تو آج کے دو Claude کے درمیان یہ مختصر مکالمہ، اعلیٰ خودکار سافٹ ویئر فیکٹری کے قائم ہونے کا اہم مرحلہ ہوگا۔