Claude Code سیشنز کو آپس میں پیغام کیسے بھیجیں

Claude Code سیشنز کے باہمی پیغام رسانی کا مطلب

دو Claude Code سیشنز اس وقت ایک دوسرے کو پیغام بھیج سکتے ہیں جب وہ ایک ہی مشین پر، ایک ہی operating system user کے تحت چل رہے ہوں۔ پیغام سادہ متن کا ایک حصہ ہوتا ہے جو ایک Claude دوسرے Claude کے لیے لکھتا ہے۔ اس میں گفتگو کی تاریخ یا کوئی فائل شامل نہیں ہوتی۔ Claude دوسرے سیشن کو ListAgents tool کے ذریعے تلاش کرتا ہے اور متن SendMessage کے ذریعے پہنچاتا ہے، اس لیے آپ کو ان میں سے کسی بھی tool کو دستی طور پر call نہیں کرنا پڑتا۔ آپ بتاتے ہیں کہ دوسرے سیشن کو کیا معلوم ہونا چاہیے، اور Claude خود پیغام لکھ دیتا ہے۔

اس feature کو cross-session messaging کہا جاتا ہے۔ August 2026 تک اس کے لیے Claude Code v2.1.224 یا اس کے بعد کا ورژن درکار ہے، اور یہ macOS اور Linux پر چلتا ہے، جس میں WSL 2 کے اندر موجود Linux بھی شامل ہے۔ Windows کے لیے native support موجود نہیں، اور یہ Amazon Bedrock، Claude Platform on AWS، Google Cloud's Agent Platform، یا Microsoft Foundry پر دستیاب نہیں ہے۔ جب کوئی سیشن ان شرائط پر پورا اترتا ہے تو messaging پہلے ہی فعال ہوتی ہے اور اسے enable کرنے کی ضرورت نہیں ہوتی۔ ذیل میں بیان کیا گیا رویہ cross-session messaging کے لیے Anthropic documentation سے ماخوذ ہے۔

VPS پر یہ feature خاص طور پر مفید ہے، کیونکہ VPS پر سیشن اتنی دیر تک چلتے رہتے ہیں کہ انہیں address کرنا معنی رکھتا ہے۔ Laptop پر آپ lid بند کر دیتے ہیں۔ tmux کے تحت server پر، Monday کو شروع کیا ہوا session Thursday کو بھی چل رہا ہوتا ہے اور ایک repository کا context برقرار رکھتا ہے۔ جب ایسے دو سیشن موجود ہوں تو ان کے باہمی رابطے کا طریقہ محض نظری بات نہیں رہتا۔ اگر آپ نے ابھی یہ setup نہیں کیا تو VPS پر tmux کے تحت Claude Code چلانے سے شروع کریں۔ اس میں وہ session plumbing شامل ہے جسے یہ guide فرض کرتی ہے۔

جب دوسری session پر خرچ کرنا مفید ہو

ابتدا لاگت سے کریں۔ ہر session اپنی الگ context window کے ساتھ Claude کی الگ instance ہوتی ہے، اس لیے ایک ہی مدت میں دو sessions کی لاگت تقریباً ایک session سے دگنی ہوتی ہے۔ Claude کی بھیجی ہوئی message بھی usage میں بالکل اسی طرح شمار ہوتی ہے جیسے آپ کی لکھی ہوئی prompt۔ باہمی رابطہ مفت نہیں ہوتا، اور جو کام دراصل ایک ہی سلسلے کے steps پر مشتمل ہو، اسے sessions میں تقسیم کرنے سے وہ زیادہ سست اور مہنگا ہو جاتا ہے۔

وہ صورتیں جن میں دوسری session اپنی لاگت پوری کرتی ہے، ان میں ایک ہی نمونہ ہوتا ہے۔ کام کے دو حصے ایک دوسرے کا انتظار کیے بغیر بیک وقت چلتے ہیں، اور ان میں سے ایک کو کام کے دوران ایسی معلومات ملتی ہیں جن کی دوسرے کو ضرورت ہوتی ہے۔

• ایک session breaking change تلاش کرتی ہے، جبکہ دوسری اسی code پر کام کر رہی ہوتی ہے جسے اس تبدیلی نے متاثر کیا ہے۔ Claude تبدیلی کا خلاصہ بنا کر بھیج دیتا ہے، اس لیے آپ کو اسے دوسرے terminal میں دوبارہ type نہیں کرنا پڑتا۔
• دو sessions ایک ہی repository پر الگ git worktrees میں کام کرتی ہیں، اور ایک کو معلوم کرنا ہوتا ہے کہ کیا شامل ہو چکا ہے۔
• طویل migration یا test run اپنا نتیجہ اس session کو واپس بھیجتا ہے جسے آپ دیکھ رہے ہوتے ہیں۔
• ایک builder session اور ایک reviewer session، جہاں reviewer، builder کے تیار کردہ output کو پڑھ کر اپنی دریافت کردہ معلومات واپس بھیجتا ہے۔

جب کام sequential ہو، یا دونوں sessions ایک ہی files میں ترمیم کریں، تو ایک session استعمال کریں۔ اگر آپ ایسا coordinated group چاہتے ہیں جسے Claude ایک ہی task کے اندر spawn اور supervise کرے، تو وہ agent teams ہے، جو ایک الگ اور اب بھی experimental feature ہے۔ اگر آپ صرف یہی conversation کسی دوسرے terminal میں چاہتے ہیں، تو session resume کریں۔ Cross-session messaging ان independent sessions کے لیے ہے جنہیں آپ خود start اور steer کرتے ہیں۔

اس خصوصیت کے بارے میں منصوبہ بندی سے پہلے تصدیق کریں کہ یہ موجود ہے

پہلے version دیکھیں:

claude --version

اس نمبر کا 2.1.224 سے موازنہ کریں۔ پھر session کے اندر /list-agents ٹائپ کریں، جو /peers کے نام سے بھی دستیاب ہے۔ یہ ان تمام agents کو دکھاتا ہے جن تک یہ session پہنچ سکتا ہے، ساتھ ہی وہ نام بھی دکھاتا ہے جس پر ہر agent جواب دیتا ہے۔ اگر command بالکل بھی پہچانی نہ جائے تو اس session میں cross-session messaging موجود نہیں ہے، اور کوئی settings file اسے فعال نہیں کر سکتی۔ /status ٹائپ کریں اور Peer address والی row تلاش کریں: اس میں اس session کا اپنا inbox address ہوتا ہے، جس کے شروع میں uds: لگا ہوتا ہے۔

ایک مسئلہ خاص طور پر VPS users کو درپیش ہوتا ہے۔ Cross-session messaging کا انحصار feature-flag evaluation پر ہے، اور کئی privacy variables اس evaluation کو بند کر دیتے ہیں، جس کے نتیجے میں یہ feature اپنی default off حالت میں رہتا ہے۔ DO_NOT_TRACK، DISABLE_TELEMETRY، CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC، اور DISABLE_GROWTHBOOK سب یہی کرتے ہیں۔ لوگ نیا server harden کرتے وقت انہیں ~/.bashrc میں paste کر دیتے ہیں، پھر حیران ہوتے ہیں کہ /list-agents موجود نہیں ہے۔ یہی values settings file کے env map یا managed settings سے بھی آ سکتی ہیں، اس لیے پہلے shell چیک کریں۔

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

جو variable value پرنٹ کرے، اسے unset کریں۔ DISABLE_TELEMETRY اور CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC کے لیے کوئی بھی non-empty value اس behaviour کو فعال کر دیتی ہے، جس میں 0 string بھی شامل ہے، اس لیے DISABLE_TELEMETRY=0 بظاہر نظر آنے والا کام نہیں کرتا۔ اسے بند کرنے کے لیے variable کو unset کریں یا اس کی value empty string مقرر کریں۔

اپنے sessions کے نام رکھیں، ورنہ Claude انہیں address نہیں کر سکتا

Claude نام کے ذریعے کسی message کو session سے منسوب کرتا ہے۔ Session شروع کرتے وقت نام مقرر کریں:

claude --name builder-api

آپ چلتے ہوئے session کے اندر /rename کے ذریعے بھی نام مقرر کر سکتے ہیں۔ اگر آپ نام مقرر نہ کریں تو Claude Code working directory کے folder name سے نام اخذ کرتا ہے، مثلاً myapp-3f۔ ایک session کے لیے یہ کافی ہے، لیکن چار sessions کے لیے الجھن پیدا ہوتی ہے، اور دو sessions کا نام ایک جیسا بھی ہو سکتا ہے۔ /list-agents کا output ہر local session کی working directory دکھاتا ہے، جس سے ایک جیسے نام والے sessions میں فرق کیا جا سکتا ہے۔ ناموں کے ٹکرانے کی صورت میں Claude کی اپنی listing address میں ایک مختصر identifier بھی شامل کرتی ہے۔ خود نام رکھنا identifiers پڑھنے سے زیادہ آسان ہے۔

قابلِ تکرار دو-session tmux layout

یہ ایک ہی repository پر builder session اور reviewer session ہے۔ reviewer الگ git worktree میں کام کرتا ہے، اس لیے دونوں کبھی ایک ہی file میں نہیں لکھتے۔ git worktree add کو HEAD کے ساتھ استعمال کرنے سے detached checkout ملتا ہے، جو ایسی session کے لیے موزوں ہے جو commit کرنے کے بجائے صرف پڑھتی ہے۔ دونوں sessions مختلف کام کرتی ہیں، اس لیے reviewer کو اپنا output style دینا مفید ہے۔ اس سے اس session کا system prompt تبدیل ہوتا ہے اور یہ ترتیب ہر turn میں برقرار رہتی ہے، بجائے اس کے کہ ایک بار لکھی گئی instruction کی طرح آہستہ آہستہ غیر مؤثر ہو جائے۔

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 windows کو نام کے مطابق فہرست میں دکھاتا ہے تاکہ آپ مطلوبہ window منتخب کر سکیں۔ builder window میں /list-agents چلائیں۔ آپ کو reviewer-api اس کی working directory ~/src/api-review کے ساتھ نظر آنا چاہیے۔ اگر یہ موجود نہ ہو تو reviewer session نے ابھی startup مکمل نہیں کیا، یا اگلے section میں بیان کردہ دو مسائل میں سے کوئی ایک موجود ہے۔ پھر سادہ زبان میں کوئی کام منتقل کریں:

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

Claude summary لکھ کر اسے بھیجتا ہے۔ آپ message کا متن نہیں لکھتے، اور Claude جو بھیجتا ہے وہ مختلف ہو سکتا ہے۔ reviewer window میں message sender کے نام کے ساتھ conversation میں ظاہر ہوتا ہے۔ اگر وہ session idle ہو تو Claude فوراً اس پر نیا turn شروع کر دیتا ہے۔ اگر session کے mid-turn میں ہو تو message tool calls کے درمیان تک انتظار کرتا ہے، اس لیے چلنے والی command کبھی interrupt نہیں ہوتی۔ Claude کے اسے پڑھ لینے کے بعد message ایک سطری Message from row میں مختصر ہو جاتا ہے، جسے Ctrl+O کھولتا ہے۔ یہ جوڑی اس وقت بہتر کام کرتی ہے جب builder اپنی تبدیلیاں چھوٹی رکھے، کیونکہ محدود diff سے مختصر hand-off بنتا ہے اور دوسری session ایک ہی turn میں review مکمل کر سکتی ہے۔ یہی عادت lazy senior dev skill نافذ کرتی ہے۔

ایک VPS پر کون کس کو دیکھ سکتا ہے

ایک ہی مشین پر پیغام رسانی Anthropic servers سے نہیں گزرتی۔ ہر session registration files کو disk پر لکھتا ہے اور اپنا inbox socket bind کرتا ہے، جبکہ Claude Code ان files کو پڑھ کر آپ کے دوسرے sessions تلاش کرتا ہے۔ اس کے دو نتائج ہیں، اور server پر دونوں اہم ہیں۔

socket آپ کے operating system user تک محدود ہوتا ہے۔ root کے طور پر شروع کیا گیا session اور deploy کے طور پر شروع کیا گیا session ایک دوسرے کو نہیں دیکھ سکتے، چاہے وہ ایک ہی tmux server میں ساتھ ساتھ چل رہے ہوں، کیونکہ ایک user کے sessions دوسرے user کے socket تک رسائی نہیں حاصل کر سکتے۔ دونوں sessions کو ایک ہی user کے طور پر چلائیں۔

container کا اپنا filesystem ہوتا ہے۔ Docker کے اندر موجود session اور host پر موجود session ایک دوسرے تک رسائی نہیں حاصل کر سکتے، کیونکہ وہ ایک ہی registration files نہیں پڑھ رہے ہوتے۔ ایک ہی container کے اندر موجود دو sessions معمول کے مطابق ایک دوسرے کو message بھیج سکتے ہیں۔ اگر آپ isolation کے لیے agents کو containers میں رکھتے ہیں، جیسا کہ disposable VM میں coding agents چلانا، تو توقع رکھیں کہ messaging container کے اندر کام کرے گی، لیکن container boundary کے پار نہیں۔

دوسری machines اور web پر موجود آپ کے sessions listing میں صرف اس وقت دکھائی دیتے ہیں جب Remote Control connected ہو، اور انہیں اسی حیثیت سے label کیا جاتا ہے۔ یہاں موجود Claude صرف ایسے session سے موصول ہونے والے message کا جواب دے سکتا ہے۔ یہ خود اس exchange کو شروع نہیں کر سکتا۔

آپ کا پیغام کبھی کیوں نہیں پہنچا

عام طور پر اس کی وجہ network نہیں ہوتی۔ وصول کرنے والا session خود فیصلہ کرتا ہے کہ پیغام کے ساتھ کیا کرنا ہے، اور اس نے اسے deliver نہ کرنے کا فیصلہ کیا ہوتا ہے۔ ہر آنے والا پیغام تین میں سے ایک نتیجے پر ختم ہوتا ہے: deliver، hold (آپ کی منظوری تک deliver کیے بغیر الگ رکھنا)، یا refuse (deliver کیے بغیر حذف کر دینا)۔

جب کوئی crossSessionInbound value لاگو نہ ہو، تو Claude Code دونوں sessions کے permission modes کا موازنہ کرکے ہر پیغام کے لیے فیصلہ کرتا ہے۔ وہ ان sessions کو ایک class میں رکھتا ہے جو permission prompts کو bypass کرتے ہیں، اور باقی تمام sessions کو دوسری class میں۔ auto، acceptEdits، اور dontAsk کو prompting شمار کیا جاتا ہے۔ ایسے session میں Plan mode کو bypassing شمار کیا جاتا ہے جس میں bypass permissions دستیاب ہوں۔ اگر آپ کو یقین نہ ہو کہ کوئی session کس class میں آتا ہے، تو پہلے ہر permission mode کا اصل کام پڑھ لینا مفید ہے، کیونکہ زیادہ تر sessions اب auto سے شروع ہوتے ہیں، اور یہ اس تقسیم میں prompting والی جانب ہے۔ پھر اصول دونوں سمتوں میں یکساں رہتا ہے:

• جو receiving session permissions کے لیے prompt کرتا ہے، اسے ہر پیغام deliver کیا جاتا ہے۔ یہ صرف اس وقت ایک پیغام hold کرتا ہے جب sending session خود کو prompts bypass کرنے والا ظاہر کرے۔
• جو receiving session prompts bypass کرتا ہے، وہ ہر پیغام آپ کی منظوری کے لیے hold کرتا ہے۔ یہ صرف اس وقت پیغام deliver کرتا ہے جب sender بھی bypassing ہو۔

اس لیے زیادہ تر لوگ جو پہلا workflow بناتے ہیں، عین وہی کام نہیں کرتا۔ آپ builder کو --permission-mode bypassPermissions کے ساتھ شروع کرتے ہیں تاکہ وہ unattended چلتا رہے، reviewer کو default settings پر چھوڑ دیتے ہیں، اور builder کا ہر پیغام ایسے approval dialog میں انتظار کرتا رہتا ہے جسے کوئی نہیں دیکھ رہا۔ یہ dialog dialogExpiry deadline کے بعد بند ہو جاتا ہے، جس کی default value 5m ہے، اور پیغام حذف کر دیا جاتا ہے۔ اسی machine پر sending session کو اطلاع ملتی ہے جب اس کا پیغام hold ہو، اور receiver کے بعد میں اسے deliver، deny یا expire کرنے پر follow-up اطلاع بھی ملتی ہے، اس لیے socket کو مورد الزام ٹھہرانے سے پہلے sender کی screen دیکھیں۔

کسی session کو messages unattended لینے کے قابل بنانے کے لیے crossSessionInbound کو accept پر set کریں۔ اسے کہاں set کیا جاتا ہے، اس سے طے ہوتا ہے کہ یہ کہاں لاگو ہوگا۔ Claude Code پہلے managed settings، پھر --settings flag، اور پھر user settings پڑھتا ہے، اور جو پہلی value ملے اسے لاگو کرتا ہے۔ project یا local settings میں موجود value صرف اسی وقت لاگو ہوتی ہے جب وہ accept < hold < refuse کی ladder کے مطابق زیادہ strict ہو۔ accept میں موجود .claude/settings.json ہر چیز سے زیادہ loose ہے، اس لیے جب کسی trusted source نے value set کی ہو تو اسے نظرانداز کیا جاتا ہے۔ اسے ~/.claude/settings.json میں رکھیں، یا ایک session کے لیے اسے pass کریں:

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

ایک headless claude -p worker interactive session کی طرح inbox socket bind کرتا ہے اور listing میں ظاہر ہوتا ہے، لیکن یہ approval dialog نہیں دکھا سکتا۔ وہاں held پیغام اس وقت تک hold رہتا ہے جب تک mode یا settings میں بعد کی تبدیلی اسے allow نہ کرے۔ اوپر موجود --settings line ایسے worker کو messages لینے کی اجازت دینے کا طریقہ ہے۔ bare mode میں شروع کیا گیا session کوئی socket bind نہیں کرتا، اس لیے وہ messages وصول بھی نہیں کر سکتا اور list میں ظاہر بھی نہیں ہو سکتا۔

جہاں hand-offs تعطل کا شکار ہو جاتے ہیں

Message loops خودکار طور پر سنبھالے جاتے ہیں۔ Claude Code ہر sender کے repeated messages پر rate limit لگاتا ہے، مختصر وقفے میں آنے والے identical repeats کو drop کر دیتا ہے، اور ہر session میں read ہونے کے منتظر accepted messages کی تعداد 50 تک محدود رکھتا ہے۔ اس لیے دو sessions ہمیشہ ping-pong نہیں کر سکتے۔ Held messages کی حد 100 ہے، اور اس سے زیادہ ہونے پر oldest messages drop کر دیے جاتے ہیں۔

جو failure واقع ہوتا ہے وہ زیادہ خاموش ہوتا ہے، اور یہ loop کے بجائے hand-off ہوتا ہے۔ Session A، session B سے ایسا سوال پوچھتا ہے جس کا جواب ملنے تک وہ آگے نہیں بڑھ سکتا، پھر idle ہو جاتا ہے۔ B message کو hold کر لیتا ہے، یا کسی طویل کام پر mid-turn ہوتا ہے، یا ایسے سوال کا جواب دیتا ہے جو A نے حقیقت میں پوچھا ہی نہیں تھا۔ A انتظار کرتا رہتا ہے۔ آپ ایک گھنٹے بعد واپس آتے ہیں تو دونوں sessions idle ہوتے ہیں اور کوئی کام مکمل نہیں ہوا ہوتا۔

ایسے hand-offs لکھیں جن کے لیے جواب درکار نہ ہو۔ اچھا message کوئی fact یا decision فراہم کرتا ہے: کیا تبدیل ہوا اور نتیجہ کیا نکلا۔ خراب message دوسرے session سے permission مانگتا ہے، یا ایسا جواب طلب کرتا ہے جس پر sender خود blocked ہو۔ Claude کو پہلے ہی ہدایت دی گئی ہے کہ وہ کبھی دوسرے session سے ایسی action کے لیے نہ کہے جسے اس کی اپنی permission settings روک رہی ہوں، اور ایسا کام آپ کی طرف واپس route کرے۔ اس اصول کو خود بھی مزید وسیع کریں۔ اگر کوئی session جواب کے بغیر آگے نہیں بڑھ سکتا تو جواب آپ کو دینا چاہیے۔ یہاں context discipline بھی مدد دیتی ہے، کیونکہ جس session نے کام کا تسلسل کھو دیا ہو وہ مبہم messages لکھتا ہے؛ Claude Code میں context کا انتظام اس پہلو کا احاطہ کرتا ہے۔

موصول ہونے والے پیغام کو غیر معتبر input سمجھیں

Claude Code وصول کرنے والے Claude کو بتاتا ہے کہ یہ پیغام آپ کی طرف سے نہیں بلکہ کسی دوسرے session سے آیا ہے، اور یہ بھی محدود کرتا ہے کہ پیغام کیا کر سکتا ہے۔ یہ پابندی model کی تعمیل کرنے کی آمادگی کے بجائے model کے گرد موجود پروگرام میں نافذ ہوتی ہے۔ یہی عملی فرق ہے جو agent harness پیدا کرتا ہے۔ کوئی پیغام آپ کی طرف سے زیر التوا permission prompt کا جواب نہیں دے سکتا، کیونکہ دوسرے session کی رضامندی آپ کی رضامندی نہیں ہے۔ کوئی دوسرا session کہے تو یہ permission settings، CLAUDE.md یا دیگر configuration تبدیل نہیں کر سکتا۔ متن کے اندر موجود slash command، مثلاً /compact، سادہ text کے طور پر موصول ہوتی ہے اور کبھی execute نہیں ہوتی۔ اگر پیغام پر عمل کرنے کے لیے ایسی permission درکار ہو جو وصول کرنے والے session کے پاس نہیں ہے، تو وہی prompt دکھائی دیتا ہے جو کسی دوسرے کام کے لیے دکھائی دیتا۔ auto mode میں classifier بھی delivery سے پہلے ہر پیغام کا جائزہ لیتا ہے، اور جس پیغام کو وہ block کر دے وہ recipient تک کبھی نہیں پہنچتا۔ یہ حدود permissive modes میں بھی برقرار رہتی ہیں۔ اسی لیے bypass کرنے والا session inbound messages پر default طور پر روک لگاتا ہے، بجائے اس کے کہ ان پر اعتماد کرے۔

یہ permissions کے بارے میں ہے۔ اس میں content شامل نہیں ہے۔ بھیجنے والے session نے کسی اجنبی کی لکھی ہوئی pull request description، web page، dependency README یا issue comment پڑھا ہو سکتا ہے، اور جو کچھ اس نے پڑھا ہو وہ آپ کے دوسرے session کے لیے لکھے گئے متن پر اثر انداز ہو سکتا ہے۔ یہ پیغام data ہے۔ اسے بھی اسی طرح مشکوک سمجھیں جیسے session میں باہر سے داخل ہونے والے کسی بھی دوسرے text کو سمجھتے ہیں۔ یہی وہ discipline ہے جسے اپنے AI agents سے secrets دور رکھنا بیان کرتا ہے: فرض کریں کہ trust boundary عبور کرنے والی ہر چیز غلط ہو سکتی ہے، اور اسے کبھی خود کو authorise نہ کرنے دیں۔

اگر آپ اس رویے کو کم کرنا چاہتے ہیں تو 2 controls موجود ہیں۔ crossSessionInbound کو refuse پر set کرنے سے inbound peer messages delivery کے بغیر drop ہو جاتے ہیں۔ project یا local settings سے یہ value ہر دوسرے source پر لاگو ہوتی ہے، کیونکہ یہ ladder میں سب سے سخت value ہے۔ اس session کو sending یا listing سے روکنے کے لیے permission deny rules شامل کریں جن میں SendMessage اور ListAgents کے نام ہوں۔ دونوں کو بغیر کسی specifier کے bare tool names کے طور پر لکھیں۔ isolatePeerMachines کو true پر set کرنے سے اس machine سے باہر کسی session تک کوئی پیغام پہنچنے سے پہلے آپ کی واضح منظوری درکار ہوتی ہے، اور یہ منظوری bypassPermissions mode میں بھی ضروری رہتی ہے۔

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

SendMessage کو deny کرنے سے subagents کو messaging بھی ختم ہو جاتی ہے، کیونکہ دونوں کے لیے یہی tool استعمال ہوتا ہے۔ انکار کرنے والا session اپنے /status یا دوسرے sessions کی listings میں کوئی ظاہری تبدیلی نہیں دکھاتا۔ اس لیے setting کی تصدیق screen کے بجائے session کی configuration سے کریں۔

Bridges اور shared memory MCP servers

اسی عرصے میں کئی third-party projects سامنے آئے جو ملتی جلتی مگر مختلف نوعیت کا کام کرتے ہیں: local agent-to-agent bridges چلنے والے agents کے درمیان متن relay کرتے ہیں، جبکہ MCP (model context protocol) servers متعدد agents کو ایک مشترکہ store فراہم کرتے ہیں، جہاں وہ data پڑھ اور لکھ سکتے ہیں۔ انہیں competitor کے بجائے مختلف ساخت کے حل سمجھیں، اور کوئی بھی install command چلانے سے پہلے اسے project کے اپنے README کے مطابق verify کریں۔ Messaging push طریقے سے کام کرتی ہے، کیونکہ sender متن receiver کی turn میں شامل کرتا ہے۔ Shared store pull طریقے سے کام کرتا ہے، کیونکہ کسی session میں خلل نہیں ڈالا جاتا اور session اگلی بار note دیکھنے پر اسے پڑھتی ہے۔ آہستہ تبدیل ہونے والی status کے لیے pull زیادہ پرسکون طریقہ ہے، لیکن یہ صرف اسی وقت کام کرتا ہے جب session واقعی اسے دیکھے۔

اگر آپ یہ طریقہ اختیار کریں تو اہم سوالات feature list کے بجائے process سے متعلق ہیں۔ Server کس user کے طور پر چلتا ہے، اور یہ system پر کیا کچھ پڑھ سکتا ہے؟ VPS پر MCP servers چلانا میں اس setup کا احاطہ کیا گیا ہے۔ repos کے درمیان agent skills شیئر کرنا اس آسان صورتِ حال کا احاطہ کرتا ہے جس میں آپ sessions کے درمیان live state کے بجائے instructions شیئر کرنا چاہتے ہیں، اور اس سے وہ بہت سے messages ختم ہو جاتے ہیں جو بصورتِ دیگر آپ کو بھیجنے پڑتے۔ وسیع تر تصویر کے لیے VPS پر coding agent چلانا سے آغاز کریں۔

FAQ

میری session میں /list-agents کو تسلیم کیوں نہیں کیا جا رہا؟

اس session میں cross-session messaging دستیاب نہیں ہے۔ پہلے claude --version کو 2.1.224 کے مقابل چیک کریں، کیونکہ اس feature کے لیے یہی version یا اس کے بعد کا version درکار ہے۔ پھر platform چیک کریں، کیونکہ یہ macOS اور Linux پر چلتا ہے، native 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 کے مطلوبہ feature-flag evaluation کو روک دیتا ہے اور feature کو غیر فعال چھوڑ دیتا ہے۔

دوسرے session کو بھیجا گیا میرا message کبھی کیوں نہیں پہنچا؟

اگر /list-agents کام کرتا ہے تو messaging فعال ہے اور کسی مخصوص وجہ سے وہ message رک گیا ہے۔ عام وجہ permission modes ہوتے ہیں۔ جو session permission prompts کو bypass کرتا ہے، وہ ہر inbound message کو آپ کی منظوری تک روک کر رکھتا ہے، جب تک sender بھی bypass نہ کر رہا ہو۔ یہ approval dialog dialogExpiry deadline کے بعد، default طور پر پانچ منٹ بعد، ختم ہو جاتا ہے۔ sending session میں held notice چیک کریں۔ اسے درست کرنے کے لیے ~/.claude/settings.json میں crossSessionInbound کو accept پر set کریں یا اسے --settings کے ساتھ pass کریں، کیونکہ project یا local settings میں موجود accept کو کم سخت value ہونے کی وجہ سے نظرانداز کیا جاتا ہے۔

کیا Docker میں چلنے والا Claude Code session host پر موجود session کو message بھیج سکتا ہے؟

نہیں۔ Sessions disk پر موجود registration files اور ہر session کے لیے الگ inbox socket کے ذریعے ایک دوسرے کو تلاش کرتے ہیں، جبکہ container کا اپنا filesystem ہوتا ہے، اس لیے دونوں ایک ہی files نہیں دیکھ سکتے۔ ایک ہی container کے اندر موجود دو sessions معمول کے مطابق ایک دوسرے کو message بھیج سکتے ہیں۔ یہی اصول بتاتا ہے کہ root کے طور پر چلنے والا session اور آپ کے normal user کے طور پر چلنے والا session ایک دوسرے تک کیوں نہیں پہنچ سکتے: socket صرف اس operating system user تک محدود ہوتا ہے جو اس کا مالک ہو۔

کیا دوسرے Claude Code session سے آنے والے message پر عمل کرنا محفوظ ہے؟

اس text کو غیر معتبر input سمجھیں، کیونکہ sending session نے ممکن ہے کوئی web page، README یا کسی دوسرے شخص کا لکھا ہوا issue comment پڑھا ہو۔ Claude Code پہلے ہی message کو خود عمل کرنے سے روکتا ہے: یہ pending permission prompt کو approve نہیں کر سکتا، درخواست پر permission settings یا CLAUDE.md تبدیل نہیں کر سکتا، اور text میں موجود slash command plain text کے طور پر پہنچتی ہے اور کبھی run نہیں ہوتی۔ یہ protections permissions کا احاطہ کرتی ہیں، judgement کا نہیں۔ اس لیے receiving session کو اس پر عمل کرنے کی ہدایت دینے سے پہلے موصولہ text پڑھیں۔

کیا cross-session messaging میرا code Anthropic کو بھیجتی ہے؟

ایک ہی machine پر موجود دو sessions کے درمیان ایسا نہیں ہوتا۔ Message اسی machine پر موجود per-session socket کے ذریعے منتقل ہوتا ہے اور Anthropic servers سے نہیں گزرتا۔ صرف Claude کا لکھا ہوا text بھیجا جاتا ہے، conversation history یا files نہیں۔ آپ کی دوسری machines پر موجود session یا web پر موجود session کو بھیجے گئے messages Anthropic servers کے ذریعے Remote Control connection پر منتقل ہوتے ہیں۔ اس سمت میں Claude صرف موصول ہونے والے message کا جواب دے سکتا ہے، خود message شروع نہیں کر سکتا۔ machine سے باہر کچھ بھی بھیجنے سے پہلے اپنی approval لازم کرنے کے لیے isolatePeerMachines کو true پر set کریں۔