Claude Code அமர்வுகள் ஒன்றுக்கொன்று செய்தி அனுப்புவது

Claude Code அமர்வுகள் ஒன்றுக்கொன்று செய்தி அனுப்புவதன் பொருள்

ஒரே கணினியில், ஒரே operating system user-ன் கீழ் இயங்கும் இரண்டு Claude Code அமர்வுகள் ஒன்றுக்கொன்று செய்தி அனுப்பிக்கொள்ள முடியும். ஒரு Claude மற்றொரு Claude-க்கு எழுதும் எளிய உரை (plain text) தான் ஒரு செய்தி. இதில் உரையாடல் வரலாறு அல்லது கோப்புகள் எதுவும் இருக்காது. Claude மற்ற அமர்வை ListAgents கருவியைக் கொண்டு கண்டறிந்து, SendMessage மூலம் உரையை வழங்குகிறது; எனவே நீங்கள் எந்தக் கருவியையும் கைமுறையாக இயக்க வேண்டியதில்லை. மற்ற அமர்வுக்கு என்ன தெரிய வேண்டும் என்பதை நீங்கள் கூறினால் போதும், Claude அந்தச் செய்தியைத் தானே எழுதும்.

இந்த அம்சம் cross-session messaging என்று அழைக்கப்படுகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இதற்கு Claude Code v2.1.224 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இது macOS மற்றும் Linux-ல் (WSL 2-ல் உள்ள Linux உட்பட) இயங்குகிறது. Windows-க்கு நேரடி ஆதரவு இல்லை. மேலும், இது Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, அல்லது Microsoft Foundry ஆகியவற்றில் கிடைக்காது. ஒரு அமர்வு இந்தத் தேவைகளைப் பூர்த்தி செய்யும் போது, செய்தி அனுப்பும் வசதி ஏற்கனவே செயல்பாட்டில் இருக்கும்; எதையும் தனியாக enable செய்ய வேண்டியதில்லை. கீழே விவரிக்கப்பட்டுள்ள செயல்பாடு Anthropic-ன் cross-session messaging ஆவணத்திலிருந்து பெறப்பட்டது.

ஒரு VPS-ல் தான் இது முக்கியத்துவம் பெறுகிறது, ஏனெனில் அங்குதான் அமர்வுகள் நீண்ட காலம் இயங்குகின்றன. மடிக்கணினியில் நீங்கள் மூடியை மூடிவிடுவீர்கள். tmux-ன் கீழ் இயங்கும் ஒரு server-ல், நீங்கள் திங்கட்கிழமை தொடங்கிய அமர்வு வியாழக்கிழமையும் இயங்கிக்கொண்டிருக்கும், அது ஒரு repository-ன் சூழலைத் தக்கவைத்திருக்கும். உங்களிடம் இரண்டு அமர்வுகள் இருக்கும்போது, அவை எவ்வாறு தொடர்புகொள்கின்றன என்பது முக்கியமானதாகிறது. நீங்கள் இன்னும் அதை அமைக்கவில்லை என்றால், tmux-ன் கீழ் VPS-ல் Claude Code-ஐ இயக்குதல் என்பதிலிருந்து தொடங்கவும்; இந்த வழிகாட்டிக்குத் தேவையான அமர்வு அமைப்புகளை அது விளக்குகிறது.

இரண்டாவது session எப்போது பயனுள்ளது

செலவில் இருந்து தொடங்குவோம். ஒவ்வொரு session-ம் தனித்தனி Claude instance ஆகும், ஒவ்வொன்றிற்கும் தனித்தனி context window உண்டு. எனவே, ஒரே கால அளவில் இரண்டு session-களைப் பயன்படுத்துவது, ஒரு session-ஐ விட ஏறக்குறைய இரு மடங்கு செலவாகும். நீங்கள் அனுப்பும் ஒவ்வொரு செய்தியும், நீங்கள் தட்டச்சு செய்யும் prompt-ஐப் போலவே பயன்பாட்டுக் கணக்கில் (usage) சேர்க்கப்படும். ஒருங்கிணைப்பு இலவசமானது அல்ல; ஒரே தொடர்ச்சியான பணிகளைப் பிரித்துச் செய்யும்போது, அது மெதுவாகவும் அதிக செலவாகவும் மாறும்.

இரண்டாவது session-க்கான செலவு பயனுள்ளதாக இருக்கும் சூழல்கள் ஒரே மாதிரியானவை. இரண்டு பணிகள் ஒன்றையொன்று சாராமல் ஒரே நேரத்தில் நடக்கும்போது, ஒரு பணியில் கிடைக்கும் தகவலை மற்றொன்று பயன்படுத்த வேண்டிய சூழலில் இது உதவும்.

• ஒரு session-ல் code-ஐ உருவாக்கும்போது, மற்றொரு session-ல் ஒரு breaking change கண்டறியப்படுகிறது. நீங்கள் மீண்டும் தட்டச்சு செய்வதற்குப் பதிலாக, Claude அந்த மாற்றத்தைச் சுருக்கமாகத் தெரிவித்து மற்ற session-க்கு அனுப்பும்.
• இரண்டு session-கள் ஒரே repository-ல் தனித்தனி git worktrees-ல் வேலை செய்கின்றன; ஒரு session-க்கு மற்றொன்றில் என்ன மாற்றங்கள் பதிவாகியுள்ளன என்பது தேவைப்படுகிறது.
• நீண்ட migration அல்லது test run-ன் முடிவுகள், நீங்கள் கண்காணிக்கும் session-க்குத் தெரிவிக்கப்படுகின்றன.
• ஒரு builder session மற்றும் ஒரு reviewer session; இதில் builder உருவாக்கியதை reviewer படித்து, அதில் கண்டறிந்த கருத்துகளைத் திருப்பி அனுப்பும்.

பணிகள் வரிசையாக இருக்கும்போதோ அல்லது இரண்டு session-களும் ஒரே கோப்புகளைத் திருத்த வேண்டியிருக்கும்போதோ, ஒரே session-ஐப் பயன்படுத்தவும். Claude ஒரு பணியின் உள்ளே குழுவை உருவாக்கி மேற்பார்வையிட வேண்டும் எனில், அது agent teams எனப்படும் தனிப்பட்ட மற்றும் சோதனை நிலையில் உள்ள வசதியாகும். ஒரே உரையாடலை மற்றொரு terminal-ல் தொடர விரும்பினால், session-ஐ resume செய்யவும். Cross-session messaging என்பது நீங்கள் சுயமாகத் தொடங்கி வழிநடத்தும் சுதந்திரமான session-களுக்கானது.

ஒரு வசதியைச் சார்ந்த திட்டமிடுதலுக்கு முன் அது உள்ளதா எனச் சரிபார்க்கவும்

முதலில் version-ஐப் பார்க்கவும்:

claude --version

அந்த எண்ணை 2.1.224 உடன் ஒப்பிடவும். பிறகு, ஒரு session-க்குள், /list-agents என்பதைத் தட்டச்சு செய்யவும்; இது /peers கட்டளைக்கும் பதிலளிக்கும். இந்த session எட்டக்கூடிய ஒவ்வொரு agent-ஐயும், அது அறியப்படும் பெயருடன் இது பட்டியலிடும். இந்த கட்டளை அங்கீகரிக்கப்படவில்லை என்றால், இந்த session-ல் cross-session messaging வசதி இல்லை என்று பொருள்; எந்த settings file-ஐ மாற்றினாலும் இதைச் சரிசெய்ய முடியாது. /status என்பதைத் தட்டச்சு செய்து, Peer address வரிசையைத் தேடவும்: இது uds: முன்னொட்டுடன் இந்த session-ன் சொந்த inbox முகவரியைக் கொண்டிருக்கும்.

VPS பயனர்களை ஒரு சிக்கல் குறிப்பாகப் பாதிக்கிறது. Cross-session messaging என்பது feature-flag மதிப்பீட்டைச் சார்ந்தது. பல privacy variables இந்த மதிப்பீட்டை முடக்கிவிடுகின்றன, இதனால் அந்த வசதி அதன் இயல்பான முடக்கப்பட்ட நிலையிலேயே இருக்கும். DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, மற்றும் DISABLE_GROWTHBOOK ஆகிய அனைத்தும் இதைச் செய்கின்றன. பயனர்கள் ஒரு புதிய server-ஐப் பாதுகாக்கும்போது, இவற்றை ~/.bashrc-ல் நகலெடுத்து ஒட்டுகிறார்கள், பிறகு ஏன் /list-agents இல்லை என்று குழம்புகிறார்கள். அதே மதிப்புகள் settings file-ல் உள்ள env map மூலமாகவோ அல்லது நிர்வகிக்கப்படும் settings மூலமாகவோ வரலாம், எனவே முதலில் shell-ஐச் சரிபார்க்கவும்.

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

எந்த variable மதிப்பை அச்சிடுகிறதோ, அதை unset செய்யவும். DISABLE_TELEMETRY மற்றும் CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ஆகியவற்றிற்கு, 0 என்ற string உட்பட, காலியாக இல்லாத எந்த மதிப்பும் அந்தச் செயல்பாட்டை இயக்கும். எனவே, DISABLE_TELEMETRY=0 என்பது பார்ப்பதற்குத் தோன்றுவது போலச் செயல்படாது. அந்த variable-ஐ unset செய்வதன் மூலமோ அல்லது அதை வெறும் string-ஆக அமைப்பதன் மூலமோ மட்டுமே நீங்கள் அதை முடக்க முடியும்.

உங்கள் session-களுக்குப் பெயரிடுங்கள், இல்லையெனில் Claude-ஆல் அவற்றை அடையாளம் காண முடியாது

Claude ஒரு செய்தியை அதன் பெயரைக் கொண்டு ஒரு session-க்கு அனுப்புகிறது. session-ஐத் தொடங்கும்போது அதன் பெயரை அமைக்கவும்:

claude --name builder-api

நடப்பில் உள்ள session-க்குள் /rename கட்டளையைப் பயன்படுத்தியும் நீங்கள் பெயரை அமைக்கலாம். நீங்கள் எதையும் அமைக்கவில்லை என்றால், Claude Code அந்த working directory-ன் கோப்புறைப் பெயரை அடிப்படையாகக் கொண்டு ஒரு பெயரை உருவாக்கும், உதாரணமாக myapp-3f. இது ஒரு session-க்குச் சரியாக இருக்கும், ஆனால் நான்கு session-கள் இருக்கும்போது குழப்பத்தை ஏற்படுத்தும்; மேலும் இரண்டு session-கள் ஒரே பெயரைப் பெறவும் வாய்ப்புள்ளது. /list-agents வெளியீடு ஒவ்வொரு local session-ன் working directory-ஐயும் காட்டுகிறது, இது ஒரே பெயரில் உள்ள session-களை வேறுபடுத்தி அறிய உதவுகிறது. பெயர்கள் மோதும்போது, Claude-ன் சொந்தப் பட்டியல் முகவரியுடன் ஒரு சிறிய identifier-ஐச் சேர்க்கிறது. identifier-களைப் படித்துப் புரிந்துகொள்வதை விட, நீங்களே பெயரிடுவது எளிதானது.

மீண்டும் உருவாக்கக்கூடிய இரண்டு அமர்வு tmux அமைப்பு

இது ஒரே களஞ்சியத்தில் (repository) ஒரு உருவாக்குநர் (builder) அமர்வு மற்றும் ஒரு மதிப்பாய்வாளர் (reviewer) அமர்வு ஆகும். மதிப்பாய்வாளர் தனி git worktree-ல் வேலை செய்வதால், இரண்டு அமர்வுகளும் ஒரே கோப்பில் எழுதுவதில்லை. git worktree add உடன் HEAD சேரும்போது detached checkout கிடைக்கிறது; இது மாற்றங்களைச் சேமிப்பதை விட வாசிப்பதற்கு மட்டுமே பயன்படும் அமர்வுக்குத் தேவையானது. இரண்டு அமர்வுகளும் வெவ்வேறு பணிகளைச் செய்வதால், மதிப்பாய்வாளருக்கு தனி வெளியீட்டு பாணியை (output style) வழங்குவது சிறந்தது. இது அந்த அமர்வின் 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-ஐ அதன் working directory ~/src/api-review உடன் பார்க்க வேண்டும். அது இல்லையென்றால், மதிப்பாய்வாளர் அமர்வு இன்னும் தொடங்கவில்லை அல்லது அடுத்த பகுதியில் உள்ள இரண்டு சிக்கல்களில் ஒன்று இருக்கலாம். பிறகு, எளிய மொழியில் தகவலைப் பரிமாறவும்:

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

Claude சுருக்கத்தை எழுதி அனுப்புகிறது. நீங்கள் செய்தி உரையை எழுத வேண்டியதில்லை, Claude அனுப்பும் உள்ளடக்கம் மாறுபடும். மதிப்பாய்வாளர் விண்டோவில், அந்தச் செய்தி அனுப்புநரின் பெயருடன் உரையாடலில் தோன்றும். அந்த அமர்வு செயலற்ற நிலையில் இருந்தால், Claude உடனடியாக ஒரு புதிய சுற்றைத் தொடங்கும். அது ஒரு பணியின் நடுவில் இருந்தால், tool calls-க்கு இடைப்பட்ட நேரத்தில் செய்தி வரும், எனவே இயங்கிக்கொண்டிருக்கும் கட்டளை ஒருபோதும் தடைபடாது. Claude அதைப் படித்தவுடன், செய்தி ஒரு வரி Message from ஆகச் சுருங்கும், அதை Ctrl+O விரிவுபடுத்தும். உருவாக்குநர் தனது மாற்றங்களைச் சிறியதாக வைத்திருக்கும்போது இந்த ஜோடி சிறப்பாகச் செயல்படும். ஏனெனில், சிறிய diff-கள் சுருக்கமான பரிமாற்றத்தை உருவாக்கும், மேலும் மதிப்பாய்வாளர் அமர்வு அதை ஒரே சுற்றில் முடிக்கும். சோம்பேறி மூத்த மென்பொருள் உருவாக்குநர் திறன் (lazy senior dev skill) இதையே வலியுறுத்துகிறது.

ஒரே VPS-ல் யார் யாரைப் பார்க்க முடியும்

ஒரே machine-ல் நடக்கும் பரிமாற்றங்கள் Anthropic servers வழியாகச் செல்வதில்லை. ஒவ்வொரு session-ம் registration கோப்புகளை disk-ல் எழுதி, தனக்கென ஒரு inbox socket-ஐ உருவாக்குகிறது. உங்கள் மற்ற session-களைக் கண்டறிய Claude Code அந்தக் கோப்புகளைப் படிக்கிறது. இதனால் இரண்டு விளைவுகள் ஏற்படுகின்றன, இவை இரண்டும் server-ல் தாக்கத்தை ஏற்படுத்தும்.

Socket உங்கள் operating system user-க்கு மட்டுமே கட்டுப்படுத்தப்பட்டுள்ளது. நீங்கள் root ஆகத் தொடங்கிய ஒரு session-ம், deploy ஆகத் தொடங்கிய ஒரு session-ம், ஒரே tmux server-ல் அருகருகே இருந்தாலும், ஒன்றையொன்று பார்க்க முடியாது. ஏனெனில், ஒரு user-ன் session-களால் மற்றொரு user-ன் socket-ஐ அணுக முடியாது. எனவே, இரண்டு session-களையும் ஒரே user-ஆக இயக்கவும்.

ஒவ்வொரு container-க்கும் தனித்தனி filesystem உண்டு. Docker-க்குள் இருக்கும் ஒரு session-ம், host-ல் இருக்கும் ஒரு session-ம் ஒன்றையொன்று அணுக முடியாது. ஏனெனில், அவை ஒரே registration கோப்புகளைப் படிப்பதில்லை. ஒரே container-க்குள் இருக்கும் இரண்டு session-கள் சாதாரணமாகத் தகவல்களைப் பரிமாறிக்கொள்ள முடியும். coding agents-ஐ disposable VM-ல் இயக்குவது போன்ற தனிமைப்படுத்தப்பட்ட சூழலுக்காக நீங்கள் agents-ஐ container-களில் வைத்திருந்தால், அந்த container-க்குள் மட்டுமே தகவல் பரிமாற்றம் நடக்கும் என்பதை நினைவில் கொள்ளவும்; container எல்லைக்கு வெளியே அது செயல்படாது.

மற்ற machine-களில் உள்ள உங்கள் session-களும், web-ல் உள்ளவையும், Remote Control இணைக்கப்பட்டிருக்கும்போது மட்டுமே பட்டியலில் தோன்றும்; அவை அவ்வாறே அடையாளப்படுத்தப்பட்டிருக்கும். Claude, அந்த session-களில் ஒன்றிலிருந்து வந்த செய்திக்கு மட்டுமே பதிலளிக்க முடியும். அது தானாக அந்த உரையாடலைத் தொடங்க முடியாது.

உங்கள் செய்தி ஏன் வந்து சேரவில்லை

இதற்கான பொதுவான காரணம் நெட்வொர்க் தொடர்பானதல்ல. செய்தியைப் பெறும் session, அந்தச் செய்தியை என்ன செய்வது என்று தீர்மானிக்கிறது; அதை வழங்க வேண்டாம் என்று அது முடிவெடுத்திருக்கலாம். வரும் ஒவ்வொரு செய்தியும் மூன்று முடிவுகளில் ஒன்றில் முடிகிறது: வழங்கப்பட்டது (delivered), நிறுத்தி வைக்கப்பட்டது (held - நீங்கள் அனுமதிக்கும் வரை வழங்கப்படாமல் ஒதுக்கி வைக்கப்படும்), அல்லது நிராகரிக்கப்பட்டது (dropped - வழங்கப்படாமல் நீக்கப்படும்).

எந்தவொரு crossSessionInbound மதிப்பும் பொருந்தாதபோது, இரண்டு session-களின் permission mode-களை ஒப்பிட்டு Claude Code ஒவ்வொரு செய்திக்கும் முடிவெடுக்கிறது. இது permission prompts-ஐத் தவிர்க்கும் session-களை ஒரு வகையாகவும், மற்ற அனைத்து session-களையும் மற்றொரு வகையாகவும் பிரிக்கிறது. auto, acceptEdits, மற்றும் dontAsk ஆகியவை prompting-ஆகக் கருதப்படுகின்றன. Bypass permissions வசதி கொண்ட ஒரு session-ல், Plan mode என்பது bypass செய்வதாகக் கருதப்படுகிறது. ஒரு session எந்த வகையைச் சேர்ந்தது என்பதில் உங்களுக்குத் தெளிவு இல்லையென்றால், ஒவ்வொரு permission mode-ம் உண்மையில் என்ன செய்கிறது என்பதை முதலில் படிப்பது நல்லது, ஏனெனில் பெரும்பாலான session-கள் இப்போது auto-வில்தான் தொடங்குகின்றன, இது prompting வகையிலேயே அடங்கும். இதற்கான விதி சமச்சீரானது:

• Permissions-க்காக prompt செய்யும் ஒரு receiving session, ஒவ்வொரு செய்தியையும் வழங்குகிறது. அனுப்பும் session prompt-களை bypass செய்வதாக இருந்தால் மட்டுமே அது செய்தியை நிறுத்தி வைக்கும்.
• Prompt-களை bypass செய்யும் ஒரு receiving session, ஒவ்வொரு செய்தியையும் உங்கள் ஒப்புதலுக்காக நிறுத்தி வைக்கும். அனுப்பும் session-ம் bypass செய்தால் மட்டுமே அது செய்தியை வழங்கும்.

எனவே, பெரும்பாலானோர் உருவாக்கும் முதல் workflow சரியாகச் செயல்படுவதில்லை. நீங்கள் ஒரு builder-ஐ --permission-mode bypassPermissions உடன் தொடங்குகிறீர்கள், ஏனெனில் அது கவனிக்கப்படாமல் இயங்க வேண்டும் என்று விரும்புகிறீர்கள், reviewer-ஐ default அமைப்பிலேயே வைத்திருக்கிறீர்கள், builder அனுப்பும் ஒவ்வொரு செய்தியும் யாரும் கவனிக்காத ஒரு approval dialog-ல் காத்திருக்கிறது. அந்த dialog dialogExpiry காலக்கெடுவிற்குப் பிறகு மூடிவிடும், இது default-ஆக 5m என இருக்கும், மேலும் செய்தி நீக்கப்படும். அதே கணினியில், செய்தி நிறுத்தி வைக்கப்பட்டால் அனுப்பும் session-க்கு ஒரு அறிவிப்பு வரும், பின்னர் receiver அதை வழங்கினாலோ, மறுத்தாலோ அல்லது காலாவதியானாலோ ஒரு follow-up அறிவிப்பு வரும், எனவே socket-ஐக் குறை கூறுவதற்கு முன் அனுப்பும் session-ன் திரையைப் பார்க்கவும்.

ஒரு session கவனிக்கப்படாமல் செய்திகளைப் பெற, crossSessionInbound-ஐ accept என அமைக்கவும். நீங்கள் அதை எங்கு அமைக்கிறீர்கள் என்பது அது பொருந்துமா என்பதைத் தீர்மானிக்கிறது. Claude Code முதலில் managed settings-ஐப் படிக்கிறது, பிறகு --settings flag, அதன் பிறகு user settings-ஐப் படிக்கிறது, மேலும் அது கண்டறியும் முதல் மதிப்பைப் பயன்படுத்துகிறது. Project அல்லது local settings-ல் உள்ள மதிப்பு, அது மிகவும் கடுமையானதாக இருக்கும்போது மட்டுமே பொருந்தும், இதற்கான வரிசை accept < hold < refuse ஆகும். .claude/settings.json-ல் உள்ள ஒரு accept மற்ற அனைத்தையும் விட தளர்வானது, எனவே நம்பகமான ஆதாரம் ஒரு மதிப்பை அமைத்திருக்கும்போது இது புறக்கணிக்கப்படும். இதை ~/.claude/settings.json-ல் வைக்கவும், அல்லது ஒரு session-க்கு மட்டும் அனுப்பவும்:

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

ஒரு headless claude -p worker, interactive session போலவே inbox socket-ஐ இணைத்துக்கொண்டு பட்டியலில் தோன்றும், ஆனால் அதனால் approval dialog-ஐக் காட்ட முடியாது. அங்கு நிறுத்தி வைக்கப்பட்ட செய்தி, பிந்தைய mode அல்லது settings மாற்றங்கள் அதை அனுமதிக்கும் வரை அப்படியே இருக்கும். மேலே உள்ள --settings வரியானது, அத்தகைய worker செய்திகளைப் பெற நீங்கள் அனுமதிக்கும் வழியாகும். Bare mode-ல் தொடங்கப்பட்ட ஒரு session எந்த socket-ஐயும் இணைப்பதில்லை, எனவே அதனால் செய்திகளைப் பெறவோ அல்லது பட்டியலில் தோன்றவோ முடியாது.

கைமாற்றங்கள் (hand-offs) முடங்கும் இடங்கள்

Message loops உங்களுக்காகவே கையாளப்படுகின்றன. Claude Code ஒவ்வொரு அனுப்பும் நபருக்கும் மீண்டும் மீண்டும் வரும் செய்திகளை rate-limit செய்கிறது, குறுகிய கால இடைவெளிக்குள் வரும் ஒரே மாதிரியான செய்திகளை நீக்குகிறது, மேலும் ஒரு session-க்கு 50 செய்திகள் வரை மட்டுமே காத்திருப்பில் வைக்க அனுமதிக்கிறது. எனவே, இரண்டு session-கள் முடிவில்லாமல் ஒன்றையொன்று ping-pong செய்ய முடியாது. சேமித்து வைக்கப்படும் செய்திகள் 100-ஆகக் கட்டுப்படுத்தப்பட்டுள்ளன, அதற்கு மேல் வரும்போது பழைய செய்திகள் நீக்கப்படும்.

நிகழும் தோல்வி மிகவும் அமைதியானது, அது ஒரு loop-ஐ விட ஒரு hand-off சிக்கலாகும். Session A, தான் தொடர்ந்து செயல்படுவதற்குத் தேவையான ஒரு கேள்வியை session B-யிடம் கேட்டுவிட்டு, idle நிலைக்குச் செல்கிறது. B அந்தச் செய்தியைத் தற்காலிகமாக வைத்திருக்கிறது, அல்லது B நீண்ட நேரம் எடுக்கும் ஒரு பணியில் இருக்கிறது, அல்லது A கேட்காத ஒரு கேள்விக்கு B பதில் அளிக்கிறது. A காத்திருக்கிறது. ஒரு மணி நேரம் கழித்து நீங்கள் வந்து பார்க்கும்போது, இரண்டு session-களும் idle நிலையில் இருக்கும், எந்த வேலையும் முடிந்திருக்காது.

பதில் தேவையில்லாத வகையில் hand-off-களை எழுதுங்கள். ஒரு சிறந்த செய்தி ஒரு உண்மையை அல்லது முடிவை உள்ளடக்கியதாக இருக்க வேண்டும்: என்ன மாறியது, அதன் முடிவு என்ன என்பது அதில் இருக்க வேண்டும். ஒரு மோசமான செய்தி, மற்ற session-இடம் அனுமதி கேட்பதாகவோ அல்லது அனுப்பியவர் எதனால் முடங்கியிருக்கிறாரோ அதற்கான பதிலை எதிர்பார்ப்பதாகவோ இருக்கும். தனது சொந்த permission settings அனுமதிக்கும் செயல்களைத் தவிர மற்றவற்றுக்கு மற்றொரு session-இடம் கேட்கக்கூடாது என்றும், அந்த வேலையை உங்களிடமே திருப்பி விட வேண்டும் என்றும் Claude-க்கு ஏற்கனவே அறிவுறுத்தப்பட்டுள்ளது. அந்த விதியை நீங்களும் பின்பற்றுங்கள். ஒரு பதில் இல்லாமல் ஒரு session-ஆல் முன்னேற முடியாது என்றால், அதற்கு நீங்கள் தான் பதில் அளிக்க வேண்டும். Context-ஐச் சரியாகக் கையாள்வதும் இதற்கு உதவும், ஏனெனில் தொடர்பை இழந்த ஒரு session தெளிவற்ற செய்திகளையே எழுதும்; managing context in Claude Code அந்தப் பகுதியை விளக்குகிறது.

உள்வரும் செய்தியை நம்பகத்தன்மையற்ற உள்ளீடாகக் கருதுதல்

Claude Code, செய்தியானது உங்களிடமிருந்து வராமல் மற்றொரு session-லிருந்து வந்ததாகப் பெறுநரான Claude-க்குத் தெரிவிக்கிறது; மேலும் அந்தச் செய்தி செய்யக்கூடிய செயல்களைக் கட்டுப்படுத்துகிறது. இந்த அமலாக்கம் மாதிரியின் (model) இணக்கத்தன்மையில் இல்லை, மாறாக மாதிரியைச் சுற்றியுள்ள நிரலில் உள்ளது; இதுவே an agent harness உருவாக்கும் நடைமுறை மாற்றமாகும். மற்றொரு session-லிருந்து வரும் ஒப்புதல் உங்கள் ஒப்புதல் ஆகாது என்பதால், ஒரு செய்தி உங்கள் சார்பாக நிலுவையில் உள்ள அனுமதி கோரிக்கைக்கு (permission prompt) பதிலளிக்க முடியாது. மற்றொரு session கேட்டது என்பதற்காக அது அனுமதி அமைப்புகளையோ, CLAUDE.md-ஐயோ அல்லது பிற configuration-களையோ மாற்ற முடியாது. உரையின் உள்ளே இருக்கும் /compact போன்ற slash command-கள் சாதாரண உரையாகவே வந்து சேரும், அவை ஒருபோதும் இயக்கப்படாது. செய்தியின் அடிப்படையில் செயல்படுவதற்குப் பெறும் session-க்கு அனுமதி தேவைப்பட்டால், பிற பணிகளுக்கு நீங்கள் காண்பது போன்ற அதே prompt-ஐ நீங்களும் காண்பீர்கள். Auto mode-ல், ஒரு classifier ஒவ்வொரு செய்தியையும் விநியோகிக்கும் முன் ஆய்வு செய்கிறது; அது தடுக்கும் செய்தி பெறுநரை ஒருபோதும் சென்றடையாது. இந்த வரம்புகள் permissive mode-களிலும் நீடிக்கும், இதனால்தான் ஒரு bypassing session உள்வரும் செய்திகளை நம்புவதற்குப் பதிலாக, இயல்பாகவே அவற்றை நிறுத்தி வைக்கிறது.

இது அனுமதிகளைப் பற்றியது. இது உள்ளடக்கத்தைப் பற்றியது அல்ல. அனுப்பும் session ஒரு pull request விளக்கம், ஒரு web page, ஒரு dependency README அல்லது ஒரு அந்நியரால் எழுதப்பட்ட issue comment-ஐப் படித்திருக்கலாம்; அது எதைப் படித்தாலும், அது உங்கள் மற்றொரு session-க்கு எழுதும் உரையை வடிவமைக்க முடியும். செய்தி என்பது தரவு. வெளியிலிருந்து ஒரு session-க்குள் நுழையும் மற்ற எந்த உரையையும் போலவே இதையும் சந்தேகத்துடன் அணுக வேண்டும். keeping secrets out of your AI agents-ல் விவரிக்கப்பட்டுள்ள ஒழுக்கம் இதுதான்: நம்பிக்கைக்குரிய எல்லையைக் கடந்த எதையும் தவறாக இருக்கலாம் என்று கருதுங்கள், மேலும் அது தானாகவே அங்கீகாரம் பெற ஒருபோதும் அனுமதிக்காதீர்கள்.

இதன் அளவைக் குறைக்க விரும்பினால் இரண்டு கட்டுப்பாடுகள் உள்ளன. crossSessionInbound-ஐ refuse என அமைப்பது, உள்வரும் peer செய்திகளை விநியோகிக்காமல் நிராகரிக்கும். project அல்லது local settings-லிருந்து இந்த மதிப்பு மற்ற அனைத்து ஆதாரங்களையும் விட மேலோங்கிச் செயல்படும், ஏனெனில் இதுவே மிகக் கடுமையான கட்டுப்பாடாகும். இந்த session அனுப்புவதையோ அல்லது பட்டியலிடுவதையோ நிறுத்த, SendMessage மற்றும் ListAgents ஆகியவற்றை உள்ளடக்கிய permission deny விதிகளைச் சேர்க்கவும்; இவை இரண்டும் எந்தக் குறிப்பானும் (specifier) இல்லாமல் வெறும் tool பெயர்களாக எழுதப்பட வேண்டும். isolatePeerMachines-ஐ true என அமைப்பது, இந்த இயந்திரத்திற்கு அப்பால் உள்ள session-க்கு எந்தச் செய்தியும் செல்வதற்கு முன் உங்கள் வெளிப்படையான ஒப்புதலைக் கோரும்; bypassPermissions mode-ல் கூட இந்த ஒப்புதல் கட்டாயமாகும்.

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

SendMessage-ஐ மறுப்பது subagent-களுக்கான செய்தியனுப்புதலையும் நீக்குகிறது, ஏனெனில் ஒரே tool இரண்டிற்கும் பயன்படுகிறது. மறுக்கும் session அதன் சொந்த /status-ல் அல்லது பிற session-களின் பட்டியல்களில் எந்த மாற்றத்தையும் காட்டாது, எனவே திரையில் பார்ப்பதை விட session-ன் configuration-லிருந்து அமைப்பை உறுதிப்படுத்தவும்.

Bridges மற்றும் shared memory MCP servers

இதே காலகட்டத்தில், தொடர்புடைய செயல்பாடுகளைச் செய்யும் பல மூன்றாம் தரப்புத் திட்டங்கள் வெளியாகியுள்ளன: இயங்கிக்கொண்டிருக்கும் agents-க்கு இடையே உரையை relay செய்யும் local agent-to-agent bridges மற்றும் பல agents ஒரே shared store-ல் படிக்கவும் எழுதவும் உதவும் MCP (model context protocol) servers. இவற்றை போட்டியாளராகக் கருதாமல், ஒரு மாறுபட்ட வடிவமாக அணுகுங்கள். எந்தவொரு install command-ஐயும் இயக்குவதற்கு முன்பு, அந்தத் திட்டத்தின் சொந்த README கோப்புடன் சரிபார்க்கவும். Messaging என்பது push முறையில் இயங்குகிறது, ஏனெனில் அனுப்புநர் பெறுநரின் turn-ல் உரையை வைக்கிறார். Shared store என்பது pull முறையில் இயங்குகிறது, ஏனெனில் இதில் யாரும் இடையூறு செய்யப்படுவதில்லை; ஒரு session அடுத்தமுறை பார்க்கும்போதுதான் அந்த note-ஐக் காண முடியும். மெதுவாக மாறும் நிலைகளுக்கு (status) pull முறை அமைதியானது, மேலும் ஒரு session உண்மையில் பார்க்கும்போது மட்டுமே இது செயல்படும்.

நீங்கள் அந்த வழியைத் தேர்ந்தெடுத்தால், feature list-ஐ விட செயல்முறை (process) குறித்த கேள்விகளைக் கேட்பதே சிறந்தது. அந்த server எந்த user-ஆக இயங்குகிறது மற்றும் அந்த machine-ல் எதை அதால் படிக்க முடியும் என்பதே முக்கியம். Running MCP servers on a VPS அந்த அமைப்பைப் பற்றி விளக்குகிறது. Sharing agent skills across repos என்பது sessions-க்கு இடையே live state-ஐ விட instructions-ஐப் பகிர விரும்பும் எளிய சூழலைப் பற்றியது; இது நீங்கள் அனுப்ப வேண்டிய பல செய்திகளைக் குறைக்கிறது. ஒட்டுமொத்த சூழலைப் புரிந்துகொள்ள, running a coding agent on a VPS என்பதில் இருந்து தொடங்குங்கள்.

FAQ

எனது session-ல் ஏன் /list-agents அங்கீகரிக்கப்படவில்லை?

இந்த session-ல் cross-session messaging வசதி இல்லை. முதலில் claude --version-ஐ 2.1.224 பதிப்புடன் ஒப்பிட்டுச் சரிபார்க்கவும், ஏனெனில் இந்த வசதிக்கு அந்தப் பதிப்பு அல்லது அதற்குப் பிந்தைய பதிப்பு அவசியம். அடுத்து, இயங்குதளத்தைச் சரிபார்க்கவும்; இது 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 மதிப்பீட்டைத் தடுத்து, அதை முடக்கிவிடும்.

மற்றொரு session-க்கு நான் அனுப்பிய செய்தி ஏன் சென்றடையவில்லை?

/list-agents சரியாக வேலை செய்தால், messaging வசதி இயங்குகிறது என்று அர்த்தம்; ஏதோ ஒரு குறிப்பிட்ட தடையால் செய்தி சென்றடையவில்லை. இதற்குப் பொதுவான காரணம் permission modes ஆகும். Permission prompts-ஐத் தவிர்க்கும் ஒரு session, அனுப்பும் தரப்பு அனுமதி பெறாதவரை அனைத்து உள்வரும் செய்திகளையும் உங்கள் ஒப்புதலுக்காக நிறுத்தி வைக்கும். அந்த ஒப்புதல் உரையாடல் dialogExpiry காலக்கெடுவிற்குப் பிறகு (இயல்பாக ஐந்து நிமிடங்கள்) நீக்கப்படும். செய்தி அனுப்பும் session-ல் நிறுத்தி வைக்கப்பட்ட அறிவிப்பு உள்ளதா என்று சரிபார்க்கவும். இதைச் சரிசெய்ய, ~/.claude/settings.json-ல் crossSessionInbound-ஐ accept என அமைக்கவும் அல்லது --settings மூலம் அனுப்பவும். ஏனெனில் project அல்லது local settings-ல் உள்ள accept தளர்வான மதிப்பாகக் கருதப்பட்டு நிராகரிக்கப்படும்.

Docker-ல் உள்ள ஒரு Claude Code session-ஆல் host-ல் உள்ள session-க்கு செய்தி அனுப்ப முடியுமா?

முடியாது. Sessions தங்களுக்குள் வட்டில் உள்ள registration files மற்றும் per-session inbox socket மூலம் ஒன்றையொன்று கண்டறிகின்றன. ஒரு container-க்குத் தனிப்பட்ட filesystem இருப்பதால், இரண்டாலும் ஒரே கோப்புகளைப் பார்க்க முடியாது. ஒரே container-க்குள் இருக்கும் இரண்டு sessions தங்களுக்குள் சாதாரணமாகச் செய்தி அனுப்பிக்கொள்ள முடியும். இதே விதிதான் root-ஆக இயங்கும் ஒரு session மற்றும் உங்கள் சாதாரண பயனர் கணக்கில் இயங்கும் ஒரு session ஏன் ஒன்றையொன்று தொடர்பு கொள்ள முடியாது என்பதையும் விளக்குகிறது: அந்த socket அதை உருவாக்கிய operating system பயனருக்கு மட்டுமே கட்டுப்படுத்தப்பட்டுள்ளது.

மற்றொரு Claude Code session-லிருந்து வரும் செய்தியின் அடிப்படையில் செயல்படுவது பாதுகாப்பானதா?

அந்த உரையை நம்பகத்தன்மையற்ற உள்ளீடாகக் கருதவும். ஏனெனில், அனுப்பும் session யாரோ ஒருவர் எழுதிய இணையப் பக்கம், README, அல்லது issue comment-ஐப் படித்திருக்கலாம். Claude Code ஏற்கனவே செய்தியைத் தானாகச் செயல்படுவதிலிருந்து தடுக்கிறது: அது நிலுவையில் உள்ள permission prompt-க்கு ஒப்புதல் அளிக்க முடியாது, கோரிக்கையின் பேரில் permission settings அல்லது CLAUDE.md-ஐ மாற்ற முடியாது, மேலும் உரையில் உள்ள slash command சாதாரண உரையாகவே வந்து சேரும், அது இயங்காது. அந்தப் பாதுகாப்புகள் அனுமதிகளை மட்டுமே கட்டுப்படுத்தும், உங்கள் முடிவெடுக்கும் திறனை அல்ல. எனவே, செய்தியைப் பெறும் session-ஐச் செயல்படச் சொல்லும் முன், வந்த செய்தியை முழுமையாகப் படிக்கவும்.

Cross-session messaging எனது குறியீட்டை (code) Anthropic-க்கு அனுப்புமா?

ஒரே கணினியில் உள்ள இரண்டு sessions-க்கு இடையே அனுப்பாது. செய்தி அந்த கணினியில் உள்ள per-session socket வழியாகவே செல்லும், Anthropic servers வழியாகச் செல்லாது. Claude எழுதிய உரை மட்டுமே அனுப்பப்படும், உரையாடல் வரலாறு அல்லது கோப்புகள் அனுப்பப்படாது. உங்கள் மற்றொரு கணினியில் உள்ள session-க்கு அல்லது இணையத்தில் உள்ள session-க்கு அனுப்பப்படும் செய்திகள், Remote Control இணைப்பு வழியாக Anthropic servers வழியாகச் செல்லும். அந்தத் திசையில், வந்த செய்திக்கு மட்டுமே Claude பதில் அளிக்க முடியும், தானாகப் புதிய செய்தியைத் தொடங்க முடியாது. ஏதேனும் ஒரு தகவல் கணினியை விட்டு வெளியேறும் முன் உங்கள் ஒப்புதல் தேவை எனில், isolatePeerMachines-ஐ true என அமைக்கவும்.