วิธีส่งข้อความระหว่างเซสชัน Claude Code บน VPS

ความหมายของการที่เซสชัน Claude Code ส่งข้อความถึงกัน

เซสชัน Claude Code สองเซสชันสามารถส่งข้อความถึงกันได้เมื่อทำงานบนเครื่องเดียวกัน ภายใต้ผู้ใช้งานระบบปฏิบัติการเดียวกัน ข้อความคือข้อมูลข้อความธรรมดาหนึ่งชุดที่ Claude เขียนขึ้นเพื่อส่งให้ Claude อีกตัวหนึ่ง โดยข้อความนี้จะไม่มีประวัติการสนทนาและไม่มีไฟล์แนบ Claude จะค้นหาเซสชันอื่นด้วยเครื่องมือ ListAgents และส่งข้อความด้วย SendMessage ดังนั้นคุณจึงไม่จำเป็นต้องเรียกใช้เครื่องมือทั้งสองนี้ด้วยตนเอง คุณเพียงแค่ระบุสิ่งที่เซสชันอื่นจำเป็นต้องทราบ แล้ว Claude จะเขียนข้อความนั้นด้วยตัวเอง

ฟีเจอร์นี้เรียกว่าการส่งข้อความข้ามเซสชัน (cross-session messaging) ณ เดือนสิงหาคม 2026 ฟีเจอร์นี้ต้องการ Claude Code v2.1.224 หรือใหม่กว่า และทำงานบน macOS และ Linux รวมถึง Linux ภายใน WSL 2 ได้ โดยยังไม่มีการรองรับ Windows แบบ native และไม่สามารถใช้งานได้บน Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform หรือ Microsoft Foundry เมื่อเซสชันตรงตามข้อกำหนดเหล่านี้ การส่งข้อความจะเปิดใช้งานอยู่แล้วและไม่มีสิ่งใดที่ต้องตั้งค่าเพิ่มเติม พฤติกรรมที่อธิบายไว้ด้านล่างนี้มาจาก เอกสารประกอบของ Anthropic สำหรับการส่งข้อความข้ามเซสชัน

VPS คือจุดที่เรื่องนี้มีความสำคัญ เพราะ VPS เป็นที่ที่เซสชันทำงานยาวนานพอที่จะคุ้มค่าต่อการติดต่อสื่อสาร บนแล็ปท็อปคุณมักจะปิดฝาเครื่อง แต่บนเซิร์ฟเวอร์ที่รันภายใต้ tmux เซสชันที่คุณเริ่มไว้ตั้งแต่วันจันทร์จะยังคงทำงานอยู่จนถึงวันพฤหัสบดี โดยยังคงเก็บบริบทของ repository หนึ่งไว้ เมื่อคุณมีเซสชันลักษณะนี้สองรายการ วิธีที่พวกมันสื่อสารกันจึงไม่ใช่เรื่องทฤษฎีอีกต่อไป หากคุณยังไม่ได้ตั้งค่าส่วนนี้ ให้เริ่มต้นที่ การรัน Claude Code บน VPS ภายใต้ tmux ซึ่งครอบคลุมถึงโครงสร้างพื้นฐานของเซสชันที่คู่มือนี้อ้างอิงถึง

เมื่อการเปิด session ที่สองคุ้มค่ากับ token ที่เสียไป

เริ่มต้นด้วยเรื่องค่าใช้จ่าย แต่ละ session คืออินสแตนซ์ของ Claude ที่แยกจากกันโดยมี context window เป็นของตัวเอง ดังนั้นการเปิดสอง session จึงมีค่าใช้จ่ายประมาณสองเท่าของ session เดียวในช่วงเวลาที่เท่ากัน ข้อความที่ถูกส่งออกมาจะถูกนับรวมในการใช้งานเช่นเดียวกับ prompt ที่คุณพิมพ์ การประสานงานไม่ได้เกิดขึ้นฟรี และงานที่เป็นลำดับขั้นตอนเดียวกันจะช้าลงและมีค่าใช้จ่ายสูงขึ้นเมื่อคุณแยกมันออกเป็นหลาย session

กรณีที่การเปิด session ที่สองจะคุ้มค่ากับต้นทุนนั้นมีลักษณะร่วมกันอยู่อย่างหนึ่ง คือการมีงานสองส่วนที่ทำงานไปพร้อมกันโดยไม่ต้องรอซึ่งกันและกัน และงานหนึ่งได้เรียนรู้ข้อมูลที่อีกงานจำเป็นต้องใช้ในระหว่างดำเนินการ

• session หนึ่งพบการเปลี่ยนแปลงที่ทำให้ระบบพัง (breaking change) ในขณะที่อีก session กำลังเขียนโค้ดต่อยอดจากส่วนที่พังนั้น Claude จะสรุปการเปลี่ยนแปลงและส่งข้อมูลดังกล่าวให้ แทนที่คุณจะต้องพิมพ์ใหม่ใน terminal อีกอัน
• สอง session ทำงานบน repository เดียวกันโดยใช้ git worktrees แยกกัน และ session หนึ่งจำเป็นต้องทราบว่ามีการเปลี่ยนแปลงใดที่ถูก merge เข้ามาแล้ว
• การย้ายระบบ (migration) หรือการรันทดสอบ (test run) ที่ใช้เวลานาน รายงานผลลัพธ์กลับมายัง session ที่คุณกำลังเฝ้าดูอยู่
• session สำหรับสร้างงาน (builder) และ session สำหรับตรวจสอบงาน (reviewer) โดยที่ reviewer จะอ่านสิ่งที่ builder สร้างขึ้นและส่งข้อมูลสิ่งที่พบกลับไป

เมื่องานเป็นแบบลำดับขั้นตอน หรือเมื่อทั้งสอง session ต้องแก้ไขไฟล์เดียวกัน ให้ใช้เพียง session เดียว หากคุณต้องการกลุ่มที่ประสานงานกันซึ่ง Claude เป็นผู้สร้างและกำกับดูแลภายในงานเดียว นั่นคือเรื่องของทีมตัวแทน (agent teams) ซึ่งเป็นฟีเจอร์แยกต่างหากที่ยังอยู่ในขั้นทดลอง หากคุณเพียงแค่ต้องการสนทนาต่อใน terminal อื่น ให้ใช้การ resume session แทน การส่งข้อความข้าม session มีไว้สำหรับ session ที่เป็นอิสระต่อกันซึ่งคุณเป็นผู้เริ่มและควบคุมด้วยตัวเอง

ตรวจสอบว่าฟีเจอร์นั้นมีอยู่จริงก่อนวางแผนใช้งาน

เริ่มจากตรวจสอบเวอร์ชัน:

claude --version

เปรียบเทียบตัวเลขเวอร์ชันกับ 2.1.224 จากนั้นภายในเซสชัน ให้พิมพ์ /list-agents ซึ่งสามารถใช้คำสั่ง /peers แทนได้เช่นกัน คำสั่งนี้จะแสดงรายการเอเจนต์ทั้งหมดที่เซสชันนี้สามารถติดต่อได้ พร้อมชื่อที่แต่ละเอเจนต์ใช้ตอบรับ หากระบบไม่รู้จักคำสั่งนี้ แสดงว่าเซสชันนี้ไม่มีฟีเจอร์การส่งข้อความข้ามเซสชัน (cross-session messaging) และไม่มีไฟล์การตั้งค่าใดที่จะแก้ไขปัญหานี้ได้ ให้พิมพ์ /status แล้วมองหาแถว Peer address ซึ่งจะระบุที่อยู่กล่องข้อความของเซสชันนี้ โดยมี uds: เป็นคำนำหน้า

มีกับดักหนึ่งที่มักพบในผู้ใช้ VPS โดยเฉพาะ ฟีเจอร์การส่งข้อความข้ามเซสชันขึ้นอยู่กับการประเมิน feature-flag และตัวแปรด้านความเป็นส่วนตัวหลายตัวจะปิดการประเมินดังกล่าว ส่งผลให้ฟีเจอร์นี้ถูกปิดใช้งานตามค่าเริ่มต้น ตัวแปร DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC และ DISABLE_GROWTHBOOK ล้วนส่งผลเช่นนี้ ผู้ใช้มักทำการ harden เซิร์ฟเวอร์ใหม่โดยการคัดลอกตัวแปรเหล่านี้ไปวางใน ~/.bashrc แล้วจึงสงสัยว่าเหตุใด /list-agents จึงไม่ปรากฏขึ้น ค่าเหล่านี้อาจมาจาก map env ในไฟล์การตั้งค่าหรือจากการตั้งค่าแบบ managed ดังนั้นควรตรวจสอบ shell ก่อนเป็นอันดับแรก

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

ให้ยกเลิกการตั้งค่า (unset) ตัวแปรใดก็ตามที่แสดงผลออกมา สำหรับ DISABLE_TELEMETRY และ CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ค่าใดก็ตามที่ไม่ใช่ค่าว่างจะเปิดใช้งานพฤติกรรมนี้ รวมถึงสตริง 0 ด้วย ดังนั้นการตั้งค่า DISABLE_TELEMETRY=0 จึงไม่ได้ผลลัพธ์ตามที่เข้าใจ คุณสามารถปิดใช้งานได้โดยการ unset ตัวแปรดังกล่าวหรือกำหนดค่าให้เป็นสตริงว่าง

ตั้งชื่อเซสชันของคุณ มิฉะนั้น Claude จะไม่สามารถระบุเซสชันเหล่านั้นได้

Claude ระบุข้อความไปยังเซสชันด้วยชื่อ คุณควรตั้งชื่อเมื่อเริ่มต้นเซสชัน:

claude --name builder-api

คุณยังสามารถตั้งชื่อได้ด้วย /rename ในขณะที่เซสชันกำลังทำงานอยู่ หากคุณไม่ได้ตั้งชื่อ Claude Code จะกำหนดชื่อจากชื่อโฟลเดอร์ของไดเรกทอรีที่ทำงานอยู่ เช่น myapp-3f ซึ่งอาจเพียงพอสำหรับหนึ่งเซสชัน แต่จะสร้างความสับสนหากมีสี่เซสชัน และอาจเกิดกรณีที่สองเซสชันมีชื่อเดียวกันได้ ผลลัพธ์จาก /list-agents จะแสดงไดเรกทอรีที่ทำงานอยู่ของแต่ละเซสชันในเครื่อง ซึ่งช่วยให้แยกแยะเซสชันที่ชื่อเหมือนกันได้ และรายการของ Claude เองจะเพิ่มตัวระบุสั้นๆ เข้าไปในที่อยู่เมื่อชื่อซ้ำกัน การตั้งชื่อด้วยตนเองนั้นสะดวกกว่าการอ่านตัวระบุเหล่านี้

เลย์เอาต์ tmux สองเซสชันที่คุณสามารถทำซ้ำได้

นี่คือเซสชันสำหรับผู้สร้าง (builder) และผู้ตรวจสอบ (reviewer) บน repository เดียวกัน ผู้ตรวจสอบจะทำงานใน git worktree แยกต่างหาก ดังนั้นทั้งสองเซสชันจะไม่เขียนไฟล์เดียวกัน git worktree add ร่วมกับ HEAD จะให้ผลลัพธ์เป็น detached checkout ซึ่งเป็นสิ่งที่คุณต้องการสำหรับเซสชันที่เน้นการอ่านมากกว่าการ 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 จะแสดงรายการหน้าต่างตามชื่อเพื่อให้คุณเลือกได้ ในหน้าต่างของผู้สร้าง ให้รัน /list-agents คุณควรจะเห็น reviewer-api พร้อมกับไดเรกทอรีทำงานคือ ~/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 ที่แคบจะทำให้การส่งมอบงานสั้นลง และเป็นการตรวจสอบที่อีกเซสชันสามารถทำเสร็จได้ในรอบเดียว ซึ่งเป็นนิสัยที่ ทักษะของนักพัฒนาอาวุโสที่ขี้เกียจ มีไว้เพื่อบังคับใช้

ใครสามารถมองเห็นใครได้บ้างบน VPS เครื่องเดียว

การส่งข้อมูลภายในเครื่องเดียวกันจะไม่ผ่านเซิร์ฟเวอร์ของ Anthropic แต่ละเซสชันจะเขียนไฟล์ลงทะเบียนลงในดิสก์และผูกเข้ากับ socket ของกล่องข้อความของตนเอง จากนั้น Claude Code จะอ่านไฟล์เหล่านั้นเพื่อค้นหาเซสชันอื่นของคุณ ซึ่งส่งผลตามมา 2 ประการที่อาจเกิดขึ้นได้บนเซิร์ฟเวอร์

Socket จะถูกจำกัดไว้เฉพาะผู้ใช้ในระบบปฏิบัติการของคุณเท่านั้น เซสชันที่คุณเริ่มในฐานะ root และเซสชันที่คุณเริ่มในฐานะ deploy จะไม่สามารถมองเห็นกันได้ แม้จะอยู่เคียงข้างกันใน tmux server เดียวกันก็ตาม เนื่องจากเซสชันของผู้ใช้คนหนึ่งไม่สามารถเข้าถึง socket ของผู้ใช้อีกคนได้ ดังนั้นให้รันทั้งสองเซสชันด้วยผู้ใช้คนเดียวกัน

คอนเทนเนอร์มีระบบไฟล์เป็นของตัวเอง เซสชันที่อยู่ภายใน Docker และเซสชันบนโฮสต์จะไม่สามารถเข้าถึงกันได้ เนื่องจากไม่ได้อ่านไฟล์ลงทะเบียนชุดเดียวกัน เซสชันสองเซสชันที่อยู่ภายในคอนเทนเนอร์เดียวกันสามารถส่งข้อความถึงกันได้ตามปกติ หากคุณเก็บเอเจนต์ไว้ในคอนเทนเนอร์เพื่อแยกส่วนการทำงาน ดังที่อธิบายไว้ใน การรันเอเจนต์เขียนโค้ดใน VM แบบใช้แล้วทิ้ง ให้คาดหวังว่าการส่งข้อความจะทำงานได้เฉพาะภายในคอนเทนเนอร์เท่านั้น ไม่สามารถข้ามขอบเขตของคอนเทนเนอร์ได้

เซสชันของคุณบนเครื่องอื่นและบนเว็บจะปรากฏในรายการเฉพาะในขณะที่ Remote Control เชื่อมต่ออยู่เท่านั้น และจะถูกระบุไว้อย่างชัดเจน Claude ในที่นี้สามารถตอบกลับข้อความที่ส่งมาจากเซสชันเหล่านั้นได้เท่านั้น ไม่สามารถเป็นผู้เริ่มการสนทนาได้

เหตุผลที่ข้อความของคุณไม่ถูกส่งถึงปลายทาง

สาเหตุส่วนใหญ่ไม่ได้เกิดจากเครือข่าย แต่เกิดจากเซสชันผู้รับตัดสินใจว่าจะจัดการกับข้อความนั้นอย่างไร ซึ่งผลลัพธ์คือการไม่ส่งข้อความนั้น ทุกข้อความที่เข้ามาจะจบลงด้วยหนึ่งในสามสถานะ: ส่งสำเร็จ (delivered), พักไว้ (held - เก็บไว้โดยยังไม่ส่งจนกว่าคุณจะอนุมัติ), หรือปฏิเสธ (refused - ถูกทิ้งโดยไม่ส่ง)

เมื่อไม่มีค่า crossSessionInbound ใดๆ มีผลบังคับใช้ Claude Code จะตัดสินใจเป็นรายข้อความโดยเปรียบเทียบโหมดสิทธิ์ของทั้งสองเซสชัน โดยจะจัดกลุ่มเซสชันที่ข้ามการแจ้งเตือนขอสิทธิ์ไว้ในกลุ่มหนึ่ง และเซสชันที่เหลือไว้อีกกลุ่มหนึ่ง โดย auto, acceptEdits และ dontAsk ถือเป็นการแจ้งเตือนขอสิทธิ์ ส่วนโหมด Plan จะถือว่าเป็นการข้ามการแจ้งเตือนในเซสชันที่มีสิทธิ์ข้ามการแจ้งเตือนพร้อมใช้งาน กฎที่ใช้จึงมีความสมมาตรดังนี้:

• เซสชันผู้รับที่แจ้งเตือนขอสิทธิ์จะได้รับข้อความทุกฉบับ โดยจะพักข้อความไว้ก็ต่อเมื่อเซสชันผู้ส่งระบุตัวตนว่าเป็นการข้ามการแจ้งเตือนเท่านั้น
• เซสชันผู้รับที่ข้ามการแจ้งเตือนจะพักข้อความทุกฉบับไว้รอการอนุมัติจากคุณ โดยจะส่งข้อความก็ต่อเมื่อผู้ส่งมีการข้ามการแจ้งเตือนเช่นกัน

ดังนั้น เวิร์กโฟลว์แรกที่คนส่วนใหญ่สร้างขึ้นมักเป็นเวิร์กโฟลว์ที่ใช้งานไม่ได้จริง คุณเริ่มการทำงานของ builder ด้วย --permission-mode bypassPermissions เพราะต้องการให้ทำงานโดยไม่ต้องเฝ้าหน้าจอ คุณปล่อยให้ reviewer ใช้ค่าเริ่มต้น และทุกข้อความที่ builder ส่งไปจะไปค้างอยู่ในกล่องโต้ตอบการอนุมัติที่ไม่มีใครเฝ้าดู กล่องโต้ตอบนั้นจะปิดลงหลังจากครบกำหนดเวลา dialogExpiry ซึ่งมีค่าเริ่มต้นเป็น 5m และข้อความนั้นจะถูกทิ้งไป บนเครื่องเดียวกัน เซสชันผู้ส่งจะได้รับแจ้งเตือนเมื่อข้อความถูกพักไว้ และได้รับแจ้งเตือนติดตามผลเมื่อผู้รับทำการส่ง ปฏิเสธ หรือหมดเวลาในภายหลัง ดังนั้นโปรดอ่านหน้าจอของผู้ส่งก่อนที่จะโทษว่าปัญหาอยู่ที่ socket

เพื่อให้เซสชันรับข้อความได้โดยไม่ต้องเฝ้าหน้าจอ ให้ตั้งค่า crossSessionInbound เป็น accept ตำแหน่งที่คุณตั้งค่าจะเป็นตัวกำหนดว่าค่าดังกล่าวมีผลหรือไม่ Claude Code จะอ่านการตั้งค่าที่จัดการไว้ก่อน ตามด้วยแฟล็ก --settings แล้วจึงอ่านการตั้งค่าของผู้ใช้ และจะใช้ค่าแรกที่พบ ค่าในการตั้งค่าระดับโปรเจกต์หรือระดับท้องถิ่นจะมีผลก็ต่อเมื่อมีความเข้มงวดมากกว่าเท่านั้น โดยเรียงลำดับจาก accept < hold < refuse ค่า accept ใน .claude/settings.json นั้นมีความเข้มงวดน้อยกว่าค่าอื่นทั้งหมด จึงถูกละเลยเสมอเมื่อมีแหล่งที่เชื่อถือได้กำหนดค่าไว้แล้ว ให้ใส่ค่าดังกล่าวไว้ใน ~/.claude/settings.json หรือส่งผ่านค่านี้สำหรับเซสชันเดียว:

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

Worker แบบ headless claude -p จะผูกเข้ากับ inbox socket เหมือนกับเซสชันแบบโต้ตอบและปรากฏในรายการ แต่จะไม่สามารถแสดงกล่องโต้ตอบการอนุมัติได้ ข้อความที่ถูกพักไว้ในนั้นจะยังคงถูกพักไว้จนกว่าโหมดหรือการตั้งค่าในภายหลังจะอนุญาตให้ส่งได้ บรรทัด --settings ด้านบนคือวิธีที่คุณอนุญาตให้ worker ดังกล่าวรับข้อความได้ ส่วนเซสชันที่เริ่มในโหมด bare จะไม่ผูกกับ socket ใดๆ เลย จึงไม่สามารถรับข้อความหรือปรากฏในรายการได้

จุดที่การส่งต่องานเกิดภาวะหยุดชะงัก (Deadlock)

การวนซ้ำของข้อความจะได้รับการจัดการให้โดยอัตโนมัติ Claude Code จะจำกัดอัตราการส่งข้อความซ้ำต่อผู้ส่งหนึ่งราย ทิ้งข้อความที่เหมือนกันซึ่งส่งเข้ามาภายในช่วงเวลาสั้นๆ และจำกัดจำนวนข้อความที่รอการอ่านไว้ที่ 50 ข้อความต่อเซสชัน เพื่อป้องกันไม่ให้สองเซสชันโต้ตอบกันไปมาไม่สิ้นสุด ข้อความที่ถูกพักไว้จะถูกจำกัดไว้ที่ 100 ข้อความ และข้อความที่เก่าที่สุดจะถูกลบทิ้งหากเกินจำนวนนี้

ความล้มเหลวที่เกิดขึ้นจริงมักจะเงียบกว่านั้น และเป็นปัญหาเรื่องการส่งต่องานมากกว่าการวนซ้ำ เซสชัน A ถามคำถามเซสชัน B ซึ่งจำเป็นต้องได้รับคำตอบก่อนจึงจะดำเนินการต่อได้ จากนั้นเซสชัน A ก็เข้าสู่สถานะว่าง B พักข้อความนั้นไว้ หรือ B กำลังประมวลผลงานที่ยาวนาน หรือ B ตอบคำถามที่ A ไม่ได้ถามจริงๆ เซสชัน A จึงรอคอย เมื่อคุณกลับมาดูอีกครั้งในหนึ่งชั่วโมงให้หลัง คุณจะพบกับสองเซสชันที่ว่างงานและไม่มีงานใดคืบหน้า

จงเขียนการส่งต่องานที่ไม่จำเป็นต้องรอการตอบกลับ ข้อความที่ดีควรนำเสนอข้อเท็จจริงหรือการตัดสินใจ เช่น มีอะไรเปลี่ยนแปลงไปบ้างและผลลัพธ์เป็นอย่างไร ข้อความที่ไม่ดีคือการที่เซสชันหนึ่งขออนุญาตจากอีกเซสชันหนึ่ง หรือขอคำตอบที่ผู้ส่งกำลังติดขัดอยู่ Claude ได้รับคำสั่งไว้แล้วว่าห้ามขอให้เซสชันอื่นดำเนินการใดๆ ที่การตั้งค่าสิทธิ์ของตัวมันเองไม่อนุญาต และให้ส่งต่องานนั้นกลับมาที่คุณแทน คุณควรนำกฎนี้ไปปรับใช้ด้วย หากเซสชันหนึ่งไม่สามารถดำเนินการต่อได้โดยไม่มีคำตอบ คุณคือผู้ที่ควรเป็นคนตอบคำถามนั้น การรักษาวินัยด้านบริบท (Context) ก็ช่วยได้เช่นกัน เพราะเซสชันที่สูญเสียลำดับความคิดมักจะเขียนข้อความที่คลุมเครือ ซึ่งเนื้อหาเรื่อง การจัดการบริบทใน Claude Code ได้ครอบคลุมประเด็นดังกล่าวไว้แล้ว

การจัดการข้อความขาเข้าเสมือนข้อมูลที่ไม่น่าเชื่อถือ

Claude Code จะแจ้งให้ Claude ฝั่งรับทราบว่าข้อความดังกล่าวมาจากเซสชันอื่นและไม่ใช่จากตัวคุณเอง พร้อมทั้งจำกัดขอบเขตการทำงานของข้อความนั้น ข้อความดังกล่าวไม่สามารถตอบรับคำขออนุญาตที่ค้างอยู่แทนคุณได้ เนื่องจากการยินยอมจากเซสชันอื่นไม่ใช่การยินยอมของคุณ นอกจากนี้ยังไม่สามารถเปลี่ยนแปลงการตั้งค่าสิทธิ์ CLAUDE.md หรือการกำหนดค่าอื่น ๆ ตามคำขอของเซสชันอื่นได้ คำสั่ง slash ภายในข้อความ เช่น /compact จะถูกส่งมาเป็นข้อความธรรมดาและจะไม่ถูกประมวลผล หากการดำเนินการตามข้อความนั้นจำเป็นต้องใช้สิทธิ์ที่เซสชันฝั่งรับไม่มี คุณจะเห็นคำขออนุญาตเช่นเดียวกับงานอื่น ๆ ในโหมดอัตโนมัติจะมีตัวจำแนกประเภท (classifier) คอยตรวจสอบข้อความแต่ละฉบับก่อนส่งมอบ หากข้อความใดถูกบล็อก ข้อความนั้นจะไปไม่ถึงผู้รับ ข้อจำกัดเหล่านี้ยังคงมีผลแม้ในโหมดที่อนุญาตให้ทำงานได้กว้างขวาง (permissive modes) ซึ่งเป็นเหตุผลว่าทำไมเซสชันที่พยายามข้ามการตรวจสอบจึงระงับข้อความขาเข้าไว้โดยค่าเริ่มต้นแทนที่จะเชื่อถือข้อความเหล่านั้น

นั่นคือส่วนที่ครอบคลุมเรื่องสิทธิ์ แต่ไม่ครอบคลุมถึงเนื้อหา เซสชันฝั่งส่งอาจอ่านคำอธิบาย pull request, หน้าเว็บ, ไฟล์ README ของ dependency หรือความคิดเห็นใน issue ที่เขียนโดยบุคคลภายนอก และสิ่งที่อ่านมานั้นสามารถกำหนดรูปแบบข้อความที่เขียนไปยังเซสชันอื่นของคุณได้ ข้อความถือเป็นข้อมูล จึงควรได้รับการปฏิบัติด้วยความระมัดระวังเช่นเดียวกับข้อความอื่น ๆ ที่เข้าสู่เซสชันจากภายนอก นี่คือหลักการที่อธิบายไว้ใน การป้องกันไม่ให้ความลับรั่วไหลไปยัง AI agents ของคุณ: ให้สันนิษฐานว่าข้อมูลใดก็ตามที่ข้ามขอบเขตความเชื่อถือ (trust boundary) อาจไม่ถูกต้อง และอย่าปล่อยให้ข้อมูลนั้นอนุญาตตัวเองโดยเด็ดขาด

มีตัวควบคุมสองประการหากคุณต้องการลดการทำงานในส่วนนี้ การตั้งค่า crossSessionInbound เป็น refuse จะเป็นการยกเลิกข้อความจาก peer ขาเข้าโดยไม่ส่งมอบ และหากตั้งค่าจากโปรเจกต์หรือการตั้งค่าภายในเครื่อง ค่านี้จะมีผลเหนือแหล่งที่มาอื่นทั้งหมดเนื่องจากเป็นระดับที่เข้มงวดที่สุด หากต้องการหยุดไม่ให้เซสชันนี้ส่งหรือแสดงรายการข้อความ ให้เพิ่มกฎการปฏิเสธสิทธิ์โดยระบุชื่อ SendMessage และ ListAgents ซึ่งทั้งคู่ต้องเขียนเป็นชื่อเครื่องมือเปล่า ๆ โดยไม่มีตัวระบุ การตั้งค่า isolatePeerMachines เป็น true จะกำหนดให้ต้องได้รับการอนุมัติจากคุณอย่างชัดเจนก่อนที่ข้อความใด ๆ จะไปถึงเซสชันที่อยู่นอกเหนือเครื่องนี้ และการอนุมัตินั้นจำเป็นต้องมีแม้ในโหมด bypassPermissions

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

การปฏิเสธ SendMessage จะเป็นการลบการส่งข้อความไปยัง subagents ด้วย เนื่องจากใช้เครื่องมือเดียวกันในการทำงานทั้งสองอย่าง เซสชันที่ปฏิเสธการทำงานจะไม่แสดงการเปลี่ยนแปลงที่มองเห็นได้ใน /status ของตนเองหรือในรายการของเซสชันอื่น ดังนั้นควรยืนยันการตั้งค่าจากการกำหนดค่าของเซสชันนั้นโดยตรงแทนการดูจากหน้าจอ

Bridges และ MCP servers แบบ shared memory

ในช่วงเวลาเดียวกันมีโครงการจากภายนอกหลายโครงการที่ทำหน้าที่ใกล้เคียงกัน ได้แก่ bridge แบบ local agent-to-agent ที่ส่งต่อข้อความระหว่าง agent ที่กำลังทำงานอยู่ และ MCP (model context protocol) servers ที่จัดเตรียมพื้นที่จัดเก็บข้อมูลส่วนกลางให้ agent หลายตัวสามารถอ่านและเขียนได้ ให้พิจารณาว่าสิ่งเหล่านี้เป็นรูปแบบการทำงานที่แตกต่างออกไปแทนที่จะมองว่าเป็นคู่แข่ง และตรวจสอบคำสั่งติดตั้งกับไฟล์ README ของโครงการนั้นๆ ให้แน่ใจก่อนดำเนินการ การส่งข้อความจะเป็นแบบ push เนื่องจากผู้ส่งจะใส่ข้อความลงในรอบการทำงานของผู้รับ ส่วนพื้นที่จัดเก็บข้อมูลส่วนกลางจะเป็นแบบ pull เนื่องจากไม่มีการขัดจังหวะการทำงาน และ session จะเห็นบันทึกเมื่อมีการตรวจสอบในครั้งถัดไป รูปแบบ pull จะมีความเสถียรกว่าสำหรับสถานะที่มีการเปลี่ยนแปลงช้า และจะทำงานก็ต่อเมื่อ session เข้ามาตรวจสอบเท่านั้น

หากคุณเลือกใช้วิธีนี้ คำถามที่ควรพิจารณาคือเรื่องของกระบวนการมากกว่ารายการฟีเจอร์ เช่น server ทำงานภายใต้ user ใด และสามารถอ่านข้อมูลอะไรบนเครื่องได้บ้าง การรัน MCP servers บน VPS ครอบคลุมการตั้งค่าดังกล่าว การแชร์ทักษะของ agent ข้าม repository ครอบคลุมกรณีที่ง่ายกว่าซึ่งคุณต้องการแชร์คำสั่งระหว่าง session แทนที่จะเป็นสถานะแบบสด ซึ่งช่วยลดจำนวนข้อความที่คุณต้องส่งลงได้มาก สำหรับภาพรวมที่กว้างขึ้น การรัน coding agent บน VPS คือจุดเริ่มต้นที่เหมาะสม

FAQ

ทำไม /list-agents ถึงไม่ถูกจดจำในเซสชันของฉัน?

เซสชันดังกล่าวไม่มีการรับส่งข้อความข้ามเซสชัน ให้ตรวจสอบ claude --version เทียบกับ 2.1.224 ก่อน เนื่องจากฟีเจอร์นี้ต้องการเวอร์ชันดังกล่าวหรือใหม่กว่า จากนั้นให้ตรวจสอบแพลตฟอร์ม เพราะฟีเจอร์นี้ทำงานบน macOS และ Linux เท่านั้น ไม่รองรับ Windows แบบ native และไม่สามารถใช้งานได้บน 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 ที่ฟีเจอร์นี้ต้องใช้ ทำให้ฟีเจอร์ถูกปิดการทำงาน

ทำไมข้อความที่ส่งไปยังอีกเซสชันจึงไม่ถึงปลายทาง?

หาก /list-agents ทำงานได้ปกติ แสดงว่าระบบรับส่งข้อความเปิดอยู่ และมีปัจจัยที่จำกัดกว่านั้นขัดขวางข้อความดังกล่าว สาเหตุที่พบบ่อยคือโหมดสิทธิ์การเข้าถึง เซสชันที่ข้ามการแจ้งเตือนขอสิทธิ์จะพักข้อความขาเข้าทุกรายการไว้รอการอนุมัติจากคุณ เว้นแต่ผู้ส่งจะข้ามการแจ้งเตือนเช่นกัน และกล่องโต้ตอบการอนุมัตินั้นจะถูกยกเลิกหลังจากครบกำหนดเวลา dialogExpiry ซึ่งค่าเริ่มต้นคือ 5 นาที ให้ตรวจสอบเซสชันผู้ส่งว่ามีการแจ้งเตือนค้างอยู่หรือไม่ ในการแก้ไขปัญหานี้ ให้ตั้งค่า crossSessionInbound เป็น accept ใน ~/.claude/settings.json หรือส่งผ่านด้วย --settings เนื่องจาก accept ในการตั้งค่าโปรเจกต์หรือการตั้งค่าภายในเครื่องจะถูกละเว้นเพราะถือเป็นค่าที่หละหลวมกว่า

เซสชัน Claude Code ใน Docker สามารถส่งข้อความหาเซสชันบนโฮสต์ได้หรือไม่?

ไม่ได้ เซสชันต่างๆ จะค้นหากันผ่านไฟล์ลงทะเบียนในดิสก์และ socket กล่องข้อความประจำเซสชัน ซึ่งคอนเทนเนอร์มีระบบไฟล์เป็นของตัวเอง ทั้งสองจึงไม่สามารถมองเห็นไฟล์เดียวกันได้ แต่เซสชันสองเซสชันที่อยู่ภายในคอนเทนเนอร์เดียวกันสามารถส่งข้อความถึงกันได้ตามปกติ กฎเดียวกันนี้อธิบายว่าทำไมเซสชันที่รันในฐานะ root และเซสชันที่รันในฐานะผู้ใช้ปกติของคุณจึงไม่สามารถติดต่อกันได้ เนื่องจาก socket ถูกจำกัดไว้เฉพาะผู้ใช้ระบบปฏิบัติการที่เป็นเจ้าของเท่านั้น

ข้อความจากเซสชัน Claude Code อื่นมีความปลอดภัยที่จะดำเนินการตามหรือไม่?

ให้ถือว่าข้อความเป็นข้อมูลนำเข้าที่ไม่น่าเชื่อถือ เนื่องจากเซสชันผู้ส่งอาจอ่านหน้าเว็บ, ไฟล์ README หรือความคิดเห็นใน issue ที่เขียนโดยผู้อื่นมา Claude Code มีการป้องกันไม่ให้ข้อความนั้นดำเนินการด้วยตัวเองอยู่แล้ว เช่น ไม่สามารถอนุมัติการแจ้งเตือนขอสิทธิ์ที่ค้างอยู่ ไม่สามารถเปลี่ยนการตั้งค่าสิทธิ์หรือ CLAUDE.md ตามคำขอ และ slash command ในข้อความจะถูกส่งมาเป็นข้อความธรรมดาและไม่ทำงาน การป้องกันเหล่านี้ครอบคลุมเฉพาะเรื่องสิทธิ์ ไม่ใช่การตัดสินใจ ดังนั้นโปรดอ่านสิ่งที่ได้รับก่อนที่จะสั่งให้เซสชันผู้รับดำเนินการตาม

การรับส่งข้อความข้ามเซสชันส่งโค้ดของฉันไปยัง Anthropic หรือไม่?

ระหว่างสองเซสชันบนเครื่องเดียวกัน คำตอบคือไม่ ข้อความจะเดินทางผ่าน socket ประจำเซสชันบนเครื่องนั้นและไม่ผ่านเซิร์ฟเวอร์ของ Anthropic โดยจะส่งเฉพาะข้อความที่ Claude เขียนเท่านั้น ไม่มีการส่งประวัติการสนทนาหรือไฟล์ ส่วนข้อความที่ส่งไปยังเซสชันบนเครื่องอื่นของคุณ หรือเซสชันบนเว็บ จะเดินทางผ่านเซิร์ฟเวอร์ของ Anthropic ผ่านการเชื่อมต่อ Remote Control และในทิศทางนั้น Claude สามารถตอบกลับข้อความที่ได้รับมาเท่านั้น ไม่สามารถเป็นผู้เริ่มส่งข้อความได้ ให้ตั้งค่า isolatePeerMachines เป็น true เพื่อกำหนดให้ต้องได้รับการอนุมัติจากคุณก่อนที่ข้อมูลใดๆ จะออกจากเครื่อง