Cara Sesi Claude Code Saling Menghantar Mesej

Maksud sesi Claude Code menghantar mesej antara satu sama lain

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

Ciri ini dipanggil pemesejan antara sesi. Setakat August 2026, ciri ini memerlukan Claude Code v2.1.224 atau yang lebih baharu, dan berjalan pada macOS serta Linux, termasuk Linux dalam WSL 2. Sokongan Windows natif tidak tersedia. Ciri ini juga tidak tersedia pada Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform atau Microsoft Foundry. Apabila sesi memenuhi keperluan tersebut, pemesejan sudah diaktifkan dan tiada apa-apa yang perlu diaktifkan. Tingkah laku yang diterangkan di bawah adalah berdasarkan dokumentasi Anthropic tentang pemesejan antara sesi.

VPS ialah tempat ciri ini berguna, kerana sesi pada VPS boleh berjalan cukup lama untuk dirujuk. Pada komputer riba, anda menutup penutupnya. Pada pelayan yang menggunakan tmux, sesi yang anda mulakan pada hari Isnin masih berjalan pada hari Khamis dan masih menyimpan konteks satu repositori. Apabila terdapat dua sesi seperti itu, cara kedua-duanya berkomunikasi bukan lagi sekadar teori. Jika anda belum menyediakan perkara ini, mulakan dengan menjalankan Claude Code pada VPS menggunakan tmux, yang menerangkan penyediaan sesi yang diandaikan oleh panduan ini.

Bila sesi kedua berbaloi dari segi token

Mulakan dengan kos. Setiap sesi ialah instance Claude yang berasingan dengan tetingkap konteksnya sendiri. Oleh itu, dua sesi berharga kira-kira dua kali ganda berbanding satu sesi bagi tempoh yang sama. Mesej yang dihantar dikira dalam penggunaan sama seperti prompt yang anda taip. Penyelarasan bukan percuma. Kerja yang sebenarnya terdiri daripada satu urutan langkah menjadi lebih perlahan dan lebih mahal apabila dipecahkan kepada beberapa sesi.

Situasi yang menjadikan sesi kedua berbaloi mempunyai corak yang sama. Dua bahagian kerja berjalan serentak tanpa menunggu satu sama lain, dan salah satu daripadanya memperoleh maklumat yang diperlukan oleh bahagian yang lain semasa tugas berlangsung.

• Satu sesi menemui perubahan yang memecahkan keserasian, manakala sesi yang lain sedang membina berdasarkan kod yang terjejas. Claude meringkaskan perubahan itu dan menghantarnya, jadi anda tidak perlu menaip semula maklumat tersebut dalam terminal yang lain.
• Dua sesi mengendalikan repositori yang sama dalam git worktree berasingan, dan salah satu sesi perlu mengetahui perubahan yang telah digabungkan.
• Proses migrasi atau ujian yang panjang melaporkan hasilnya kembali kepada sesi yang sedang anda pantau.
• Satu sesi membina dan satu sesi menyemak. Sesi penyemak membaca hasil yang dijana oleh sesi pembina, kemudian menghantar penemuannya.

Apabila kerja dilakukan secara berurutan, atau apabila kedua-dua sesi akan mengubah fail yang sama, gunakan satu sesi. Jika anda mahukan kumpulan terselaras yang dicipta dan diselia oleh Claude dalam satu tugas, gunakan agent teams. Ini ialah ciri berasingan yang masih dalam fasa eksperimen. Jika anda hanya mahu perbualan yang sama dalam terminal lain, sambung semula sesi tersebut. Pemesejan merentas sesi adalah untuk sesi bebas yang anda mulakan dan pandu sendiri.

Semak sama ada ciri itu tersedia sebelum merancang penggunaannya

Versi dahulu:

claude --version

Bandingkan nombor itu dengan 2.1.224. Kemudian, dalam sesi tersebut, taip /list-agents, yang juga menerima /peers. Perintah itu mencetak setiap ejen yang boleh dicapai oleh sesi ini, bersama-sama nama yang digunakan oleh setiap ejen untuk menjawab. Jika perintah itu langsung tidak dikenali, sesi ini tidak mempunyai pemesejan silang sesi dan tiada fail tetapan yang dapat mengubahnya. Taip /status dan cari baris Peer address: baris itu mengandungi alamat peti masuk sesi ini sendiri, dengan awalan uds:.

Terdapat satu perangkap yang khusus menjejaskan pengguna VPS. Pemesejan silang sesi bergantung pada penilaian feature flag, dan beberapa pemboleh ubah privasi mematikan penilaian itu. Akibatnya, ciri tersebut kekal dalam keadaan lalai, iaitu dimatikan. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC dan DISABLE_GROWTHBOOK semuanya melakukan perkara ini. Pentadbir biasanya mengukuhkan pelayan baharu dengan menampal pemboleh ubah tersebut ke dalam ~/.bashrc, kemudian tertanya-tanya sebab /list-agents tidak wujud. Nilai yang sama juga boleh datang daripada peta env dalam fail tetapan atau daripada tetapan terurus, jadi semak shell terlebih dahulu.

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

Nyahset mana-mana pemboleh ubah yang menghasilkan output. Bagi DISABLE_TELEMETRY dan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, sebarang nilai yang tidak kosong menghidupkan tingkah laku tersebut, termasuk rentetan 0. Oleh itu, DISABLE_TELEMETRY=0 tidak melakukan perkara seperti yang kelihatan. Matikan ciri itu dengan menyahset pemboleh ubah berkenaan atau menetapkannya kepada rentetan kosong.

Namakan sesi anda, atau Claude tidak dapat menyasarkannya

Claude menyasarkan mesej kepada sesi berdasarkan namanya. Tetapkan nama apabila anda memulakan sesi:

claude --name builder-api

Anda juga boleh menetapkan nama dengan /rename dalam sesi yang sedang berjalan. Jika anda tidak menetapkan nama, Claude Code menjana nama berdasarkan nama folder direktori kerja, seperti myapp-3f. Ini memadai untuk satu sesi, tetapi mengelirukan apabila terdapat empat sesi. Dua sesi juga boleh mendapat nama yang sama. Output /list-agents memaparkan direktori kerja setiap sesi setempat, supaya anda boleh membezakan sesi yang mempunyai nama sama. Senarai Claude sendiri turut menambahkan pengecam ringkas pada alamat apabila nama bertindih. Menamakan sesi sendiri lebih mudah daripada membaca pengecam.

Susunan tmux dua sesi yang boleh anda hasilkan semula

Ini ialah sesi builder dan sesi reviewer pada satu repositori. Reviewer berfungsi dalam git worktree yang berasingan, jadi kedua-duanya tidak pernah menulis pada fail yang sama. git worktree add bersama HEAD menghasilkan checkout terpisah, iaitu pilihan yang sesuai untuk sesi yang membaca dan bukannya membuat commit. Oleh sebab kedua-dua sesi menjalankan tugas yang berbeza, anda wajar memberikan reviewer gaya output tersendiri. Gaya ini mengubah system prompt sesi tersebut dan kekal pada setiap giliran, bukannya hilang seperti arahan yang ditaip sekali.

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 window mengikut nama supaya anda boleh memilih salah satu. Dalam window builder, jalankan /list-agents. Anda sepatutnya melihat reviewer-api dengan direktori kerja ~/src/api-review. Jika tidak ada, sesi reviewer belum selesai dimulakan atau salah satu daripada dua masalah dalam bahagian seterusnya berlaku. Kemudian serahkan sesuatu dalam bahasa biasa:

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 itu, dan kandungan yang dihantar oleh Claude berbeza-beza. Dalam window reviewer, mesej itu muncul dalam perbualan bersama nama pengirim. Jika sesi tersebut tidak aktif, Claude terus memulakan giliran baharu padanya. Jika sesi sedang menjalankan giliran, mesej itu menunggu sehingga antara panggilan tool, jadi arahan yang sedang berjalan tidak pernah diganggu. Selepas Claude membacanya, mesej itu diringkaskan menjadi baris Message from satu baris yang dikembangkan oleh Ctrl+O. Kedua-dua sesi ini berfungsi dengan lebih baik apabila builder mengekalkan perubahan yang kecil, kerana diff yang sempit menghasilkan serahan yang lebih ringkas dan membolehkan sesi lain menyelesaikan semakan dalam satu giliran. Inilah tabiat yang kemahiran lazy senior dev cuba tegakkan.

Siapa boleh melihat siapa pada satu VPS

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

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

Container mempunyai sistem failnya sendiri. Sesi dalam Docker dan sesi pada hos tidak dapat mencapai satu sama lain kerana kedua-duanya tidak membaca fail pendaftaran yang sama. Dua sesi dalam container yang sama boleh berbalas mesej seperti biasa. Jika anda mengekalkan agent dalam container untuk pengasingan, seperti dalam menjalankan agent pengekodan dalam VM pakai buang, jangkakan pemesejan berfungsi dalam container tetapi tidak merentasi sempadan container.

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

Sebab mesej anda tidak pernah sampai

Sebab yang lazim tiada kaitan dengan rangkaian. Sesi penerima menentukan tindakan terhadap mesej itu, dan keputusannya ialah untuk tidak menghantarnya. Setiap mesej yang tiba berakhir dengan salah satu daripada tiga hasil: dihantar, ditahan (diasingkan tanpa dihantar sehingga anda meluluskannya), atau ditolak (digugurkan tanpa dihantar).

Apabila tiada nilai crossSessionInbound digunakan, Claude Code menentukan tindakan bagi setiap mesej dengan membandingkan mod kebenaran kedua-dua sesi. Sesi yang memintas gesaan kebenaran dikelompokkan dalam satu kelas, manakala semua sesi lain dikelompokkan dalam kelas yang satu lagi. auto, acceptEdits dan dontAsk dikira sebagai mod yang memaparkan gesaan. Mod pelan dikira sebagai memintas gesaan dalam sesi yang mempunyai kebenaran untuk memintasnya. Jika anda tidak pasti sesi berada dalam kelas yang mana, cara sebenar setiap mod kebenaran berfungsi wajar dibaca dahulu, kerana kebanyakan sesi kini bermula dalam mod auto dan mod itu berada pada sisi gesaan dalam pembahagian tersebut. Peraturan ini adalah simetri:

• Sesi penerima yang memaparkan gesaan kebenaran menerima setiap mesej. Sesi itu hanya menahan mesej apabila sesi penghantar mengenal pasti dirinya sebagai sesi yang memintas gesaan.
• Sesi penerima yang memintas gesaan menahan setiap mesej untuk kelulusan anda. Sesi itu hanya menghantar mesej apabila penghantar juga memintas gesaan.

Oleh itu, aliran kerja pertama yang dibina oleh kebanyakan orang sebenarnya ialah aliran kerja yang tidak berfungsi. Anda memulakan pembina dengan --permission-mode bypassPermissions kerana mahu pembina itu berjalan tanpa pengawasan, membiarkan penyemak menggunakan tetapan lalai, lalu setiap mesej yang dihantar oleh pembina menunggu dalam dialog kelulusan yang tiada sesiapa memantaunya. Dialog itu ditutup selepas tempoh dialogExpiry, yang lalainya ialah 5m, lalu mesej tersebut digugurkan. Pada mesin yang sama, sesi penghantar menerima pemberitahuan apabila mesejnya ditahan, diikuti pemberitahuan apabila penerima kemudian menghantar, menolak atau membiarkan mesej itu tamat tempoh. Oleh itu, baca skrin penghantar sebelum menyalahkan soket.

Untuk membolehkan sesi menerima mesej tanpa pengawasan, tetapkan crossSessionInbound kepada accept. Lokasi tetapan menentukan skop penggunaannya. Claude Code membaca tetapan terurus dahulu, kemudian flag --settings, dan seterusnya tetapan pengguna. Nilai pertama yang ditemui akan digunakan. Nilai dalam tetapan projek atau setempat hanya digunakan apabila nilainya lebih ketat, mengikut turutan accept < hold < refuse. Nilai accept dalam .claude/settings.json lebih longgar daripada semua nilai lain, jadi nilai itu diabaikan apabila sumber dipercayai telah menetapkan sesuatu nilai. Letakkan nilai itu 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 pekerja itu tidak dapat memaparkan dialog kelulusan. Mesej yang ditahan di situ kekal ditahan sehingga perubahan mod atau tetapan yang seterusnya membenarkannya. Baris --settings di atas ialah cara untuk membolehkan pekerja sedemikian menerima mesej. Sesi yang dimulakan dalam mod bare tidak mengikat sebarang soket, jadi sesi itu tidak dapat menerima mesej atau muncul dalam senarai.

Apabila penyerahan kerja menemui jalan buntu

Gelung mesej diuruskan secara automatik. Claude Code mengehadkan kadar mesej berulang daripada setiap pengirim, menggugurkan mesej berulang yang sama jika diterima dalam tempoh yang singkat, dan mengehadkan mesej yang diterima tetapi belum dibaca kepada 50 bagi setiap sesi. Oleh itu, dua sesi tidak boleh saling menghantar mesej tanpa henti. Mesej yang ditahan dihadkan kepada 100, dan mesej paling lama akan digugurkan selepas jumlah itu dicapai.

Kegagalan yang berlaku biasanya lebih senyap dan melibatkan penyerahan kerja, bukan gelung. Sesi A bertanya kepada sesi B soalan yang perlu dijawab sebelum sesi A boleh meneruskan kerja, kemudian menjadi tidak aktif. Sesi B mungkin menahan mesej itu, sedang menjalankan tugas yang panjang, atau menjawab soalan yang sebenarnya tidak ditanya oleh sesi A. Sesi A terus menunggu. Apabila anda kembali sejam kemudian, terdapat dua sesi tidak aktif dan tiada kerja yang selesai.

Tulis penyerahan kerja yang tidak memerlukan balasan. Mesej yang baik menyampaikan fakta atau keputusan: perkara yang berubah dan hasilnya. Mesej yang tidak baik meminta sesi lain mendapatkan kebenaran atau memberikan jawapan yang menyebabkan pengirim tidak dapat meneruskan kerja. Claude telah diarahkan supaya tidak meminta sesi lain melakukan tindakan yang akan disekat oleh tetapan kebenarannya sendiri, dan sebaliknya mengembalikan tugas itu kepada anda. Luaskan peraturan itu sendiri. Jika sesuatu sesi tidak dapat meneruskan kerja tanpa jawapan, andalah yang perlu menjawabnya. Disiplin konteks juga membantu kerana sesi yang sudah kehilangan konteks akan menulis mesej yang kabur; mengurus konteks dalam Claude Code menerangkan aspek tersebut.

Anggap mesej masuk sebagai input yang tidak dipercayai

Claude Code memberitahu Claude penerima bahawa mesej itu datang daripada sesi lain dan bukannya daripada anda, serta mengehadkan tindakan yang boleh dilakukan oleh mesej tersebut. Penguatkuasaan ini berlaku dalam program yang membalut model, bukannya bergantung pada kesediaan model untuk mematuhi arahan. Inilah perbezaan praktikal yang dibuat oleh rangka kerja ejen. Mesej tidak boleh menjawab gesaan kebenaran yang masih belum selesai bagi pihak anda, kerana keizinan daripada sesi lain bukan keizinan anda. Mesej itu tidak boleh mengubah tetapan kebenaran, CLAUDE.md atau konfigurasi lain hanya kerana diminta oleh sesi lain. Perintah slash dalam teks, seperti /compact, diterima sebagai teks biasa dan tidak pernah dilaksanakan. Jika tindakan terhadap mesej itu memerlukan kebenaran yang tidak dimiliki oleh sesi penerima, anda akan melihat gesaan yang sama seperti bagi kerja lain. Dalam mod automatik, pengelas turut menyemak setiap mesej sebelum penghantaran. Mesej yang disekat tidak akan sampai kepada penerima. Had ini kekal dalam mod permisif. Oleh itu, sesi yang memintas kawalan memegang mesej masuk secara lalai dan bukannya mempercayainya.

Ini meliputi kebenaran. Ia tidak meliputi kandungan. Sesi penghantar mungkin telah membaca perihalan pull request, halaman web, README dependency atau komen isu yang ditulis oleh orang asing. Apa sahaja yang dibacanya boleh mempengaruhi teks yang ditulisnya kepada sesi anda yang lain. Mesej itu ialah data. Anda perlu mencurigainya seperti mana-mana teks lain yang masuk ke dalam sesi dari luar. Inilah disiplin yang diterangkan dalam menjauhkan rahsia daripada ejen AI anda: anggap apa sahaja yang melintasi sempadan kepercayaan mungkin salah, dan jangan biarkan kandungan itu memberikan kebenaran kepada dirinya sendiri.

Terdapat dua kawalan jika anda mahu mengurangkan keadaan ini. Menetapkan crossSessionInbound kepada refuse akan membuang mesej peer masuk tanpa menghantarnya. Jika ditetapkan dalam tetapan projek atau setempat, nilai itu mengatasi semua sumber lain kerana ia paling ketat dalam hierarki tersebut. Untuk menghentikan sesi ini daripada menghantar atau menyenaraikan mesej, tambahkan peraturan penolakan kebenaran yang menamakan SendMessage dan ListAgents. Kedua-duanya hendaklah ditulis sebagai nama alat sahaja tanpa penentu. Menetapkan isolatePeerMachines kepada true memerlukan kelulusan jelas anda sebelum sebarang mesej sampai kepada sesi di luar mesin ini. Kelulusan itu tetap diperlukan walaupun dalam mod bypassPermissions.

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

Menolak SendMessage turut menghapuskan pemesejan kepada subejen kerana alat yang sama digunakan untuk kedua-duanya. Sesi yang menolak tidak menunjukkan perubahan yang boleh dilihat pada /status sendiri atau pada senarai sesi lain. Oleh itu, sahkan tetapan tersebut daripada konfigurasi sesi, bukan daripada paparan skrin.

Bridges dan pelayan MCP memori dikongsi

Beberapa projek pihak ketiga dilancarkan dalam tempoh yang sama dengan fungsi yang berdekatan: bridges ejen-ke-ejen tempatan yang menyampaikan teks antara ejen yang sedang berjalan, serta pelayan MCP (model context protocol) yang menyediakan satu stor dikongsi untuk dibaca dan ditulis oleh beberapa ejen. Nilai projek ini sebagai bentuk yang berbeza, bukan sebagai pesaing, dan sahkan sebarang arahan pemasangan dengan README projek itu sendiri sebelum menjalankannya. Pemesejan ialah push kerana penghantar memasukkan teks ke dalam giliran penerima. Stor dikongsi ialah pull kerana tiada sesi yang diganggu dan sesuatu sesi melihat nota apabila sesi itu menyemaknya pada kali seterusnya. Pull lebih sesuai untuk status yang berubah secara perlahan, dan kaedah ini hanya berfungsi apabila sesuatu sesi benar-benar menyemaknya.

Jika anda memilih pendekatan itu, soalan yang wajar ditanya berkaitan dengan proses, bukan senarai ciri. Pelayan itu berjalan sebagai pengguna mana, dan apakah yang boleh dibacanya pada pelayan tersebut. Menjalankan pelayan MCP pada VPS menerangkan persediaan itu. Berkongsi kemahiran ejen antara repositori menerangkan kes yang lebih mudah apabila perkara yang ingin dikongsi antara sesi ialah arahan, bukan keadaan semasa. Pendekatan ini juga mengurangkan banyak mesej yang perlu dihantar. Untuk gambaran yang lebih luas, menjalankan ejen pengekodan pada VPS ialah tempat untuk bermula.

FAQ

Mengapakah /list-agents tidak dikenali dalam sesi saya?

Sesi itu tidak mempunyai pemesejan antara sesi. Semak claude --version terhadap 2.1.224 terlebih dahulu kerana ciri ini memerlukan versi tersebut atau yang lebih baharu. Kemudian semak platform kerana ciri ini berjalan pada macOS dan Linux, tetapi bukan pada Windows asli. Ciri ini juga 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 ini dan menyebabkan ciri itu kekal dimatikan.

Mengapakah mesej saya kepada sesi lain tidak pernah sampai?

Jika /list-agents berfungsi, pemesejan telah diaktifkan dan terdapat halangan khusus pada mesej itu. Punca lazim ialah mod kebenaran. Sesi yang memintas prompt kebenaran akan menahan setiap mesej masuk untuk kelulusan anda, kecuali pengirim juga memintas prompt tersebut. Dialog kelulusan itu akan digugurkan selepas tempoh dialogExpiry, iaitu lima minit secara lalai. Semak sesi pengirim untuk melihat notis mesej ditahan. Untuk membaikinya, tetapkan crossSessionInbound kepada accept dalam ~/.claude/settings.json atau hantar nilai itu dengan --settings kerana accept dalam tetapan projek atau setempat akan diabaikan sebagai nilai yang lebih longgar.

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

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

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

Anggap teks itu sebagai input yang tidak dipercayai kerana sesi pengirim mungkin telah membaca halaman web, README atau komen isu yang ditulis oleh orang lain. Claude Code sudah menghalang mesej itu daripada bertindak sendiri: ia tidak boleh meluluskan prompt kebenaran yang masih menunggu, tidak boleh mengubah tetapan kebenaran atau CLAUDE.md atas permintaan, dan slash command dalam teks diterima sebagai teks biasa serta tidak pernah dijalankan. Perlindungan ini hanya meliputi kebenaran, bukan pertimbangan. Oleh itu, baca kandungan yang diterima sebelum anda mengarahkan sesi penerima untuk bertindak.

Adakah pemesejan antara sesi menghantar kod saya kepada Anthropic?

Tidak, jika melibatkan dua sesi pada mesin yang sama. Mesej dihantar melalui soket khusus sesi pada mesin itu dan tidak melalui pelayan Anthropic. 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 dihantar melalui pelayan Anthropic menerusi sambungan Remote Control. Dalam arah itu, Claude hanya boleh membalas mesej yang diterima dan tidak boleh memulakan mesej. Tetapkan isolatePeerMachines kepada true untuk memerlukan kelulusan anda sebelum apa-apa meninggalkan mesin.