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

Claude Code سیشنز کا ایک دوسرے کو پیغام بھیجنے کا مطلب

دو Claude Code سیشنز ایک دوسرے کو اس وقت پیغام بھیج سکتے ہیں جب وہ ایک ہی مشین پر اور ایک ہی operating system user کے تحت چل رہے ہوں۔ پیغام plain text کا ایک حصہ ہوتا ہے جو ایک Claude دوسرے Claude کے لیے لکھتا ہے۔ اس میں گفتگو کی history یا کوئی فائل شامل نہیں ہوتی۔ Claude دوسرے سیشن کو ListAgents tool سے تلاش کرتا ہے اور متن SendMessage کے ذریعے پہنچاتا ہے، اس لیے آپ کو دونوں tools خود چلانے کی ضرورت نہیں ہوتی۔ آپ بتاتے ہیں کہ دوسرے سیشن کو کیا معلوم ہونا چاہیے، اور 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 پہلے سے فعال ہوتی ہے، اور اسے فعال کرنے کے لیے کسی اضافی configuration کی ضرورت نہیں ہوتی۔ ذیل میں بیان کردہ طریقۂ کار cross-session messaging سے متعلق Anthropic documentation سے ماخوذ ہے۔

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

جب دوسری session اضافی tokens کا جواز بنتی ہے

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

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

• ایک session breaking change تلاش کرتی ہے، جبکہ دوسری اس code پر کام کر رہی ہوتی ہے جس میں وہ تبدیلی آ چکی ہے۔ Claude اس تبدیلی کا خلاصہ بنا کر بھیج دیتا ہے، لہٰذا آپ کو اسے دوسرے terminal میں دوبارہ لکھنا نہیں پڑتا۔
• دو sessions ایک ہی repository پر الگ git worktrees میں کام کرتی ہیں، اور ایک session کو معلوم کرنا ہوتا ہے کہ کیا شامل کیا گیا ہے۔
• طویل migration یا test run اپنا نتیجہ اس session کو واپس بھیجتا ہے جسے آپ monitor کر رہے ہوتے ہیں۔
• ایک 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 کرتے ہیں۔

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

پہلے ورژن دیکھیں:

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 صارفین کے لیے ایک خاص مسئلہ موجود ہے۔ Cross-session messaging کا انحصار feature-flag evaluation پر ہوتا ہے، اور کئی privacy variables اس evaluation کو بند کر دیتے ہیں، جس سے یہ سہولت اپنی default off حالت میں رہتی ہے۔ DO_NOT_TRACK، DISABLE_TELEMETRY، CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC اور DISABLE_GROWTHBOOK یہ سب یہی اثر ڈالتے ہیں۔ لوگ نئے server کو سخت بنانے کے لیے انہیں ~/.bashrc میں paste کر دیتے ہیں، پھر حیران ہوتے ہیں کہ /list-agents موجود کیوں نہیں ہے۔ یہی values settings file کے env map یا managed settings کے ذریعے بھی آ سکتی ہیں، اس لیے پہلے shell کی جانچ کریں۔

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

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

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

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

claude --name builder-api

آپ running 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 کرنے کے بجائے صرف پڑھتی ہے۔

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 کو نام کے مطابق list کرتا ہے تاکہ آپ ایک window منتخب کر سکیں۔ builder window میں /list-agents چلائیں۔ آپ کو reviewer-api اس کی working directory ~/src/api-review کے ساتھ نظر آنا چاہیے۔ اگر یہ موجود نہ ہو تو reviewer session نے ابھی start نہیں کیا، یا اگلے 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 ایک سطری Message from row میں تبدیل ہو جاتا ہے، جسے Ctrl+O expand کرتا ہے۔ یہ جوڑا اس وقت بہتر کام کرتا ہے جب builder اپنی تبدیلیاں مختصر رکھے، کیونکہ narrow diff سے مختصر hand-off بنتا ہے اور review دوسری session ایک ہی turn میں مکمل کر سکتی ہے۔ یہی عادت 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 پر موجود آپ کے sessions اور web پر موجود sessions listing میں صرف اس وقت دکھائی دیتے ہیں جب Remote Control connected ہو، اور انہیں اسی حیثیت سے label کیا جاتا ہے۔ یہاں Claude صرف اس message کا جواب دے سکتا ہے جو ان میں سے کسی ایک کی طرف سے موصول ہوا ہو۔ وہ خود اس exchange کا آغاز نہیں کر سکتا۔

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

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

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

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

اس لیے زیادہ تر لوگ جو پہلا workflow بناتے ہیں، وہی عین وہ workflow ہے جو کام نہیں کرتا۔ آپ builder کو --permission-mode bypassPermissions کے ساتھ شروع کرتے ہیں کیونکہ آپ چاہتے ہیں کہ وہ unattended چلتا رہے، reviewer کو default settings پر چھوڑ دیتے ہیں، اور builder کا ہر پیغام ایسے approval dialog میں انتظار کرتا رہتا ہے جسے کوئی دیکھ نہیں رہا۔ یہ dialog dialogExpiry deadline کے بعد بند ہو جاتا ہے۔ اس deadline کی default value 5m ہے، اور پیغام حذف کر دیا جاتا ہے۔ اسی machine پر sending session کو اس وقت notice ملتا ہے جب اس کا پیغام 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 ہر value سے looser ہوتا ہے، اس لیے 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 پیغام اس وقت تک held رہتا ہے جب تک mode یا settings میں تبدیلی اسے لینے کی اجازت نہ دے۔ اوپر موجود --settings line ایسے worker کو messages لینے کی اجازت دیتی ہے۔ bare mode میں شروع کیا گیا session کوئی socket bind نہیں کرتا، اس لیے نہ messages وصول کر سکتا ہے اور نہ list میں ظاہر ہوتا ہے۔

جہاں hand-offs deadlock ہو جاتے ہیں

Message loops آپ کے لیے خود handle ہوتے ہیں۔ Claude Code ایک ہی sender کی بار بار آنے والی messages پر rate-limit عائد کرتا ہے، مختصر وقفے میں موصول ہونے والی identical repeats کو drop کر دیتا ہے، اور ہر session میں پڑھنے کے لیے زیرِ انتظار 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 لکھیں جن کے لیے reply درکار نہ ہو۔ ایک اچھا message کوئی fact یا decision فراہم کرتا ہے: کیا تبدیل ہوا اور نتیجہ کیا نکلا۔ برا message دوسرے session سے permission مانگتا ہے، یا ایسا جواب طلب کرتا ہے جس پر sender کا کام رکا ہوا ہو۔ Claude کو پہلے ہی ہدایت دی گئی ہے کہ وہ کبھی بھی دوسرے session سے ایسا action کرنے کو نہ کہے جسے اس کی اپنی permission settings روک دیں، اور اس کام کو واپس آپ تک route کرے۔ اس rule کو خود بھی آگے بڑھائیں۔ اگر کوئی session جواب کے بغیر progress نہیں کر سکتا تو جواب آپ کو دینا چاہیے۔ Context discipline بھی یہاں مدد دیتی ہے، کیونکہ thread کھو دینے والا session مبہم messages لکھتا ہے؛ Claude Code میں context کا انتظام اس پہلو کا احاطہ کرتا ہے۔

آنے والے پیغام کو ناقابل اعتماد input سمجھیں

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

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

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

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

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

Bridges اور shared memory MCP servers

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

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

FAQ

میرے session میں /list-agents کی شناخت کیوں نہیں ہو رہی؟

اس session میں sessions کے درمیان 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-flag evaluation کو روک دیتا ہے جس پر یہ feature منحصر ہے، اور اسے بند رکھتا ہے۔

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

اگر /list-agents کام کرتا ہے تو messaging فعال ہے، اور کسی مخصوص وجہ سے وہ message رک گیا ہے۔ عام وجہ permission modes ہوتے ہیں۔ جو session permission prompts کو bypass کرتا ہے، وہ ہر inbound message کو آپ کی منظوری تک روک کر رکھتا ہے، الاّ یہ کہ sender بھی bypass نہ کرتا ہو۔ یہ approval dialog dialogExpiry deadline کے بعد ختم ہو جاتا ہے، جو بطور default پانچ منٹ ہے۔ بھیجنے والے 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 سمجھیں، کیونکہ بھیجنے والے session نے کوئی web page، README، یا کسی دوسرے شخص کا لکھا ہوا issue comment پڑھا ہو سکتا ہے۔ Claude Code خود message کو براہِ راست عمل کرنے سے روکتا ہے: یہ زیرِ التوا permission prompt کو approve نہیں کر سکتا، request پر permission settings یا CLAUDE.md تبدیل نہیں کر سکتا، اور text میں موجود slash command plain text کے طور پر پہنچتا ہے اور کبھی run نہیں ہوتا۔ یہ تحفظات permissions تک محدود ہیں، judgement تک نہیں۔ اس لیے وصول ہونے والے text کو پڑھنے کے بعد ہی receiving session کو اس پر عمل کرنے کی ہدایت دیں۔

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

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