Cara Sesi Claude Code Saling Menghantar Mesej

Maksud sesi Claude Code saling menghantar mesej

Dua sesi Claude Code boleh saling menghantar mesej apabila ia dijalankan pada mesin yang sama, di bawah pengguna sistem pengendalian yang sama. Satu mesej ialah sekeping teks biasa yang ditulis oleh satu Claude untuk Claude yang lain. Ia tidak membawa sejarah perbualan mahupun fail. Claude mencari sesi yang satu lagi dengan alat ListAgents dan menghantar teks tersebut dengan SendMessage, jadi anda tidak perlu memanggil mana-mana alat tersebut secara manual. Anda hanya perlu menyatakan perkara yang perlu diketahui oleh sesi tersebut, dan Claude akan menulis mesej itu sendiri.

Ciri ini dipanggil pemesejan rentas sesi (cross-session messaging). Setakat Ogos 2026, ia memerlukan Claude Code v2.1.224 atau lebih baharu, dan ia berjalan pada macOS serta Linux, termasuk Linux di dalam WSL 2. Tiada sokongan Windows asli, dan ia tidak tersedia pada Amazon Bedrock, Claude Platform di AWS, Agent Platform Google Cloud, atau Microsoft Foundry. Apabila sesuatu sesi memenuhi keperluan tersebut, pemesejan sudah pun diaktifkan dan tiada apa-apa yang perlu ditetapkan. Perlakuan yang diterangkan di bawah adalah berdasarkan dokumentasi Anthropic untuk pemesejan rentas sesi.

VPS ialah tempat perkara ini menjadi penting, kerana VPS adalah tempat sesi bertahan cukup lama sehingga berbaloi untuk dihubungi. Pada komputer riba, anda akan menutup penutupnya. Pada pelayan di bawah tmux, sesi yang anda mulakan pada hari Isnin masih berjalan pada hari Khamis, masih memegang konteks satu repositori. Sebaik sahaja anda mempunyai dua sesi sedemikian, cara ia berkomunikasi bukan lagi sekadar teori. Jika anda belum menetapkannya lagi, mulakan dengan menjalankan Claude Code pada VPS di bawah tmux, yang merangkumi penyediaan sesi yang diandaikan oleh panduan ini.

Apabila sesi kedua berbaloi dengan tokennya

Mulakan dengan kos. Setiap sesi ialah instans Claude yang berasingan dengan tetingkap konteksnya sendiri, jadi dua sesi menelan kos kira-kira dua kali ganda berbanding satu sesi dalam tempoh yang sama. Mesej yang dihantar dikira terhadap penggunaan sama seperti prompt yang anda taip. Penyelarasan tidak percuma, dan kerja yang sebenarnya merupakan satu urutan langkah menjadi lebih perlahan serta lebih mahal apabila anda memecahkannya merentasi sesi.

Kes di mana sesi kedua berbaloi dengan kosnya mempunyai ciri yang sama. Dua tugasan berjalan pada masa yang sama tanpa menunggu antara satu sama lain, dan salah satu daripadanya mempelajari sesuatu yang diperlukan oleh yang satu lagi di pertengahan tugas.

• Satu sesi menemui perubahan yang merosakkan (breaking change) sementara sesi yang lain sedang membina kod yang dirosakkannya. Claude meringkaskan perubahan tersebut dan menghantarnya, berbanding anda menaip semula dalam terminal yang satu lagi.
• Dua sesi bekerja pada repositori yang sama dalam git worktrees yang berasingan, dan salah satu daripadanya perlu mengetahui apa yang telah dimasukkan.
• Satu migrasi panjang atau ujian yang dijalankan melaporkan hasilnya kembali ke sesi yang sedang anda pantau.
• Sesi pembina dan sesi penyemak, di mana penyemak membaca apa yang dihasilkan oleh pembina dan menghantar kembali apa yang ditemuinya.

Apabila kerja bersifat berjujukan, atau apabila kedua-dua sesi akan menyunting fail yang sama, gunakan satu sesi. Apabila anda mahukan kumpulan yang diselaraskan yang dijana dan diselia oleh Claude dalam satu tugasan, itu adalah pasukan ejen (agent teams), satu ciri berasingan yang masih dalam peringkat eksperimen. Apabila anda hanya mahukan perbualan yang sama dalam terminal lain, sambung semula sesi tersebut. Pemesejan rentas sesi adalah untuk sesi bebas yang anda mulakan dan kendalikan sendiri.

Pastikan ciri tersebut tersedia sebelum merancang penggunaannya

Pertama, semak versi:

claude --version

Bandingkan nombor tersebut dengan 2.1.224. Kemudian, di dalam sesi, taip /list-agents, yang juga bertindak balas kepada /peers. Ia mencetak setiap ejen yang boleh dicapai oleh sesi ini, berserta nama yang digunakan oleh setiap ejen tersebut. Jika arahan itu tidak dikenali langsung, sesi ini tidak mempunyai pemesejan rentas sesi (cross-session messaging), dan tiada fail tetapan yang akan mengubahnya. Taip /status dan cari baris Peer address: ia mengandungi alamat peti masuk sesi ini sendiri, dengan awalan uds:.

Satu perangkap sering menjejaskan pengguna VPS. Pemesejan rentas sesi bergantung pada penilaian feature-flag, dan beberapa pemboleh ubah privasi mematikan penilaian tersebut, yang menyebabkan ciri itu kekal dalam keadaan lalai (off). DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, dan DISABLE_GROWTHBOOK semuanya melakukan perkara ini. Pengguna mengeraskan (harden) pelayan baharu dengan menampal pemboleh ubah tersebut ke dalam ~/.bashrc, kemudian tertanya-tanya mengapa /list-agents tidak wujud. Nilai yang sama boleh datang daripada peta env dalam fail tetapan atau daripada tetapan terurus, jadi periksa shell terlebih dahulu.

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

Nyahset (unset) mana-mana pemboleh ubah yang dipaparkan. Bagi DISABLE_TELEMETRY dan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, sebarang nilai yang tidak kosong akan mengaktifkan kelakuan tersebut, termasuk rentetan 0, jadi DISABLE_TELEMETRY=0 tidak berfungsi seperti yang disangkakan. Anda mematikannya dengan menyahset pemboleh ubah tersebut atau menetapkannya kepada rentetan kosong.

Namakan sesi anda, atau Claude tidak dapat merujuknya

Claude merujuk mesej kepada sesuatu sesi berdasarkan namanya. Tetapkan nama tersebut apabila anda memulakan sesi:

claude --name builder-api

Anda juga boleh menetapkannya dengan /rename semasa sesi sedang berjalan. Jika anda tidak menetapkan apa-apa, Claude Code akan memperoleh nama daripada nama folder direktori kerja, contohnya myapp-3f. Ini memadai untuk satu sesi tetapi mengelirukan untuk empat sesi, dan dua sesi boleh berakhir dengan nama yang sama. Output /list-agents menunjukkan direktori kerja bagi setiap sesi tempatan, yang membantu membezakan sesi yang mempunyai nama sama, dan senarai Claude sendiri akan menambah pengecam ringkas pada alamat apabila nama bertindih. Menamakan sesi sendiri adalah lebih mudah daripada membaca pengecam.

Susun atur tmux dua sesi yang boleh anda hasilkan semula

Ini merupakan sesi pembina dan sesi penyemak pada satu repositori. Penyemak bekerja dalam git worktree yang berasingan, jadi kedua-duanya tidak akan menulis pada fail yang sama. git worktree add dengan HEAD memberikan daftar keluar (checkout) terasing, iaitu perkara yang anda perlukan untuk sesi yang membaca dan bukannya melakukan komit.

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 kemudian w menyenaraikan tetingkap mengikut nama supaya anda boleh memilih satu. Dalam tetingkap pembina, jalankan /list-agents. Anda sepatutnya melihat reviewer-api dengan direktori kerjanya ~/src/api-review. Jika ia tiada, sesi penyemak belum selesai dimulakan, atau salah satu daripada dua masalah dalam bahagian seterusnya berlaku. Kemudian serahkan sesuatu dalam bahasa yang mudah:

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

Claude menulis ringkasan dan menghantarnya. Anda tidak menulis teks mesej tersebut, dan kandungan yang dihantar oleh Claude adalah berbeza-beza. Dalam tetingkap penyemak, mesej itu muncul dalam perbualan dengan nama penghantar. Jika sesi itu melahu, Claude memulakan giliran baharu serta-merta. Jika ia berada di pertengahan giliran, mesej itu menunggu sehingga antara panggilan alat, jadi arahan yang sedang berjalan tidak akan terganggu. Sebaik sahaja Claude membacanya, mesej itu mengecil kepada baris Message from satu baris yang dikembangkan oleh Ctrl+O. Pasangan ini berfungsi dengan lebih baik apabila pembina memastikan perubahannya kecil, kerana diff yang sempit menghasilkan penyerahan yang lebih pendek dan semakan yang boleh diselesaikan oleh sesi lain dalam satu giliran, iaitu tabiat yang wujud untuk dikuatkuasakan oleh kemahiran pembangun senior yang malas.

Siapa boleh melihat siapa pada satu VPS

Penghantaran pada mesin yang sama tidak pernah melalui pelayan Anthropic. Setiap sesi menulis fail pendaftaran ke cakera dan mengikat soket peti masuknya sendiri, dan Claude Code membaca fail tersebut untuk mencari sesi anda yang lain. Dua akibat akan berlaku, dan kedua-duanya memberi kesan pada pelayan.

Soket dihadkan kepada pengguna sistem pengendalian anda. Sesi yang anda mulakan sebagai root dan sesi yang anda mulakan sebagai deploy tidak boleh melihat satu sama lain, walaupun bersebelahan dalam pelayan tmux yang sama, kerana sesi satu pengguna tidak boleh mencapai soket pengguna lain. Jalankan kedua-dua sesi sebagai pengguna yang sama.

Bekas (container) mempunyai sistem failnya sendiri. Sesi di dalam Docker dan sesi pada hos tidak boleh mencapai satu sama lain, kerana ia tidak membaca fail pendaftaran yang sama. Dua sesi di dalam bekas yang sama boleh menghantar mesej antara satu sama lain secara normal. Jika anda menyimpan ejen dalam bekas untuk pengasingan, seperti dalam menjalankan ejen pengekodan dalam VM pakai buang, jangkakan pemesejan berfungsi di dalam bekas dan bukan merentasi sempadan bekas.

Sesi anda pada mesin lain, dan di web, hanya muncul dalam senarai semasa Remote Control disambungkan, dan ia dilabelkan sedemikian. Claude di sini hanya boleh membalas mesej yang tiba daripada salah satu sesi tersebut. Ia tidak boleh memulakan pertukaran mesej itu.

Mengapa mesej anda tidak pernah sampai

Sebab yang biasa berlaku tiada kaitan dengan rangkaian. Sesi penerima menentukan tindakan terhadap mesej tersebut, dan keputusannya adalah untuk tidak menghantarnya. Setiap mesej yang tiba berakhir dengan salah satu daripada tiga hasil: dihantar, ditahan (disisihkan tanpa dihantar sehingga anda meluluskannya), atau ditolak (digugurkan tanpa penghantaran).

Apabila tiada nilai crossSessionInbound yang terpakai, Claude Code membuat keputusan bagi setiap mesej dengan membandingkan mod kebenaran kedua-dua sesi. Ia mengumpulkan sesi yang memintas gesaan kebenaran ke dalam satu kelas dan setiap sesi lain ke dalam kelas yang satu lagi. auto, acceptEdits, dan dontAsk dikira sebagai gesaan. Mod pelan dikira sebagai pemintasan dalam sesi yang mempunyai kebenaran pintasan tersedia. Peraturannya adalah simetri:

• Sesi penerima yang meminta kebenaran akan menerima setiap mesej yang dihantar. Ia hanya menahan mesej apabila sesi penghantar mengenal pasti dirinya sebagai pemintas gesaan.
• Sesi penerima yang memintas gesaan akan menahan setiap mesej untuk kelulusan anda. Ia hanya menghantar mesej apabila penghantar juga melakukan pemintasan.

Oleh itu, aliran kerja pertama yang dibina oleh kebanyakan orang adalah aliran kerja yang tidak berfungsi. Anda memulakan pembina dengan --permission-mode bypassPermissions kerana anda mahu ia berjalan tanpa pengawasan, anda membiarkan penyemak pada tetapan lalai, dan setiap mesej yang dihantar oleh pembina menunggu dalam dialog kelulusan yang tidak dipantau oleh sesiapa. Dialog itu ditutup selepas tarikh akhir dialogExpiry, yang secara lalai ditetapkan kepada 5m, dan mesej tersebut digugurkan. Pada mesin yang sama, sesi penghantar mendapat notis apabila mesejnya ditahan, dan susulan apabila penerima kemudiannya menghantar, menolak, atau membiarkannya tamat tempoh, jadi baca skrin penghantar sebelum anda menyalahkan soket.

Untuk membolehkan sesi menerima mesej tanpa pengawasan, tetapkan crossSessionInbound kepada accept. Tempat anda menetapkannya menentukan sama ada ia terpakai. Claude Code membaca tetapan terurus terlebih dahulu, kemudian bendera --settings, diikuti tetapan pengguna, dan menggunakan nilai pertama yang ditemuinya. Nilai dalam tetapan projek atau tempatan hanya terpakai apabila ia lebih ketat, pada tangga accept < hold < refuse. accept dalam .claude/settings.json adalah lebih longgar daripada segala-galanya, jadi ia diabaikan apabila sumber yang dipercayai telah menetapkan nilai. Letakkannya dalam ~/.claude/settings.json, atau hantarkannya untuk satu sesi:

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

Pekerja claude -p tanpa kepala mengikat soket peti masuk seperti sesi interaktif dan muncul dalam senarai, tetapi ia tidak dapat memaparkan dialog kelulusan. Mesej yang ditahan di sana kekal ditahan sehingga mod atau perubahan tetapan kemudian membenarkannya. Baris --settings di atas adalah cara anda membenarkan pekerja sedemikian menerima mesej. Sesi yang dimulakan dalam mod bare tidak mengikat sebarang soket, jadi ia tidak boleh menerima mesej mahupun muncul dalam senarai.

Di mana serahan tugas mengalami kebuntuan

Gelung mesej dikendalikan untuk anda. Claude Code mengehadkan kadar mesej berulang bagi setiap penghantar, menggugurkan ulangan serupa yang tiba dalam tempoh singkat, dan mengehadkan mesej diterima yang menunggu untuk dibaca kepada 50 bagi setiap sesi, supaya dua sesi tidak boleh berbalas mesej selama-lamanya. Mesej yang ditahan dihadkan kepada 100, dan mesej paling lama akan digugurkan selepas had tersebut.

Kegagalan yang berlaku adalah lebih senyap, dan ia merupakan serahan tugas (hand-off) dan bukannya gelung. Sesi A bertanya kepada sesi B soalan yang memerlukan jawapan sebelum ia boleh meneruskan tugas, kemudian sesi A menjadi melahu. B menahan mesej tersebut, atau B sedang sibuk dengan tugasan yang panjang, atau B menjawab soalan yang tidak benar-benar ditanya oleh A. A menunggu. Anda kembali sejam kemudian mendapati dua sesi melahu dan tiada kerja yang disiapkan.

Tulis serahan tugas yang tidak memerlukan balasan. Mesej yang baik membawa fakta atau keputusan: apa yang berubah, dan apakah hasilnya. Mesej yang buruk meminta kebenaran daripada sesi lain, atau meminta jawapan yang menyebabkan penghantar terhenti. Claude sudah diarahkan untuk tidak meminta tindakan daripada sesi lain yang akan disekat oleh tetapan kebenarannya sendiri, dan untuk menghalakan semula kerja tersebut kepada anda. Lanjutkan peraturan itu sendiri. Jika sesuatu sesi tidak boleh membuat kemajuan tanpa jawapan, anda adalah orang yang sepatutnya menjawabnya. Disiplin konteks juga membantu di sini, kerana sesi yang telah hilang punca akan menulis mesej yang samar; mengurus konteks dalam Claude Code merangkumi aspek tersebut.

Anggap mesej masuk sebagai input yang tidak dipercayai

Claude Code memberitahu Claude penerima bahawa mesej tersebut datang daripada sesi lain dan bukan daripada anda, serta mengehadkan perkara yang boleh dilakukan oleh mesej itu. Mesej tidak boleh menjawab gesaan kebenaran yang belum selesai bagi pihak anda, kerana persetujuan daripada sesi lain bukanlah persetujuan anda. Ia tidak boleh menukar tetapan kebenaran, CLAUDE.md, atau konfigurasi lain hanya kerana sesi lain memintanya. Perintah slash di dalam teks, seperti /compact, akan sampai sebagai teks biasa dan tidak akan dilaksanakan. Jika tindakan berdasarkan mesej tersebut memerlukan kebenaran yang tidak dimiliki oleh sesi penerima, anda akan melihat gesaan yang sama seperti yang anda lihat untuk tugasan lain. Dalam mod auto, pengelas juga menyemak setiap mesej sebelum penghantaran, dan mesej yang disekat olehnya tidak akan sampai kepada penerima. Had ini kekal walaupun dalam mod permisif, itulah sebabnya sesi yang memintas akan menahan mesej masuk secara lalai dan bukannya mempercayainya.

Itu merangkumi aspek kebenaran. Ia tidak merangkumi kandungan. Sesi penghantar mungkin telah membaca perihalan pull request, halaman web, README dependensi, atau komen isu yang ditulis oleh orang asing, dan apa sahaja yang dibacanya boleh membentuk teks yang ditulisnya kepada sesi anda yang lain. Mesej tersebut adalah data. Ia wajar menerima syak wasangka yang sama seperti mana-mana teks lain yang memasuki sesi dari luar. Ini adalah disiplin yang diterangkan dalam menjaga rahsia daripada ejen AI anda: anggap apa sahaja yang melintasi sempadan kepercayaan boleh menjadi salah, dan jangan sekali-kali membenarkannya memberi kuasa kepada dirinya sendiri.

Dua kawalan wujud jika anda mahukan perkara ini dikurangkan. Menetapkan crossSessionInbound kepada refuse akan menggugurkan mesej rakan setara masuk tanpa menghantarnya, dan daripada tetapan projek atau tempatan, nilai tersebut terpakai mengatasi setiap sumber lain, kerana ia adalah yang paling ketat dalam hierarki. Untuk menghentikan sesi ini daripada menghantar atau menyenaraikan, tambahkan peraturan penafian kebenaran yang menamakan SendMessage dan ListAgents, kedua-duanya ditulis sebagai nama alat kosong tanpa penentu. Menetapkan isolatePeerMachines kepada true memerlukan kelulusan eksplisit anda sebelum sebarang mesej sampai ke sesi di luar mesin ini, dan kelulusan itu diperlukan walaupun dalam mod bypassPermissions.

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

Menafikan SendMessage juga membuang pemesejan kepada subejen, memandangkan alat yang sama digunakan untuk kedua-duanya. Sesi yang menolak tidak menunjukkan perubahan yang ketara dalam /status miliknya sendiri atau dalam penyenaraian sesi lain, jadi sahkan tetapan tersebut daripada konfigurasi sesi dan bukannya daripada skrin.

Bridge dan pelayan MCP memori kongsi

Beberapa projek pihak ketiga muncul dalam tempoh yang sama dengan fungsi yang hampir serupa: bridge ejen-ke-ejen setempat yang menyampaikan teks antara ejen yang sedang berjalan, dan pelayan MCP (model context protocol) yang memberikan beberapa ejen satu storan kongsi untuk membaca dan menulis. Nilai projek ini sebagai bentuk yang berbeza dan bukannya sebagai pesaing, dan sahkan sebarang arahan pemasangan dengan README projek tersebut sebelum anda menjalankannya. Pemesejan adalah jenis tolak (push), kerana penghantar meletakkan teks ke dalam giliran penerima. Storan kongsi adalah jenis tarik (pull), kerana tiada sesi yang diganggu dan sesi akan melihat nota tersebut apabila ia menyemaknya nanti. Tarik adalah lebih tenang untuk status yang berubah secara perlahan, dan ia hanya berfungsi apabila sesi benar-benar melihatnya.

Jika anda memilih cara tersebut, soalan yang perlu ditanya adalah mengenai proses dan bukannya senarai ciri. Apakah pengguna yang menjalankan pelayan tersebut, dan apakah yang boleh dibacanya pada mesin itu. Menjalankan pelayan MCP pada VPS merangkumi persediaan tersebut. Berkongsi kemahiran ejen merentas repo merangkumi kes yang lebih mudah di mana perkara yang ingin dikongsi antara sesi adalah arahan dan bukannya status langsung, dan ia mengurangkan banyak mesej yang sepatutnya anda hantar. Untuk gambaran yang lebih luas, menjalankan ejen pengekodan pada VPS adalah tempat untuk bermula.

FAQ

Mengapa /list-agents tidak dikenali dalam sesi saya?

Sesi tersebut tidak mempunyai pemesejan rentas sesi. Semak claude --version berbanding 2.1.224 terlebih dahulu, kerana ciri ini memerlukan versi tersebut atau yang lebih baharu. Kemudian, semak platform, kerana ia hanya berjalan pada macOS dan Linux dan bukan pada Windows asli, serta tidak tersedia pada Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, dan Microsoft Foundry. Jika kedua-duanya betul, semak shell anda untuk DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, atau DISABLE_GROWTHBOOK, kerana setiap satunya menyekat penilaian feature-flag yang diperlukan oleh ciri tersebut dan menyebabkannya dinyahaktifkan.

Mengapa mesej saya kepada sesi lain tidak pernah sampai?

Jika /list-agents berfungsi, pemesejan diaktifkan dan sesuatu yang lebih khusus telah menyekat mesej tersebut. Punca biasa ialah mod kebenaran. Sesi yang memintas gesaan kebenaran akan menahan setiap mesej masuk untuk kelulusan anda melainkan penghantar juga memintasnya, dan dialog kelulusan tersebut digugurkan selepas tamat tempoh dialogExpiry, iaitu lima minit secara lalai. Semak sesi penghantar untuk notis tahanan. Untuk membaikinya, tetapkan crossSessionInbound kepada accept dalam ~/.claude/settings.json atau hantarkannya dengan --settings, kerana accept dalam tetapan projek atau tempatan diabaikan sebagai nilai yang lebih longgar.

Bolehkah sesi Claude Code dalam Docker menghantar mesej kepada sesi pada hos?

Tidak. Sesi mencari antara satu sama lain melalui fail pendaftaran pada cakera dan soket peti masuk bagi setiap sesi, dan bekas (container) mempunyai sistem failnya sendiri, jadi kedua-duanya tidak dapat melihat fail yang sama. Dua sesi di dalam bekas yang sama boleh menghantar mesej antara satu sama lain seperti biasa. Peraturan yang sama menjelaskan mengapa sesi yang berjalan sebagai root dan sesi yang berjalan sebagai pengguna biasa anda tidak dapat mencapai satu sama lain: soket tersebut dihadkan kepada pengguna sistem pengendalian yang memilikinya.

Adakah mesej daripada sesi Claude Code lain selamat untuk diambil tindakan?

Anggap teks tersebut sebagai input yang tidak dipercayai, kerana sesi penghantar mungkin telah membaca halaman web, README, atau komen isu yang ditulis oleh orang lain. Claude Code sudah menghalang mesej tersebut daripada bertindak sendiri: ia tidak boleh meluluskan gesaan kebenaran yang belum selesai, ia tidak boleh menukar tetapan kebenaran atau CLAUDE.md atas permintaan, dan arahan slash dalam teks akan sampai sebagai teks biasa dan tidak akan dijalankan. Perlindungan tersebut meliputi kebenaran dan bukan pertimbangan, jadi baca apa yang sampai sebelum anda mengarahkan sesi penerima untuk bertindak ke atasnya.

Adakah pemesejan rentas sesi menghantar kod saya kepada Anthropic?

Antara dua sesi pada mesin yang sama, tidak. Mesej tersebut bergerak melalui soket bagi setiap sesi pada mesin itu dan tidak pernah melalui pelayan Anthropic, dan hanya teks yang ditulis oleh Claude dihantar, bukan sejarah perbualan atau fail. Mesej kepada sesi pada mesin anda yang lain, atau kepada sesi di web, memang melalui pelayan Anthropic melalui sambungan Remote Control, dan dalam arah tersebut Claude hanya boleh membalas mesej yang sampai, bukan memulakannya. Tetapkan isolatePeerMachines kepada true untuk memerlukan kelulusan anda sebelum sebarang data meninggalkan mesin.