Cara Sesi Claude Code Saling Mengirim Pesan

Apa artinya sesi Claude Code saling mengirim pesan

Dua sesi Claude Code dapat saling mengirim pesan saat keduanya berjalan pada mesin yang sama, di bawah pengguna sistem operasi yang sama. Sebuah pesan adalah satu bagian teks biasa yang ditulis oleh satu Claude untuk Claude lainnya. Pesan tersebut tidak membawa riwayat percakapan maupun file. Claude menemukan sesi lainnya dengan alat ListAgents dan mengirimkan teks tersebut dengan SendMessage, sehingga Anda tidak perlu memanggil kedua alat tersebut secara manual. Anda cukup menyampaikan apa yang perlu diketahui oleh sesi lainnya, dan Claude akan menulis pesannya sendiri.

Fitur ini disebut pengiriman pesan lintas sesi (cross-session messaging). Per Agustus 2026, fitur ini memerlukan Claude Code v2.1.224 atau yang lebih baru, dan berjalan pada macOS serta Linux, termasuk Linux di dalam WSL 2. Tidak ada dukungan Windows asli, dan fitur ini tidak tersedia di Amazon Bedrock, Claude Platform di AWS, Google Cloud's Agent Platform, atau Microsoft Foundry. Ketika sebuah sesi memenuhi persyaratan tersebut, pengiriman pesan sudah aktif dan tidak ada yang perlu diaktifkan. Perilaku yang dijelaskan di bawah ini berasal dari dokumentasi Anthropic untuk pengiriman pesan lintas sesi.

VPS adalah tempat di mana hal ini menjadi penting, karena di VPS sesi bertahan cukup lama sehingga layak untuk dihubungkan. Di laptop, Anda akan menutup layar. Di server yang menggunakan tmux, sesi yang Anda mulai pada hari Senin masih berjalan pada hari Kamis, tetap menyimpan konteks satu repositori. Setelah Anda memiliki dua sesi tersebut, bagaimana keduanya berkomunikasi bukan lagi sekadar teori. Jika Anda belum mengaturnya, mulailah dengan menjalankan Claude Code di VPS menggunakan tmux, yang mencakup pengaturan sesi yang menjadi asumsi panduan ini.

Kapan sesi kedua sepadan dengan tokennya

Mulailah dengan biayanya. Setiap sesi adalah instance Claude terpisah dengan jendela konteksnya sendiri, sehingga dua sesi memakan biaya kira-kira dua kali lipat dari satu sesi dalam periode yang sama. Pesan yang dikirim dihitung terhadap penggunaan persis seperti prompt yang Anda ketik. Koordinasi tidaklah gratis, dan pekerjaan yang sebenarnya merupakan satu rangkaian langkah akan menjadi lebih lambat dan lebih mahal jika Anda membaginya ke dalam beberapa sesi.

Kasus di mana sesi kedua sepadan dengan biayanya memiliki satu pola yang sama. Dua bagian pekerjaan berjalan pada waktu yang bersamaan tanpa saling menunggu, dan salah satunya mempelajari sesuatu yang dibutuhkan oleh yang lain di tengah tugas.

• Satu sesi menemukan perubahan yang merusak (breaking change) sementara sesi lainnya sedang membangun kode yang dirusaknya. Claude meringkas perubahan tersebut dan mengirimkannya, alih-alih Anda mengetik ulang di terminal lainnya.
• Dua sesi mengerjakan repositori yang sama di git worktrees yang terpisah, dan salah satunya perlu mengetahui apa yang telah diterapkan.
• Migrasi panjang atau pengujian melaporkan hasilnya kembali ke sesi yang sedang Anda pantau.
• Sesi pembangun dan sesi peninjau, di mana peninjau membaca apa yang dihasilkan oleh pembangun dan mengirimkan kembali apa yang ditemukannya.

Jika pekerjaan bersifat sekuensial, atau jika kedua sesi akan mengedit file yang sama, gunakan satu sesi. Jika Anda menginginkan grup terkoordinasi yang dibuat dan diawasi oleh Claude dalam satu tugas, itu adalah tim agen, fitur terpisah yang masih bersifat eksperimental. Jika Anda hanya menginginkan percakapan yang sama di terminal lain, lanjutkan sesi tersebut sebagai gantinya. Pesan lintas sesi ditujukan untuk sesi independen yang Anda mulai dan arahkan sendiri.

Pastikan fitur tersedia sebelum Anda merencanakannya

Pertama, periksa versinya:

claude --version

Bandingkan angka tersebut dengan 2.1.224. Kemudian, di dalam sesi, ketik /list-agents, yang juga merespons /peers. Perintah ini mencetak setiap agen yang dapat dijangkau oleh sesi ini, beserta nama yang digunakan masing-masing agen. Jika perintah tersebut tidak dikenali sama sekali, sesi ini tidak memiliki fitur pesan lintas sesi, dan tidak ada file pengaturan yang dapat mengubahnya. Ketik /status dan cari baris Peer address: baris tersebut berisi alamat kotak masuk sesi ini, diawali dengan uds:.

Satu kendala sering dialami oleh pengguna VPS. Pesan lintas sesi bergantung pada evaluasi feature-flag, dan beberapa variabel privasi mematikan evaluasi tersebut, yang membuat fitur tetap dalam status nonaktif bawaan. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, dan DISABLE_GROWTHBOOK semuanya menyebabkan hal ini. Pengguna sering memperketat keamanan server baru dengan menempelkan variabel tersebut ke dalam ~/.bashrc, lalu bingung mengapa /list-agents tidak ada. Nilai yang sama dapat berasal dari peta env dalam file pengaturan atau dari pengaturan terkelola, jadi periksa shell terlebih dahulu.

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

Hapus variabel mana pun yang muncul saat dicetak. Untuk DISABLE_TELEMETRY dan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, nilai apa pun yang tidak kosong akan mengaktifkan perilaku tersebut, termasuk string 0, sehingga DISABLE_TELEMETRY=0 tidak berfungsi seperti yang terlihat. Anda menonaktifkannya dengan menghapus variabel tersebut atau mengaturnya ke string kosong.

Beri nama sesi Anda, atau Claude tidak dapat mengalamatkannya

Claude mengalamatkan pesan ke sesi berdasarkan namanya. Tetapkan nama saat Anda memulai sesi:

claude --name builder-api

Anda juga dapat menetapkannya dengan /rename di dalam sesi yang sedang berjalan. Jika Anda tidak menetapkan apa pun, Claude Code akan mengambil nama dari nama folder direktori kerja, seperti myapp-3f. Hal ini mungkin tidak masalah untuk satu sesi, namun akan membingungkan untuk empat sesi, dan dua sesi bisa berakhir dengan nama yang sama. Output /list-agents menampilkan direktori kerja setiap sesi lokal, yang membedakan sesi dengan nama yang sama, dan daftar milik Claude sendiri menambahkan pengenal singkat ke alamat saat terjadi tabrakan nama. Memberi nama sendiri lebih efisien daripada membaca pengenal.

Tata letak tmux dua sesi yang dapat Anda reproduksi

Ini adalah sesi pembangun (builder) dan sesi peninjau (reviewer) pada satu repositori. Peninjau bekerja di git worktree terpisah, sehingga keduanya tidak pernah menulis ke file yang sama. git worktree add dengan HEAD menghasilkan checkout terpisah (detached), yang merupakan hal yang Anda inginkan untuk sesi yang bersifat membaca alih-alih melakukan commit. Karena kedua sesi melakukan tugas yang berbeda, ada baiknya memberikan peninjau gaya output tersendiri, yang mengubah prompt sistem sesi tersebut sehingga tetap konsisten di setiap giliran alih-alih memudar seperti instruksi yang Anda ketik sekali saja.

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 mencantumkan jendela berdasarkan nama agar Anda dapat memilih salah satu. Di jendela pembangun, jalankan /list-agents. Anda seharusnya melihat reviewer-api dengan direktori kerja ~/src/api-review. Jika tidak ada, sesi peninjau belum selesai dimulai, atau salah satu dari dua masalah di bagian berikutnya terjadi. Kemudian serahkan sesuatu dengan bahasa yang lugas:

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

Claude menulis ringkasan dan mengirimkannya. Anda tidak menulis teks pesan tersebut, dan apa yang dikirim Claude bervariasi. Di jendela peninjau, pesan muncul dalam percakapan dengan nama pengirim. Jika sesi tersebut sedang tidak aktif, Claude segera memulai giliran baru di sesi itu. Jika sedang di tengah giliran, pesan akan menunggu hingga di antara pemanggilan alat (tool calls), sehingga perintah yang sedang berjalan tidak akan terputus. Setelah Claude membacanya, pesan tersebut menciut menjadi baris Message from satu baris yang dapat diperluas oleh Ctrl+O. Pasangan ini bekerja lebih baik ketika pembangun menjaga perubahannya tetap kecil, karena diff yang sempit membuat serah terima yang lebih singkat dan tinjauan yang dapat diselesaikan sesi lain dalam satu giliran, yang merupakan kebiasaan yang ditegakkan oleh keterampilan pengembang senior yang malas.

Siapa yang dapat melihat siapa pada satu VPS

Pengiriman pada mesin yang sama tidak pernah melalui server Anthropic. Setiap sesi menulis file registrasi ke disk dan mengikat socket kotak masuknya sendiri, lalu Claude Code membaca file tersebut untuk menemukan sesi Anda yang lain. Dua konsekuensi muncul, dan keduanya berdampak pada server.

Socket dibatasi untuk pengguna sistem operasi Anda. Sesi yang Anda mulai sebagai root dan sesi yang Anda mulai sebagai deploy tidak dapat saling melihat, bahkan jika berdampingan di server tmux yang sama, karena sesi satu pengguna tidak dapat menjangkau socket pengguna lain. Jalankan kedua sesi sebagai pengguna yang sama.

Container memiliki sistem filenya sendiri. Sesi di dalam Docker dan sesi pada host tidak dapat saling menjangkau, karena keduanya tidak membaca file registrasi yang sama. Dua sesi di dalam container yang sama dapat saling mengirim pesan secara normal. Jika Anda menyimpan agen di dalam container untuk isolasi, seperti pada menjalankan agen coding di VM sekali pakai, jangan mengharapkan pengiriman pesan berfungsi melintasi batas container.

Sesi Anda di mesin lain, dan di web, hanya muncul dalam daftar saat Remote Control terhubung, dan sesi tersebut diberi label demikian. Claude di sini hanya dapat membalas pesan yang datang dari salah satu sesi tersebut. Claude tidak dapat memulai pertukaran pesan itu.

Mengapa pesan Anda tidak pernah sampai

Alasan yang paling umum tidak ada hubungannya dengan jaringan. Sesi penerima memutuskan apa yang harus dilakukan dengan pesan tersebut, dan keputusannya adalah tidak mengirimkannya. Setiap pesan yang masuk berakhir dengan satu dari tiga hasil: dikirim, ditahan (disisihkan tanpa dikirim sampai Anda menyetujuinya), atau ditolak (dibuang tanpa dikirim).

Ketika tidak ada nilai crossSessionInbound yang berlaku, Claude Code memutuskan per pesan dengan membandingkan mode izin kedua sesi. Ia mengelompokkan sesi yang melewati prompt izin ke dalam satu kelas dan sesi lainnya ke kelas yang berbeda. auto, acceptEdits, dan dontAsk dihitung sebagai sesi yang meminta prompt. Mode plan dihitung sebagai bypass dalam sesi yang memiliki izin bypass tersedia. Jika Anda tidak yakin sesi mana yang termasuk dalam kelas tertentu, apa yang sebenarnya dilakukan setiap mode izin layak dibaca terlebih dahulu, karena auto adalah tempat sebagian besar sesi dimulai saat ini dan mode tersebut berada di sisi yang meminta prompt dari pembagian tersebut. Aturannya kemudian simetris:

• Sesi penerima yang meminta prompt untuk izin akan menerima setiap pesan yang dikirim. Ia hanya menahan pesan jika sesi pengirim mengidentifikasi dirinya sebagai sesi yang melewati prompt.
• Sesi penerima yang melewati prompt akan menahan setiap pesan untuk persetujuan Anda. Ia hanya mengirimkan pesan jika pengirimnya juga melewati prompt.

Jadi, alur kerja pertama yang dibangun kebanyakan orang justru adalah alur kerja yang tidak berfungsi. Anda memulai builder dengan --permission-mode bypassPermissions karena Anda ingin menjalankannya tanpa pengawasan, Anda membiarkan reviewer pada pengaturan default, dan setiap pesan yang dikirim builder menunggu di dialog persetujuan yang tidak dilihat siapa pun. Dialog tersebut tertutup setelah tenggat waktu dialogExpiry, yang secara default adalah 5m, dan pesan tersebut dibuang. Pada mesin yang sama, sesi pengirim mendapatkan pemberitahuan saat pesannya ditahan, dan pemberitahuan tindak lanjut saat penerima nantinya mengirimkan, menolak, atau membiarkan pesan tersebut kedaluwarsa, jadi bacalah layar pengirim sebelum Anda menyalahkan socket.

Agar sesi menerima pesan tanpa pengawasan, atur crossSessionInbound ke accept. Tempat Anda mengaturnya menentukan apakah pengaturan tersebut berlaku. Claude Code membaca pengaturan terkelola terlebih dahulu, kemudian flag --settings, lalu pengaturan pengguna, dan menerapkan nilai pertama yang ditemukannya. Nilai dalam pengaturan proyek atau lokal hanya berlaku jika lebih ketat, pada tangga accept < hold < refuse. Nilai accept di .claude/settings.json lebih longgar daripada apa pun, sehingga diabaikan setiap kali sumber tepercaya telah menetapkan nilai. Letakkan di ~/.claude/settings.json, atau teruskan untuk satu sesi:

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

Worker claude -p tanpa kepala (headless) mengikat socket kotak masuk seperti sesi interaktif dan muncul dalam daftar, tetapi tidak dapat menampilkan dialog persetujuan. Pesan yang ditahan di sana akan tetap ditahan sampai mode atau perubahan pengaturan di kemudian hari mengizinkannya. Baris --settings di atas adalah cara Anda membiarkan worker tersebut menerima pesan. Sesi yang dimulai dalam mode bare tidak mengikat socket sama sekali, sehingga tidak dapat menerima pesan maupun muncul dalam daftar.

Tempat terjadinya deadlock pada hand-off

Loop pesan ditangani secara otomatis untuk Anda. Claude Code membatasi laju pesan berulang per pengirim, membuang pesan identik yang tiba dalam jendela waktu singkat, dan membatasi pesan yang menunggu untuk dibaca sebanyak 50 per sesi, sehingga dua sesi tidak dapat saling membalas selamanya. Pesan yang ditahan dibatasi hingga 100, dan pesan terlama akan dibuang jika melebihi jumlah tersebut.

Kegagalan yang sebenarnya terjadi lebih senyap, dan ini merupakan bentuk hand-off, bukan loop. Sesi A menanyakan pertanyaan kepada sesi B yang jawabannya diperlukan sebelum A dapat melanjutkan, lalu A menjadi idle. B menahan pesan tersebut, atau B sedang mengerjakan tugas yang panjang, atau B menjawab pertanyaan yang sebenarnya tidak ditanyakan oleh A. A menunggu. Anda kembali satu jam kemudian dan mendapati dua sesi dalam keadaan idle tanpa ada pekerjaan yang selesai.

Tuliskan hand-off yang tidak memerlukan balasan. Pesan yang baik memuat fakta atau keputusan: apa yang berubah, dan apa hasilnya. Pesan yang buruk meminta izin kepada sesi lain, atau meminta jawaban yang membuat pengirim terhenti. Claude sudah diinstruksikan untuk tidak pernah meminta tindakan kepada sesi lain jika pengaturan izinnya sendiri melarang hal tersebut, dan untuk mengalihkan pekerjaan itu kembali kepada Anda. Terapkan aturan tersebut secara mandiri. Jika sebuah sesi tidak dapat melanjutkan pekerjaan tanpa jawaban, Andalah yang harus menjawabnya. Disiplin konteks juga membantu di sini, karena sesi yang kehilangan alur akan menulis pesan yang samar; mengelola konteks di Claude Code membahas sisi tersebut.

Perlakukan pesan masuk sebagai input yang tidak tepercaya

Claude Code memberi tahu Claude penerima bahwa pesan tersebut berasal dari sesi lain dan bukan dari Anda, serta membatasi apa yang dapat dilakukan pesan tersebut. Penegakan tersebut berada pada program yang membungkus model, bukan pada kesediaan model untuk mematuhi, yang merupakan perbedaan praktis yang diberikan oleh an agent harness. Sebuah pesan tidak dapat menjawab permintaan izin yang tertunda atas nama Anda, karena persetujuan dari sesi lain bukanlah persetujuan Anda. Pesan tersebut tidak dapat mengubah pengaturan izin, CLAUDE.md, atau konfigurasi lainnya karena diminta oleh sesi lain. Perintah garis miring (slash command) di dalam teks, seperti /compact, akan tiba sebagai teks biasa dan tidak akan pernah dieksekusi. Jika tindakan berdasarkan pesan tersebut memerlukan izin yang tidak dimiliki oleh sesi penerima, Anda akan melihat permintaan yang sama seperti yang Anda lihat untuk pekerjaan lainnya. Dalam mode otomatis, sebuah pengklasifikasi juga meninjau setiap pesan sebelum dikirim, dan pesan yang diblokirnya tidak akan pernah sampai ke penerima. Batasan ini tetap berlaku meskipun dalam mode permisif, itulah sebabnya sesi yang melakukan bypass akan menahan pesan masuk secara default alih-alih memercayainya.

Hal tersebut mencakup izin. Namun, hal itu tidak mencakup konten. Sesi pengirim mungkin telah membaca deskripsi pull request, halaman web, README dependensi, atau komentar masalah yang ditulis oleh orang asing, dan apa pun yang dibacanya dapat membentuk teks yang ditulisnya ke sesi Anda yang lain. Pesan tersebut adalah data. Pesan tersebut patut dicurigai sama seperti teks lain yang masuk ke dalam sesi dari luar. Ini adalah disiplin yang dijelaskan dalam keeping secrets out of your AI agents: asumsikan apa pun yang melintasi batas kepercayaan bisa saja salah, dan jangan pernah biarkan hal itu memberikan otorisasi untuk dirinya sendiri.

Terdapat dua kontrol jika Anda ingin mengurangi hal ini. Mengatur crossSessionInbound ke refuse akan membuang pesan rekan masuk tanpa mengirimkannya, dan dari pengaturan proyek atau lokal, nilai tersebut berlaku di atas sumber lainnya karena merupakan yang paling ketat dalam hierarki. Untuk menghentikan sesi ini mengirim atau membuat daftar, tambahkan aturan penolakan izin (deny rules) dengan menyebutkan SendMessage dan ListAgents, keduanya ditulis sebagai nama alat (tool) tanpa penentu. Mengatur isolatePeerMachines ke true memerlukan persetujuan eksplisit Anda sebelum pesan apa pun mencapai sesi di luar mesin ini, dan persetujuan tersebut diperlukan bahkan dalam mode bypassPermissions.

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

Menolak SendMessage juga menghapus pengiriman pesan ke subagen, karena alat yang sama melayani keduanya. Sesi yang menolak tidak menunjukkan perubahan yang terlihat pada /status miliknya sendiri atau pada daftar sesi lain, jadi konfirmasikan pengaturan tersebut dari konfigurasi sesi alih-alih dari layar.

Bridge dan server MCP memori bersama

Beberapa proyek pihak ketiga muncul pada periode yang sama dengan fungsi yang berdekatan: bridge agen-ke-agen lokal yang meneruskan teks antar agen yang sedang berjalan, dan server MCP (model context protocol) yang memberikan satu penyimpanan bersama bagi beberapa agen untuk membaca dan menulis. Nilailah proyek-proyek ini sebagai bentuk yang berbeda, bukan sebagai kompetitor, dan verifikasi setiap perintah instalasi dengan README proyek tersebut sebelum Anda menjalankannya. Pesan bersifat push, karena pengirim menempatkan teks ke dalam giliran penerima. Penyimpanan bersama bersifat pull, karena tidak ada yang diinterupsi dan sesi akan melihat catatan tersebut saat sesi berikutnya memeriksa. Pull lebih tenang untuk status yang berubah secara perlahan, dan hanya berfungsi saat sesi benar-benar melakukan pengecekan.

Jika Anda memilih cara tersebut, pertanyaan yang layak diajukan adalah mengenai prosesnya, bukan daftar fiturnya. Pengguna apa yang menjalankan server tersebut, dan apa saja yang dapat dibaca oleh server di dalam sistem. Menjalankan server MCP di VPS membahas pengaturan tersebut. Berbagi skill agen antar repositori membahas kasus yang lebih sederhana di mana hal yang ingin Anda bagikan antar sesi adalah instruksi, bukan status langsung, dan cara ini menghilangkan banyak pesan yang seharusnya Anda kirim. Untuk gambaran yang lebih luas, menjalankan agen coding di VPS adalah tempat untuk memulai.

FAQ

Mengapa /list-agents tidak dikenali di sesi saya?

Sesi tersebut tidak memiliki fitur perpesanan lintas sesi. Periksa claude --version terhadap 2.1.224 terlebih dahulu, karena fitur ini memerlukan versi tersebut atau yang lebih baru. Kemudian periksa platformnya, karena fitur ini berjalan di macOS dan Linux, bukan di Windows native, dan tidak tersedia di Amazon Bedrock, Claude Platform di AWS, Google Cloud's Agent Platform, serta Microsoft Foundry. Jika keduanya sudah sesuai, periksa shell Anda untuk DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, atau DISABLE_GROWTHBOOK, karena masing-masing variabel tersebut memblokir evaluasi feature-flag yang diandalkan oleh fitur ini dan menyebabkannya tetap nonaktif.

Mengapa pesan saya ke sesi lain tidak pernah sampai?

Jika /list-agents berfungsi, berarti perpesanan aktif dan ada sesuatu yang lebih spesifik yang menghentikan pesan tersebut. Penyebab umumnya adalah mode izin. Sesi yang melewati prompt izin akan menahan setiap pesan masuk untuk persetujuan Anda, kecuali pengirim juga melewati prompt tersebut, dan dialog persetujuan itu akan dibatalkan setelah batas waktu dialogExpiry, yaitu lima menit secara default. Periksa sesi pengirim untuk melihat pemberitahuan pesan yang ditahan. Untuk memperbaikinya, atur crossSessionInbound ke accept di ~/.claude/settings.json atau teruskan dengan --settings, karena accept dalam pengaturan proyek atau lokal akan diabaikan karena nilainya dianggap lebih longgar.

Bisakah sesi Claude Code di Docker mengirim pesan ke sesi di host?

Tidak. Sesi saling menemukan melalui file registrasi di disk dan socket kotak masuk per sesi, dan container memiliki sistem file sendiri, sehingga keduanya tidak dapat melihat file yang sama. Dua sesi di dalam container yang sama dapat saling mengirim pesan secara normal. Aturan yang sama menjelaskan mengapa sesi yang berjalan sebagai root dan sesi yang berjalan sebagai pengguna normal Anda tidak dapat saling menjangkau: socket dibatasi hanya untuk pengguna sistem operasi yang memilikinya.

Apakah pesan dari sesi Claude Code lain aman untuk ditindaklanjuti?

Anggap teks tersebut sebagai input yang tidak tepercaya, karena sesi pengirim mungkin telah membaca halaman web, README, atau komentar issue yang ditulis oleh orang lain. Claude Code sudah mencegah pesan tersebut untuk bertindak sendiri: pesan tidak dapat menyetujui prompt izin yang tertunda, tidak dapat mengubah pengaturan izin atau CLAUDE.md atas permintaan, dan perintah slash dalam teks akan tiba sebagai teks biasa dan tidak akan pernah dijalankan. Perlindungan tersebut mencakup izin, bukan penilaian, jadi bacalah apa yang diterima sebelum Anda memerintahkan sesi penerima untuk menindaklanjutinya.

Apakah perpesanan lintas sesi mengirim kode saya ke Anthropic?

Antara dua sesi di mesin yang sama, tidak. Pesan dikirim melalui socket per sesi di mesin tersebut dan tidak pernah melalui server Anthropic, dan hanya teks yang ditulis Claude yang dikirim, bukan riwayat percakapan atau file. Pesan ke sesi di mesin Anda yang lain, atau ke sesi di web, memang dikirim melalui server Anthropic melalui koneksi Remote Control, dan dalam arah tersebut Claude hanya dapat membalas pesan yang masuk, bukan memulai pesan. Atur isolatePeerMachines ke true untuk mewajibkan persetujuan Anda sebelum ada data yang keluar dari mesin.