Claude Code: Cách các session nhắn tin cho nhau

Ý nghĩa của việc các session Claude Code nhắn tin cho nhau

Hai session Claude Code có thể nhắn tin cho nhau khi cùng chạy trên một máy và dưới cùng một user của hệ điều hành. Một message là một đoạn plain text do một Claude viết cho Claude khác. Message không chứa lịch sử hội thoại hoặc file. Claude tìm session còn lại bằng tool ListAgents và gửi text bằng SendMessage, nên bạn không bao giờ gọi trực tiếp hai tool này. Bạn nói session còn lại cần biết điều gì, rồi Claude tự viết message.

Tính năng này được gọi là cross-session messaging. Tính đến tháng 10 năm 2026, tính năng cần Claude Code v2.1.224 trở lên trên macOS và Linux, bao gồm Linux chạy bên trong WSL 2, và v2.1.234 trở lên trên Windows native. Messaging giữa các session trên cùng một máy hoạt động với mọi provider, bao gồm Amazon Bedrock, Claude Platform trên AWS, Google Cloud's Agent Platform và Microsoft Foundry; các provider này cần v2.1.248 trở lên. Kết nối đến session trên máy khác hoặc trên cloud bị giới hạn hơn: kết nối đi qua Remote Control, tính năng này cần đăng nhập claude.ai, nên không hoạt động với API key hoặc với 4 provider trên. Khi session đáp ứng các yêu cầu này, messaging đã được bật sẵn và không cần enable gì thêm. Hành vi được mô tả bên dưới dựa trên tài liệu Anthropic về cross-session messaging.

VPS là nơi tính năng này thực sự hữu ích, vì session trên VPS chạy đủ lâu để bạn cần gửi message đến chúng. Trên laptop, bạn đóng nắp máy. Trên server chạy dưới tmux, session bạn khởi động vào thứ Hai vẫn còn chạy vào thứ Năm và vẫn giữ context của một repository. Khi có 2 session như vậy, cách chúng trao đổi không còn là vấn đề lý thuyết. Nếu chưa thiết lập, hãy bắt đầu với chạy Claude Code trên VPS dưới tmux. Phần này hướng dẫn cách quản lý session mà guide này giả định bạn đã có.

Khi một session thứ hai đáng với số token bỏ ra

Hãy bắt đầu từ chi phí. Mỗi session là một instance Claude riêng với context window riêng, vì vậy 2 session có chi phí gần gấp đôi 1 session trong cùng một khoảng thời gian. Một message được gửi cũng được tính vào mức sử dụng giống hệt prompt bạn tự nhập. Việc phối hợp không miễn phí, và những công việc thực chất chỉ là một chuỗi bước sẽ chậm hơn, tốn kém hơn khi bạn chia chúng qua nhiều session.

Các trường hợp session thứ hai mang lại hiệu quả đều có cùng một đặc điểm. 2 phần việc chạy đồng thời mà không phải chờ nhau, và trong quá trình thực hiện, một phần biết được thông tin mà phần còn lại cần.

• Một session phát hiện breaking change trong khi session kia đang xây dựng dựa trên code đã bị thay đổi. Claude tóm tắt thay đổi và gửi cho session kia, thay vì để bạn nhập lại trong terminal khác.
• 2 session làm việc trên cùng một repository trong các git worktree riêng, và một session cần biết thay đổi nào đã được tích hợp.
• Một migration hoặc test run kéo dài gửi kết quả về session mà bạn đang theo dõi.
• Một session builder và một session reviewer, trong đó reviewer đọc sản phẩm do builder tạo ra rồi gửi lại các phát hiện.

Khi công việc có tính tuần tự, hoặc khi cả 2 session sẽ chỉnh sửa cùng một file, hãy dùng 1 session. Khi bạn muốn một nhóm được Claude tạo và giám sát trong cùng một task, đó là agent teams, một tính năng riêng vẫn đang ở giai đoạn experimental. Khi bạn chỉ muốn mở cùng cuộc trò chuyện trong một terminal khác, hãy resume session thay vì tạo session mới. Cross-session messaging dành cho các session độc lập mà bạn tự khởi động và điều khiển.

Kiểm tra tính năng trước khi thiết kế theo nó

Trước tiên, kiểm tra version:

claude --version

So sánh con số này với 2.1.224. Sau đó, trong một session, nhập /list-agents, lệnh này cũng có thể gọi bằng /peers. Lệnh sẽ in ra mọi agent mà session này có thể liên lạc, cùng với tên mà từng agent phản hồi. Nếu lệnh hoàn toàn không được nhận diện, session này không có tính năng nhắn tin giữa các session và không giá trị crossSessionInbound nào có thể bật tính năng đó. Nhập /status và tìm dòng Peer address: dòng này chứa địa chỉ inbox của chính session hiện tại, bắt đầu bằng uds:.

Người dùng VPS trên các build cũ thường gặp một vấn đề. Trước v2.1.248, tính năng nhắn tin giữa các session trên cùng một máy phụ thuộc vào việc lấy feature flag. Một số biến privacy sẽ tắt việc lấy này, khiến tính năng giữ nguyên trạng thái mặc định là tắt. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC và DISABLE_GROWTHBOOK đều có tác dụng như vậy. Người dùng thường harden server mới bằng cách dán các biến đó vào ~/.bashrc, rồi thắc mắc vì sao /list-agents không tồn tại. Từ v2.1.248, nhắn tin giữa các session trên cùng một máy vẫn hoạt động khi đã tắt việc lấy feature flag, nên update là cách xử lý gọn hơn. Các biến này vẫn quan trọng với những session nằm ngoài máy hiện tại: khi đã tắt việc lấy feature flag, Claude chỉ có thể truy cập các session đó khi Remote Control khả dụng, còn CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC và DISABLE_GROWTHBOOK sẽ làm Remote Control không khả dụng. Các giá trị tương tự cũng có thể được nạp từ map env trong file settings hoặc từ managed settings, vì vậy hãy kiểm tra shell trước.

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

Trên build cũ, hãy unset biến nào được in ra. Với DISABLE_TELEMETRY và CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, mọi giá trị không rỗng đều bật hành vi này, kể cả chuỗi 0, nên DISABLE_TELEMETRY=0 không có tác dụng như vẻ ngoài của nó. Để tắt, hãy unset biến hoặc đặt biến thành chuỗi rỗng.

Đặt tên cho session để Claude có thể xác định đúng session

Claude gửi message đến một session bằng tên của session đó. Hãy đặt tên khi bạn khởi động session:

claude --name builder-api

Bạn cũng có thể đặt tên bằng /rename trong một session đang chạy. Nếu không đặt tên, Claude Code sẽ lấy tên từ tên thư mục của working directory, chẳng hạn như myapp-3f. Cách này phù hợp với một session, nhưng dễ gây nhầm lẫn khi có bốn session; hai session cũng có thể có cùng tên. Nếu session không kết nối với Remote Control, output /list-agents sẽ hiển thị working directory của từng session local, nhờ đó phân biệt được các session trùng tên. Danh sách của Claude cũng thêm một identifier ngắn vào address khi tên bị trùng. Tự đặt tên vẫn nhanh hơn việc đọc các identifier. Tên do bạn đặt cũng giúp tính năng typeahead @ hữu ích hơn: từ v2.1.232, khi nhập @builder vào prompt rồi chọn session, bạn sẽ chỉ rõ chính xác session mà Claude cần dùng.

Bố cục tmux hai session có thể tái tạo

Đây là một session builder và một session reviewer trên cùng một repository. Reviewer làm việc trong một git worktree riêng, nên hai session không bao giờ ghi vào cùng một file. git worktree add cùng với HEAD tạo một checkout detached, phù hợp với session chỉ đọc mà không commit. Vì hai session thực hiện các công việc khác nhau, nên đặt cho reviewer một style đầu ra riêng. Style này thay đổi system prompt của session đó và áp dụng cho mọi turn, thay vì mất tác dụng như một instruction bạn chỉ nhập một lần.

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 rồi w liệt kê các window theo tên để bạn chọn. Trong window builder, chạy /list-agents. Bạn sẽ thấy reviewer-api cùng working directory là ~/src/api-review. Nếu không thấy, session reviewer chưa khởi động xong hoặc một trong hai vấn đề ở phần tiếp theo đang xảy ra. Sau đó, bàn giao công việc bằng ngôn ngữ tự nhiên:

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

Claude viết summary rồi gửi đi. Bạn không viết nội dung message, và nội dung Claude gửi sẽ thay đổi. Trong window reviewer, message xuất hiện dưới dạng preview một dòng mờ, có tên người gửi và dòng đầu tiên của nội dung, chẳng hạn › Message from @builder-api: …. Nếu session đó đang idle, Claude sẽ bắt đầu một turn mới ngay. Nếu session đang giữa một turn, message sẽ chờ đến giữa các lần gọi tool, nên command đang chạy không bao giờ bị ngắt. Ctrl+O mở transcript viewer với toàn bộ nội dung, và Claude đọc toàn bộ message dù bạn có mở rộng nó hay không. Hai session hoạt động hiệu quả hơn khi builder giữ các thay đổi nhỏ, vì diff hẹp tạo ra hand-off ngắn hơn và giúp session còn lại hoàn tất review trong một turn. Đây là thói quen mà kỹ năng lazy senior dev được tạo ra để duy trì.

Ai có thể nhìn thấy ai trên cùng một VPS

Việc chuyển tin giữa các session trên cùng máy không đi qua server Anthropic. Mỗi session bind vào một inbox socket riêng, là Unix domain socket có path trên filesystem của máy đó. Một session chỉ xuất hiện trong danh sách của các session khác khi nó bind vào socket này. Điều này dẫn đến 2 hệ quả, và cả hai đều đáng lưu ý trên server.

Socket chỉ cho phép user của hệ điều hành đã tạo session truy cập. Một session bạn khởi chạy bằng root và một session bạn khởi chạy bằng deploy sẽ không nhìn thấy nhau, dù chạy cạnh nhau trong cùng một tmux server, vì session của user này không thể truy cập socket của user kia. Hãy chạy cả hai session bằng cùng một user.

Container có filesystem riêng. Một session bên trong Docker và một session trên host không thể truy cập lẫn nhau. Hai session bên trong cùng một container vẫn có thể gửi tin nhắn cho nhau bình thường. Nếu bạn giữ các agent trong container để tăng tính cô lập, như trong chạy coding agent trong một VM dùng một lần, hãy dự kiến messaging chỉ hoạt động bên trong container, không hoạt động qua ranh giới container.

Các session của bạn trên máy khác và các cloud session chỉ xuất hiện trong danh sách khi session này đang kết nối với Remote Control. Các session trên máy khác được gắn nhãn Remote Control. Từ v2.1.225, Claude có thể bắt đầu cuộc hội thoại với một trong các session đó, không chỉ trả lời. Các message này đi qua server Anthropic. Nếu session này không kết nối với Remote Control khi Claude gửi message ra ngoài máy, message vẫn được gửi đi nhưng không có địa chỉ trả lời, nên phía bên kia không thể trả lời.

Vì sao message của bạn không bao giờ đến nơi

Lý do thường gặp không liên quan đến network. Session nhận đã quyết định cách xử lý message, và quyết định đó là không deliver. Mỗi message đến nơi sẽ kết thúc theo một trong ba trạng thái: delivered (đã deliver), held (tạm giữ, chưa deliver cho đến khi bạn approve), hoặc refused (bị từ chối và drop mà không deliver).

Khi không có giá trị crossSessionInbound áp dụng, Claude Code quyết định cho từng message bằng cách so sánh permission mode của hai session. Các session bypass permission prompt được xếp vào một nhóm, mọi session khác được xếp vào nhóm còn lại. auto, acceptEdits và dontAsk được tính là prompting. Trong một interactive terminal session có sẵn quyền bypass, Plan mode được tính là bypass. Nếu không chắc một session thuộc nhóm nào, trước tiên bạn nên đọc permission mode thực sự hoạt động như thế nào, vì auto là mode mà hiện nay phần lớn session bắt đầu với nó và nó thuộc phía prompting trong phân chia này. Quy tắc có tính đối xứng:

• Session nhận dùng prompting sẽ deliver mọi message. Session này chỉ hold message khi session gửi tự xác nhận là đang bypass prompt.
• Session nhận đang bypass prompt sẽ hold mọi message để bạn approve. Session này chỉ deliver message khi session gửi cũng đang bypass.

Vì vậy, workflow đầu tiên mà đa số mọi người xây dựng lại chính là workflow không hoạt động. Bạn khởi động builder với --permission-mode bypassPermissions vì muốn nó chạy unattended, để reviewer dùng giá trị mặc định, rồi mọi message do builder gửi đều nằm chờ trong approval dialog mà không ai theo dõi. Dialog đó đóng sau deadline dialogExpiry, mặc định là 5m, và message bị drop. Hãy kiểm tra màn hình của session nhận để tìm approval dialog đang chờ trước khi đổ lỗi cho socket.

Để session nhận message unattended, đặt crossSessionInbound thành accept. Vị trí bạn đặt giá trị này quyết định phạm vi áp dụng. Claude Code đọc managed settings trước, sau đó đọc flag --settings, rồi đến user settings và áp dụng giá trị đầu tiên tìm thấy. Giá trị trong project hoặc local settings chỉ được áp dụng khi nó nghiêm ngặt hơn, theo thứ tự accept < hold < refuse. Giá trị accept trong .claude/settings.json là lỏng nhất nên sẽ bị bỏ qua bất cứ khi nào một trusted source đã đặt giá trị. Đặt nó trong ~/.claude/settings.json hoặc truyền giá trị này cho một session. Từ v2.1.232, dòng /config Messages from your other sessions sẽ ghi cùng user setting đó giúp bạn.

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

Một worker claude -p headless bind vào inbox socket giống interactive session và xuất hiện trong listing, nhưng không thể hiển thị approval dialog. Claude Code giữ message ở đó trong cùng deadline dialogExpiry, mặc định là năm phút, deliver message nếu mode hoặc settings thay đổi cho phép trong khoảng thời gian đó; nếu không, message bị drop và được báo là expired cho sender mà nó còn kết nối được. Dòng --settings ở trên là cách để worker như vậy nhận message. Session được khởi động ở bare mode hoàn toàn không bind socket, nên không thể nhận message hoặc xuất hiện trong danh sách.

Khi bàn giao bị kẹt

Các vòng lặp message đã được xử lý tự động. Claude Code giới hạn tần suất các message lặp lại từ cùng một sender, loại bỏ các message giống hệt nhau nếu đến trong một khoảng thời gian ngắn, và giới hạn số message được chấp nhận nhưng chưa đọc ở mức 50 cho mỗi session. Vì vậy, hai session không thể ping-pong vô hạn. Số message đang chờ cũng bị giới hạn ở 100; các message cũ nhất sẽ bị loại bỏ khi vượt quá giới hạn này. Từ v2.1.238, session gửi sẽ được thông báo khi inbox của session nhận loại bỏ một message, kèm theo lý do. Một relay chain liên tục đi qua cùng các session cũng sẽ bị ngắt.

Lỗi thực sự xảy ra thường khó nhận biết hơn. Đây là lỗi bàn giao chứ không phải vòng lặp. Session A hỏi session B một câu hỏi mà A cần có câu trả lời trước khi tiếp tục, rồi chuyển sang trạng thái idle. B giữ message đó, hoặc B đang xử lý một lượt dài, hoặc B trả lời một câu hỏi mà A thực ra không hỏi. A tiếp tục chờ. Một giờ sau, bạn quay lại và thấy 2 session đều idle nhưng không có công việc nào hoàn tất.

Hãy viết hand-off không cần phản hồi. Một message tốt chứa một thông tin hoặc một quyết định: điều gì đã thay đổi và kết quả là gì. Một message không tốt yêu cầu session kia cấp quyền, hoặc yêu cầu một câu trả lời mà sender đang bị chặn vì chưa có. Claude đã được hướng dẫn không bao giờ yêu cầu session khác thực hiện một action mà các cài đặt permission của chính session đó sẽ chặn, mà phải chuyển công việc đó lại cho bạn. Bạn cũng nên áp dụng quy tắc này cho các trường hợp khác. Nếu một session không thể tiếp tục mà không có câu trả lời, chính bạn là người nên trả lời session đó. Việc giữ context đúng cách cũng giúp ích, vì session đã mất mạch thường viết message mơ hồ; quản lý context trong Claude Code trình bày phần này.

Coi message đến là dữ liệu đầu vào không đáng tin cậy

Claude Code cho Claude nhận biết rằng message đến từ một session khác chứ không phải từ bạn, đồng thời giới hạn những gì message đó có thể thực hiện. Cơ chế này nằm trong chương trình bao quanh model, không phụ thuộc vào việc model có sẵn sàng tuân thủ hay không. Đây là khác biệt thực tế mà agent harness tạo ra. Message không thể thay bạn trả lời permission prompt đang chờ, vì consent từ session khác không phải consent của bạn. Message cũng không thể thay đổi permission settings, CLAUDE.md hoặc cấu hình khác chỉ vì session khác yêu cầu. Một slash command nằm trong nội dung, chẳng hạn /compact, chỉ được nhận dưới dạng plain text và không bao giờ được thực thi. Nếu xử lý message cần một permission mà session nhận không có, bạn sẽ thấy cùng prompt như khi thực hiện bất kỳ tác vụ nào khác. Khi session gửi chạy ở auto mode, classifier của session đó cũng kiểm tra từng message trước khi Claude Code chuyển message đến nơi nhận. Message bị chặn sẽ không bao giờ đến recipient. Các giới hạn này vẫn có hiệu lực trong những permissive mode. Vì vậy, session đang bypass mặc định giữ lại message đến thay vì tin tưởng chúng.

Phần trên chỉ nói về permissions. Nó không bao quát content. Session gửi có thể đã đọc mô tả pull request, một web page, README của dependency hoặc issue comment do người lạ viết. Bất kỳ nội dung nào nó đọc cũng có thể định hình text mà nó viết cho session khác của bạn. Message là data. Bạn phải nghi ngờ message này như mọi text khác đi vào session từ bên ngoài. Đây là nguyên tắc được mô tả trong giữ secret bên ngoài AI agent của bạn: giả định rằng mọi thứ đi qua trust boundary đều có thể sai, và không bao giờ để nó tự cấp quyền cho chính nó.

Có 2 control nếu bạn muốn giảm tình trạng này. Đặt crossSessionInbound thành refuse sẽ loại bỏ inbound peer message mà không chuyển chúng đến nơi nhận. Khi được đặt trong project settings hoặc local settings, giá trị này có hiệu lực cao hơn mọi source khác vì đây là giá trị strictest trên ladder. Để ngăn session này gửi hoặc liệt kê message, hãy thêm permission deny rule có tên SendMessage và ListAgents. Cả hai phải được viết dưới dạng bare tool name, không có specifier. Đặt isolatePeerMachines thành true sẽ yêu cầu bạn explicit approval trước khi bất kỳ message nào đến một session bên ngoài máy này. Approval này vẫn bắt buộc ngay cả trong bypassPermissions mode.

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

Deny SendMessage cũng tắt việc gửi message đến subagent vì cùng một tool phục vụ cả hai chức năng. Session từ chối không hiển thị thay đổi nào trên /status của chính nó hoặc trong danh sách của session khác. Vì vậy, hãy xác nhận setting từ cấu hình của session thay vì chỉ nhìn trên screen.

Các bridge và MCP server dùng shared memory

Trong cùng giai đoạn đó, một số project bên thứ ba cũng xuất hiện với chức năng gần kề: các bridge agent-to-agent cục bộ chuyển tiếp văn bản giữa những agent đang chạy, và các MCP (model context protocol) server cung cấp một shared store để nhiều agent cùng đọc và ghi. Hãy xem chúng là một mô hình khác, không phải đối thủ cạnh tranh, và kiểm tra mọi lệnh cài đặt trong README của chính project trước khi chạy. Messaging là push vì sender đưa văn bản vào lượt xử lý của receiver. Shared store là pull vì không session nào bị gián đoạn; session sẽ thấy ghi chú khi lần tiếp theo nó kiểm tra store. Pull phù hợp hơn với trạng thái thay đổi chậm và chỉ hoạt động khi session thực sự kiểm tra.

Nếu chọn cách này, các câu hỏi cần đặt ra nên tập trung vào process thay vì danh sách tính năng. Server chạy dưới user nào và có thể đọc những gì trên máy. Chạy MCP server trên VPS trình bày cách thiết lập này. Chia sẻ skill của agent giữa các repo trình bày trường hợp đơn giản hơn, khi thứ bạn muốn chia sẻ giữa các session là instruction thay vì trạng thái runtime; cách này cũng loại bỏ nhiều message mà bạn otherwise phải gửi. Để có cái nhìn tổng quan hơn, chạy coding agent trên VPS là nơi nên bắt đầu.

FAQ

Tại sao /list-agents không được nhận diện trong session của tôi?

Session này không có tính năng nhắn tin giữa các session. Trước tiên, hãy kiểm tra claude --version: tính năng này cần phiên bản 2.1.224 trở lên trên macOS và Linux, 2.1.234 trở lên trên Windows native, và 2.1.248 trở lên trên Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform và Microsoft Foundry. Nếu build cũ hơn 2.1.248, hãy kiểm tra shell để tìm DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC hoặc DISABLE_GROWTHBOOK, vì mỗi biến trong số này đều tắt việc lấy feature flag mà các build cũ cần để nhắn tin. Cập nhật lên 2.1.248 trở lên sẽ loại bỏ dependency này đối với các session trên cùng một máy.

Tại sao message tôi gửi đến session khác không bao giờ đến nơi?

Nếu /list-agents hoạt động, tính năng nhắn tin đã được bật và có một nguyên nhân cụ thể hơn khiến message đó bị chặn. Nguyên nhân thường gặp là permission mode. Một session bỏ qua các permission prompt sẽ giữ mọi message đến để bạn phê duyệt, trừ khi session gửi cũng bỏ qua prompt; dialog phê duyệt đó sẽ bị hủy sau thời hạn dialogExpiry, mặc định là năm phút. Kiểm tra session nhận để tìm dialog phê duyệt đang chờ. Để khắc phục, đặt crossSessionInbound thành accept trong ~/.claude/settings.json hoặc truyền giá trị này bằng --settings, vì một accept trong project settings hoặc local settings sẽ bị bỏ qua nếu đó là giá trị ít nghiêm ngặt hơn.

Session Claude Code trong Docker có thể nhắn tin cho session trên host không?

Không. Inbox của mỗi session là một socket trên filesystem của máy đó, còn container có filesystem riêng. Vì vậy, session bên trong container và session trên host không thể truy cập lẫn nhau. Hai session bên trong cùng một container có thể nhắn tin cho nhau bình thường. Quy tắc tương tự cũng giải thích tại sao session chạy dưới tài khoản root và session chạy dưới user thông thường của bạn không thể truy cập lẫn nhau: socket bị giới hạn cho user của hệ điều hành sở hữu socket đó.

Message từ session Claude Code khác có an toàn để thực hiện không?

Hãy xem nội dung đó là input không đáng tin cậy, vì session gửi có thể đã đọc một web page, README hoặc issue comment do người khác viết. Claude Code đã ngăn message tự thực hiện hành động: nó không thể phê duyệt permission prompt đang chờ, không thể thay đổi permission settings hoặc CLAUDE.md theo yêu cầu, và slash command trong nội dung sẽ đến dưới dạng plain text nên không bao giờ được chạy. Các cơ chế bảo vệ này chỉ bao phủ permission, không bao phủ phán đoán của bạn. Vì vậy, hãy đọc nội dung nhận được trước khi yêu cầu session nhận thực hiện.

Tính năng nhắn tin giữa các session có gửi code của tôi đến Anthropic không?

Giữa 2 session trên cùng một máy thì không. Message đi qua một socket riêng của session trên máy đó và không đi qua các server của Anthropic. Chỉ phần text do Claude viết được gửi đi, không gửi conversation history hoặc file. Message đến session trên một máy khác của bạn hoặc đến cloud session sẽ đi qua các server của Anthropic. Từ v2.1.225, Claude cũng có thể bắt đầu trao đổi đó, ngoài việc trả lời message. Đặt isolatePeerMachines thành true để yêu cầu bạn phê duyệt trước khi bất kỳ nội dung nào rời khỏi máy.