วิธีใช้งาน Claude Code ส่งข้อความข้าม session บน VPS

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

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

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

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

เมื่อการเปิดเซสชันที่สองคุ้มค่ากับโทเค็นที่เสียไป

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

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

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

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

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

ขั้นแรกให้ตรวจสอบเวอร์ชัน:

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 จึงไม่ทำงาน ค่าเหล่านี้อาจมาจากแผนผัง env ในไฟล์การตั้งค่าหรือจากการตั้งค่าที่มีการจัดการไว้ ดังนั้นควรตรวจสอบเชลล์ก่อนเป็นอันดับแรก

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 เนื่องจากทั้งสองเซสชันมีหน้าที่ต่างกัน จึงควรให้ผู้ตรวจสอบใช้ รูปแบบการแสดงผล ของตนเอง ซึ่งจะเปลี่ยน 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 พร้อมกับไดเรกทอรีทำงานคือ ~/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 เซิร์ฟเวอร์เดียวกันก็ตาม เนื่องจากเซสชันของผู้ใช้คนหนึ่งไม่สามารถเข้าถึง socket ของผู้ใช้อีกคนหนึ่งได้ ให้รันทั้งสองเซสชันด้วยผู้ใช้คนเดียวกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

มีตัวควบคุมสองประการหากคุณต้องการลดการทำงานในส่วนนี้ การตั้งค่า 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 เนื่องจากผู้ส่งจะใส่ข้อความลงในรอบการทำงานของผู้รับ ส่วน shared store จะเป็นแบบ pull เนื่องจากไม่มีการขัดจังหวะการทำงาน และ session จะเห็นบันทึกเมื่อมีการเรียกดูในครั้งถัดไป รูปแบบ pull จะมีความเสถียรกว่าสำหรับสถานะที่มีการเปลี่ยนแปลงช้า และจะทำงานก็ต่อเมื่อ session เข้ามาตรวจสอบเท่านั้น

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

FAQ

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

เซสชันไม่มีการรับส่งข้อความข้ามเซสชัน ให้ตรวจสอบ claude --version เทียบกับเวอร์ชัน 2.1.224 ก่อน เนื่องจากฟีเจอร์นี้ต้องการเวอร์ชันดังกล่าวหรือใหม่กว่า จากนั้นให้ตรวจสอบแพลตฟอร์ม เนื่องจากฟีเจอร์นี้ทำงานบน macOS และ Linux เท่านั้น ไม่รองรับ Windows แบบ native และไม่สามารถใช้งานได้บน Amazon Bedrock, Claude Platform บน 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 ทำงานได้ปกติ แสดงว่าระบบรับส่งข้อความเปิดอยู่ และมีปัจจัยที่จำกัดกว่านั้นที่ขัดขวางข้อความดังกล่าว สาเหตุที่พบบ่อยคือโหมดสิทธิ์การเข้าถึง (permission modes) เซสชันที่ข้ามการแจ้งเตือนขอสิทธิ์จะพักข้อความขาเข้าทุกรายการไว้เพื่อรอการอนุมัติจากคุณ เว้นแต่ผู้ส่งจะข้ามการแจ้งเตือนเช่นกัน และกล่องโต้ตอบการอนุมัตินั้นจะถูกยกเลิกหลังจากครบกำหนดเวลา dialogExpiry ซึ่งโดยปกติคือ 5 นาที ให้ตรวจสอบเซสชันผู้ส่งว่ามีการแจ้งเตือนค้างอยู่หรือไม่ วิธีแก้ไขคือตั้งค่า crossSessionInbound เป็น accept ใน ~/.claude/settings.json หรือส่งผ่านด้วย --settings เนื่องจาก accept ในการตั้งค่าระดับโปรเจกต์หรือระดับเครื่องจะถูกละเว้นเพราะถือเป็นค่าที่หละหลวมกว่า

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

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

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

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

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

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