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

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

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

இந்த அம்சம் cross-session messaging என்று அழைக்கப்படுகிறது. ஆகஸ்ட் 2026 நிலவரப்படி, இதற்கு Claude Code v2.1.224 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இது macOS மற்றும் Linux-ல் இயங்குகிறது (WSL 2-ல் உள்ள Linux உட்பட). இதற்கு native Windows ஆதரவு இல்லை. மேலும், இது Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, அல்லது Microsoft Foundry ஆகியவற்றில் கிடைக்காது. ஒரு அமர்வு இந்தத் தேவைகளைப் பூர்த்தி செய்யும் போது, செய்தி அனுப்பும் வசதி ஏற்கனவே செயல்பாட்டில் இருக்கும்; நீங்கள் எதையும் தனியாக இயக்க வேண்டியதில்லை. கீழே விவரிக்கப்பட்டுள்ள செயல்பாடுகள் 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-ல் உள்ள பிழை (breaking change) கண்டறியப்படும்போது, மற்றொன்று அந்த code-ஐ அடிப்படையாகக் கொண்டு உருவாக்கிக்கொண்டிருக்கும். நீங்கள் மீண்டும் தட்டச்சு செய்வதற்குப் பதிலாக, Claude அந்த மாற்றத்தைச் சுருக்கி மற்றொன்றுக்கு அனுப்பும்.
• இரண்டு session-கள் ஒரே repository-ல் தனித்தனி git worktrees-ல் வேலை செய்யும். அதில் ஒன்று எவை இணைக்கப்பட்டுள்ளன (landed) என்பதைத் தெரிந்துகொள்ள வேண்டியிருக்கும்.
• நீண்ட migration அல்லது test run-ன் முடிவுகள் நீங்கள் கவனித்துக்கொண்டிருக்கும் session-க்குத் தெரிவிக்கப்படும்.
• ஒரு builder session மற்றும் ஒரு reviewer session. இதில் builder உருவாக்கியதை reviewer படித்து, கண்டறிந்த கருத்துக்களைத் திருப்பி அனுப்பும்.

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

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

முதலில் பதிப்பு:

claude --version

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

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 வரைபடம் மூலமாகவோ அல்லது நிர்வகிக்கப்படும் அமைப்புகள் மூலமாகவோ வரலாம், எனவே முதலில் 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-ஆக அமைப்பதன் மூலமோ நீங்கள் அதை முடக்கலாம்.

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

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

claude --name builder-api

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

நீங்கள் மீண்டும் உருவாக்கக்கூடிய இரண்டு session கொண்ட tmux அமைப்பு

இது ஒரே repository-ல் ஒரு builder session மற்றும் ஒரு reviewer session ஆகும். reviewer ஒரு தனி git worktree-ல் வேலை செய்கிறார், எனவே இருவரும் ஒரே கோப்பில் எழுதுவதில்லை. git worktree add உடன் HEAD-ஐப் பயன்படுத்தினால் detached checkout கிடைக்கும்; இது commit செய்வதற்குப் பதிலாக வாசிக்கும் session-க்குத் தேவையானதாகும்.

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 பெயர்களின் அடிப்படையில் பட்டியலிடப்படும், அதன் மூலம் நீங்கள் ஒன்றைத் தேர்ந்தெடுக்கலாம். builder window-ல், /list-agents-ஐ இயக்கவும். நீங்கள் reviewer-api-ஐ அதன் working directory ~/src/api-review உடன் பார்க்க வேண்டும். அது இல்லையென்றால், reviewer session இன்னும் தொடங்கவில்லை அல்லது அடுத்த பகுதியில் உள்ள இரண்டு சிக்கல்களில் ஒன்று ஏற்பட்டுள்ளது என்று அர்த்தம். பிறகு, எளிய மொழியில் தகவலைப் பரிமாறவும்:

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

Claude சுருக்கத்தை எழுதி அனுப்புகிறது. நீங்கள் செய்தி உரையை எழுத வேண்டியதில்லை, Claude அனுப்பும் உள்ளடக்கம் மாறுபடும். reviewer window-ல், அந்தச் செய்தி அனுப்பியவரின் பெயருடன் உரையாடலில் தோன்றும். அந்த session idle நிலையில் இருந்தால், Claude உடனடியாக ஒரு புதிய சுற்றைத் தொடங்கும். அது ஒரு சுற்றின் நடுவில் இருந்தால், tool calls-க்கு இடைப்பட்ட நேரம் வரை செய்தி காத்திருக்கும், எனவே இயங்கிக்கொண்டிருக்கும் command ஒருபோதும் தடைபடாது. Claude அதை வாசித்தவுடன், செய்தி ஒரு வரி Message from வரியாகச் சுருங்கும், அதை Ctrl+O விரிவுபடுத்தும். builder தனது மாற்றங்களைச் சிறியதாக வைத்திருக்கும்போது இந்த ஜோடி சிறப்பாகச் செயல்படுகிறது, ஏனெனில் சிறிய diff ஒரு குறுகிய பரிமாற்றத்தை உருவாக்குகிறது. இது ஒரு சுற்றில் reviewer session-ஆல் முடிக்கக்கூடிய review-ஐ வழங்குகிறது; இதற்காகவே சோம்பேறி senior dev திறன் நடைமுறையில் உள்ளது.

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

ஒரே இயந்திரத்தில் நடக்கும் பரிமாற்றங்கள் Anthropic servers வழியாகச் செல்வதில்லை. ஒவ்வொரு session-ம் பதிவு கோப்புகளை (registration files) வட்டில் எழுதி, அதன் சொந்த inbox socket-ஐ bind செய்கிறது. மற்ற 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-ம் ஒன்றையொன்று அணுக முடியாது, ஏனெனில் அவை ஒரே பதிவு கோப்புகளை வாசிப்பதில்லை. ஒரே container-க்குள் இருக்கும் இரண்டு session-கள் சாதாரணமாகத் தகவல் பரிமாறிக்கொள்ள முடியும். running coding agents in a disposable VM-ல் உள்ளது போல, தனிமைப்படுத்துதலுக்காக agents-ஐ container-களில் வைத்திருந்தால், container-க்குள் மட்டுமே தகவல் பரிமாற்றம் நடக்கும், container எல்லையைத் தாண்டி அது செயல்படாது என்பதை நினைவில் கொள்ளவும்.

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

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

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

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

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

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

ஒரு session செய்திகளைத் தானாகவே பெற்றுக்கொள்ள, crossSessionInbound-ஐ accept என அமைக்கவும். நீங்கள் அதை எங்கு அமைக்கிறீர்கள் என்பது அது பொருந்துமா என்பதைத் தீர்மானிக்கிறது. Claude Code முதலில் நிர்வகிக்கப்படும் அமைப்புகளை (managed settings) வாசிக்கிறது, பிறகு --settings flag-ஐ, அதன் பிறகு பயனர் அமைப்புகளை வாசிக்கிறது. அது கண்டறியும் முதல் மதிப்பையே அமல்படுத்துகிறது. project அல்லது local அமைப்புகளில் உள்ள மதிப்பு, அது மிகவும் கடுமையானதாக இருக்கும்போது மட்டுமே பொருந்தும் (ஏணி வரிசை: 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 அல்லது அமைப்புகள் மாற்றப்படும் வரை அப்படியே இருக்கும். ஒரு worker செய்திகளைப் பெற்றுக்கொள்ள, மேலே உள்ள --settings வரியைப் பயன்படுத்தவும். bare mode-ல் தொடங்கப்படும் ஒரு session எந்த socket-ஐயும் இணைப்பதில்லை, எனவே அதனால் செய்திகளைப் பெறவோ அல்லது பட்டியலில் தோன்றவோ முடியாது.

ஹேண்ட்-ஆஃப்கள் (hand-offs) எங்கு முடங்குகின்றன

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

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

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

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

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

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

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

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

SendMessage-ஐ மறுப்பது subagents-க்குச் செல்லும் செய்திகளையும் நீக்கும், ஏனெனில் ஒரே 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 என்பது, live state-ஐ விட instructions-ஐ sessions-க்கு இடையே பகிர விரும்பும் எளிமையான சூழலைப் பற்றியது; இது நீங்கள் அனுப்ப வேண்டிய பல செய்திகளைக் குறைக்கிறது. ஒட்டுமொத்தப் பார்வையைப் பெற, 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, அனுப்புநரும் அதேபோல் தவிர்க்காதவரை, வரும் ஒவ்வொரு செய்தியையும் உங்கள் ஒப்புதலுக்காக நிறுத்தி வைக்கும். அந்த ஒப்புதல் உரையாடல் (approval dialog) dialogExpiry காலக்கெடு முடிந்ததும் (இயல்பாக ஐந்து நிமிடங்கள்) நீக்கப்படும். செய்தி அனுப்பிய session-ல் நிறுத்தி வைக்கப்பட்ட அறிவிப்பு (held notice) உள்ளதா என்று பார்க்கவும். இதைச் சரிசெய்ய, ~/.claude/settings.json-ல் crossSessionInbound-ஐ accept என அமைக்கவும் அல்லது --settings மூலம் அதை அனுப்பவும். ஏனெனில், project அல்லது local settings-ல் உள்ள accept தளர்வான மதிப்பாகக் கருதப்பட்டு நிராகரிக்கப்படும்.

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

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

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

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

Cross-session messaging எனது code-ஐ Anthropic-க்கு அனுப்புமா?

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