Cara Claude Code Mengirim Pesan Antar-Sesi

Makna sesi Claude Code saat saling mengirim pesan

Dua sesi Claude Code dapat saling mengirim pesan jika berjalan pada mesin yang sama dan menggunakan user sistem operasi yang sama. Pesan adalah satu bagian teks biasa yang ditulis oleh satu Claude untuk Claude lainnya. Pesan tidak membawa riwayat percakapan atau file. Claude menemukan sesi lainnya dengan tool ListAgents dan mengirimkan teks tersebut dengan SendMessage, sehingga Anda tidak pernah memanggil kedua tool itu secara manual. Anda cukup menjelaskan informasi yang perlu diketahui sesi lainnya, lalu Claude menulis pesannya sendiri.

Fitur ini disebut 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. Fitur ini tidak mendukung Windows secara native dan tidak tersedia di Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, atau Microsoft Foundry. Jika sebuah sesi memenuhi persyaratan tersebut, messaging sudah aktif dan tidak ada yang perlu diaktifkan. Perilaku yang dijelaskan di bawah ini berasal dari dokumentasi Anthropic tentang cross-session messaging.

VPS adalah tempat fitur ini berguna, karena sesi pada VPS dapat berjalan cukup lama sehingga layak dituju. Pada laptop, Anda menutup penutupnya. Pada server yang menjalankan tmux, sesi yang Anda mulai pada hari Senin masih berjalan pada hari Kamis dan masih menyimpan konteks satu repositori. Setelah memiliki dua sesi seperti itu, cara keduanya berkomunikasi bukan lagi sekadar teori. Jika Anda belum menyiapkannya, mulai dari menjalankan Claude Code pada VPS menggunakan tmux, yang membahas pengelolaan sesi yang diasumsikan oleh panduan ini.

Kapan sesi kedua sepadan dengan biayanya

Mulailah dari biayanya. Setiap sesi adalah instance Claude terpisah dengan context window sendiri, sehingga dua sesi memerlukan biaya kira-kira dua kali lipat dibandingkan satu sesi dalam periode yang sama. Pesan yang dikirim juga dihitung dalam penggunaan, sama seperti prompt yang Anda ketik. Koordinasi tidak gratis. Pekerjaan yang sebenarnya merupakan satu rangkaian langkah akan menjadi lebih lambat dan mahal jika dibagi ke beberapa sesi.

Situasi ketika sesi kedua sepadan dengan biayanya memiliki pola yang sama. Dua bagian pekerjaan berjalan secara bersamaan tanpa saling menunggu, dan salah satunya menemukan informasi yang diperlukan oleh bagian lainnya di tengah proses.

• Satu sesi menemukan breaking change saat sesi lainnya sedang membangun kode yang terdampak. Claude merangkum perubahan tersebut dan mengirimkannya, sehingga Anda tidak perlu mengetiknya ulang di terminal lain.
• Dua sesi mengerjakan repository yang sama pada git worktree terpisah, dan salah satunya perlu mengetahui perubahan yang sudah diterapkan.
• Proses migrasi atau pengujian yang panjang mengirimkan hasilnya kembali ke sesi yang sedang Anda pantau.
• Satu sesi berperan sebagai builder dan sesi lainnya sebagai reviewer. Reviewer membaca hasil yang dibuat builder, lalu mengirimkan temuannya.

Jika pekerjaan berlangsung secara berurutan atau kedua sesi akan mengubah file yang sama, gunakan satu sesi. Jika Anda menginginkan grup terkoordinasi yang dibuat dan diawasi oleh Claude dalam satu tugas, gunakan agent teams. Fitur ini terpisah dan masih eksperimental. Jika Anda hanya ingin melanjutkan percakapan yang sama di terminal lain, gunakan resume session. Pesan lintas sesi ditujukan untuk sesi independen yang Anda mulai dan arahkan sendiri.

Periksa keberadaan fitur sebelum mengandalkannya

Periksa versinya terlebih dahulu:

claude --version

Bandingkan nomornya dengan 2.1.224. Kemudian, di dalam sesi, ketik /list-agents, yang juga dapat dipanggil dengan /peers. Perintah ini menampilkan semua agen yang dapat dijangkau oleh sesi tersebut, beserta nama yang digunakan setiap agen untuk merespons. Jika perintah sama sekali tidak dikenali, sesi ini tidak memiliki kemampuan pengiriman pesan antar-sesi, dan tidak ada file pengaturan yang dapat mengubahnya. Ketik /status dan cari baris Peer address: baris ini berisi alamat kotak masuk sesi ini sendiri, dengan awalan uds:.

Ada satu hal yang khusus memengaruhi pengguna VPS. Pengiriman pesan antar-sesi bergantung pada evaluasi feature flag. Beberapa variabel privasi menonaktifkan evaluasi tersebut sehingga fitur tetap dalam keadaan default, yaitu nonaktif. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, dan DISABLE_GROWTHBOOK semuanya menyebabkan hal ini. Pengguna biasanya memperketat keamanan server baru dengan menempelkan variabel tersebut ke ~/.bashrc, lalu bertanya-tanya mengapa /list-agents tidak ada. Nilai yang sama dapat berasal dari map env dalam file pengaturan atau dari pengaturan terkelola. Karena itu, periksa shell terlebih dahulu.

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

Hapus variabel mana pun yang menghasilkan output. Untuk DISABLE_TELEMETRY dan CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, nilai apa pun yang tidak kosong mengaktifkan perilaku tersebut, termasuk string 0. Jadi, DISABLE_TELEMETRY=0 tidak berfungsi seperti yang tampak. Nonaktifkan perilaku ini dengan menghapus variabel tersebut atau menetapkannya ke string kosong.

Beri nama pada sesi Anda, atau Claude tidak dapat mengarahkannya

Claude mengarahkan pesan ke suatu 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 tidak menetapkan nama, Claude Code membuat nama dari nama folder direktori kerja, misalnya myapp-3f. Hal ini cukup untuk satu sesi, tetapi membingungkan jika ada empat sesi. Dua sesi juga dapat memiliki nama yang sama. Output /list-agents menampilkan direktori kerja setiap sesi lokal, sehingga sesi dengan nama yang sama dapat dibedakan. Daftar milik Claude juga menambahkan pengenal singkat pada alamat jika terdapat nama yang sama. Menamai sesi sendiri lebih hemat daripada membaca pengenal.

Tata letak tmux dua sesi yang dapat Anda buat ulang

Ini adalah sesi builder dan sesi reviewer pada satu repositori. Reviewer bekerja di git worktree terpisah, sehingga keduanya tidak pernah menulis file yang sama. git worktree add bersama HEAD menghasilkan checkout terlepas, yang sesuai untuk sesi yang membaca, bukan melakukan commit.

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 menampilkan window berdasarkan namanya agar Anda dapat memilih salah satunya. Pada window builder, jalankan /list-agents. Anda akan melihat reviewer-api dengan direktori kerjanya, ~/src/api-review. Jika tidak ada, sesi reviewer belum selesai dimulai, atau salah satu dari dua masalah pada bagian berikutnya 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 mengirimkannya. Anda tidak menulis isi pesannya, dan pesan yang dikirim Claude dapat berbeda-beda. Pada window reviewer, pesan tersebut muncul dalam percakapan bersama nama pengirimnya. Jika sesi itu sedang idle, Claude langsung memulai giliran baru di dalamnya. Jika sesi sedang menjalankan giliran, pesan menunggu hingga di antara pemanggilan tool, sehingga perintah yang sedang berjalan tidak pernah disela. Setelah Claude membacanya, pesan tersebut diciutkan menjadi baris Message from satu baris yang diperluas oleh Ctrl+O. Keduanya bekerja lebih baik jika builder menjaga perubahan tetap kecil, karena diff yang sempit menghasilkan serah terima yang lebih singkat dan review yang dapat diselesaikan oleh sesi lain dalam satu giliran. Inilah kebiasaan yang ingin ditegakkan oleh keterampilan developer senior yang malas.

Siapa 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 inbox-nya sendiri, lalu Claude Code membaca file tersebut untuk menemukan sesi lain. Ada dua konsekuensi, dan keduanya penting 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, meskipun berjalan berdampingan dalam server tmux yang sama, karena sesi milik satu pengguna tidak dapat mengakses socket milik pengguna lain. Jalankan kedua sesi sebagai pengguna yang sama.

Container memiliki filesystem sendiri. Sesi di dalam Docker dan sesi pada host tidak dapat saling mengakses, karena keduanya tidak membaca file registrasi yang sama. Dua sesi di dalam container yang sama dapat saling mengirim pesan secara normal. Jika Anda menyimpan agent di dalam container untuk isolasi, seperti pada menjalankan coding agent dalam VM sekali pakai, perkirakan messaging berfungsi di dalam container, tetapi tidak melintasi batas container.

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

Mengapa pesan Anda tidak pernah sampai

Alasan yang umum tidak berkaitan dengan jaringan. Sesi penerima menentukan tindakan terhadap pesan tersebut, dan keputusan yang diambil adalah tidak mengirimkannya. Setiap pesan yang tiba berakhir pada salah satu dari tiga hasil: terkirim, ditahan (disisihkan dan tidak dikirim sampai Anda menyetujuinya), atau ditolak (dihapus tanpa dikirim).

Jika tidak ada nilai crossSessionInbound yang berlaku, Claude Code menentukan tindakan untuk setiap pesan dengan membandingkan mode izin kedua sesi. Sesi yang melewati prompt izin dikelompokkan ke dalam satu kelas, sedangkan semua sesi lainnya dikelompokkan ke kelas lain. auto, acceptEdits, dan dontAsk dihitung sebagai mode yang menampilkan prompt. Plan mode dihitung sebagai mode yang melewati prompt pada sesi yang memiliki izin untuk melewatinya. Aturannya bersifat simetris:

• Sesi penerima yang menampilkan prompt izin akan mengirimkan setiap pesan. Sesi tersebut hanya menahan pesan jika sesi pengirim mengidentifikasi dirinya sebagai sesi yang melewati prompt.
• Sesi penerima yang melewati prompt akan menahan setiap pesan untuk Anda setujui. Sesi tersebut hanya mengirimkan pesan jika pengirim juga melewati prompt.

Karena itu, alur kerja pertama yang biasanya dibuat orang justru tidak berfungsi. Anda memulai builder dengan --permission-mode bypassPermissions agar dapat berjalan tanpa pengawasan, membiarkan reviewer menggunakan pengaturan default, lalu setiap pesan yang dikirim builder menunggu dalam dialog persetujuan yang tidak sedang dipantau siapa pun. Dialog tersebut ditutup setelah batas waktu dialogExpiry, yang secara default adalah 5m, lalu pesan dihapus. Pada mesin yang sama, sesi pengirim menerima pemberitahuan ketika pesannya ditahan, serta pemberitahuan lanjutan ketika penerima kemudian mengirimkan, menolak, atau membiarkan pesan kedaluwarsa. Jadi, periksa layar pengirim sebelum menyalahkan socket.

Agar sesi menerima pesan tanpa pengawasan, tetapkan crossSessionInbound ke accept. Lokasi pengaturan menentukan cakupan penerapannya. Claude Code membaca managed settings terlebih dahulu, kemudian flag --settings, lalu user settings, dan menerapkan nilai pertama yang ditemukan. Nilai dalam project atau local settings hanya berlaku jika nilainya lebih ketat, berdasarkan urutan accept < hold < refuse. Nilai accept dalam .claude/settings.json lebih longgar daripada nilai apa pun, sehingga diabaikan jika trusted source telah menetapkan suatu nilai. Masukkan nilai tersebut ke dalam ~/.claude/settings.json, atau teruskan untuk satu sesi:

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

Worker claude -p tanpa antarmuka mengikat inbox socket seperti sesi interaktif dan muncul dalam daftar, tetapi tidak dapat menampilkan dialog persetujuan. Pesan yang ditahan di sana tetap ditahan sampai perubahan mode atau pengaturan berikutnya mengizinkannya. Baris --settings di atas digunakan untuk membuat worker tersebut menerima pesan. Sesi yang dimulai dalam bare mode tidak mengikat socket sama sekali, sehingga tidak dapat menerima pesan atau muncul dalam daftar.

Saat serah terima mengalami kebuntuan

Loop pesan ditangani secara otomatis. Claude Code membatasi laju pesan berulang dari setiap pengirim, membuang pesan identik yang tiba dalam jangka waktu singkat, dan membatasi pesan yang diterima tetapi belum dibaca hingga 50 per sesi. Dengan demikian, dua sesi tidak dapat saling mengirim pesan tanpa batas. Pesan yang ditahan dibatasi hingga 100; pesan tertua akan dibuang jika jumlahnya melebihi batas tersebut.

Kegagalan yang benar-benar terjadi biasanya lebih sulit terlihat dan berbentuk serah terima, bukan loop. Sesi A mengajukan pertanyaan kepada sesi B yang jawabannya diperlukan agar A dapat melanjutkan, lalu A menjadi idle. B menahan pesan tersebut, sedang menjalankan tugas yang panjang, atau menjawab pertanyaan yang sebenarnya tidak diajukan A. A menunggu. Anda kembali satu jam kemudian dan mendapati dua sesi idle tanpa pekerjaan yang selesai.

Tulis serah terima yang tidak memerlukan balasan. Pesan yang baik menyampaikan fakta atau keputusan: apa yang berubah dan apa hasilnya. Pesan yang buruk meminta sesi lain memberikan izin atau jawaban yang membuat pengirim tidak dapat melanjutkan. Claude sudah diarahkan untuk tidak pernah meminta sesi lain menjalankan tindakan yang akan diblokir oleh pengaturan izinnya sendiri, dan untuk mengembalikan pekerjaan tersebut kepada Anda. Terapkan aturan itu secara lebih luas. Jika sebuah sesi tidak dapat melanjutkan tanpa jawaban, Anda yang harus menjawabnya. Disiplin konteks juga membantu, karena sesi yang kehilangan alur akan menulis pesan yang samar; mengelola konteks di Claude Code membahas aspek tersebut.

Perlakukan pesan masuk sebagai input yang tidak tepercaya

Claude Code memberi tahu Claude penerima bahwa pesan tersebut berasal dari sesi lain, bukan dari Anda, dan membatasi tindakan yang dapat dilakukan pesan tersebut. Pesan tidak dapat menjawab permintaan izin yang tertunda atas nama Anda, karena persetujuan dari sesi lain bukan persetujuan Anda. Pesan tersebut tidak dapat mengubah pengaturan izin, CLAUDE.md, atau konfigurasi lainnya hanya karena diminta oleh sesi lain. Perintah slash di dalam teks, seperti /compact, diterima sebagai teks biasa dan tidak pernah dijalankan. Jika tindakan berdasarkan pesan memerlukan izin yang tidak dimiliki sesi penerima, Anda akan melihat permintaan yang sama seperti pada pekerjaan lainnya. Dalam mode otomatis, classifier juga meninjau setiap pesan sebelum pengiriman. Pesan yang diblokir tidak pernah sampai ke penerima. Batasan ini tetap berlaku dalam mode yang lebih permisif. Karena itu, sesi yang melewati batasan tersebut secara default menahan pesan masuk, bukan mempercayainya.

Hal tersebut mencakup izin, tetapi tidak mencakup isi pesan. Sesi pengirim mungkin telah membaca deskripsi pull request, halaman web, README dependensi, atau komentar issue yang ditulis orang yang tidak dikenal. Apa pun yang dibacanya dapat memengaruhi teks yang ditulisnya ke sesi Anda yang lain. Pesan tersebut adalah data. Perlakukan pesan itu dengan kecurigaan yang sama seperti teks lain yang masuk ke sesi dari luar. Inilah disiplin yang dijelaskan dalam menjauhkan rahasia dari agen AI Anda: anggap apa pun yang melewati batas kepercayaan dapat salah, dan jangan pernah membiarkannya memberikan otorisasi kepada dirinya sendiri.

Tersedia dua kontrol jika Anda ingin mengurangi hal ini. Mengatur crossSessionInbound ke refuse akan menghapus pesan peer masuk tanpa mengirimkannya. Dari project settings atau local settings, nilai tersebut berlaku di atas semua sumber lainnya karena merupakan nilai paling ketat dalam hierarki. Untuk menghentikan sesi ini agar tidak mengirim atau menampilkan daftar pesan, tambahkan aturan permission deny yang mencantumkan SendMessage dan ListAgents. Keduanya harus ditulis sebagai nama tool tanpa specifier. Mengatur isolatePeerMachines ke true mengharuskan persetujuan eksplisit Anda sebelum pesan apa pun dikirim ke sesi di luar mesin ini. Persetujuan tersebut tetap diperlukan bahkan dalam mode bypassPermissions.

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

Menolak SendMessage juga menghapus kemampuan mengirim pesan ke subagent karena tool yang sama digunakan untuk keduanya. Sesi yang menolak tidak menampilkan perubahan pada /status miliknya atau pada daftar sesi lainnya. Karena itu, konfirmasikan pengaturan dari konfigurasi sesi, bukan dari tampilan layar.

Bridge dan server MCP dengan memori bersama

Beberapa proyek pihak ketiga muncul pada periode yang sama dengan fungsi yang berdekatan: bridge antaragen lokal yang meneruskan teks antara agen yang sedang berjalan, serta server MCP (model context protocol) yang menyediakan satu penyimpanan bersama untuk dibaca dan ditulisi oleh beberapa agen. Nilai keduanya sebagai bentuk yang berbeda, bukan sebagai pesaing, dan verifikasi setiap perintah instalasi terhadap README milik proyek tersebut sebelum menjalankannya. Pengiriman pesan bersifat push karena pengirim memasukkan teks ke giliran penerima. Penyimpanan bersama bersifat pull karena tidak ada sesi yang diinterupsi dan sebuah sesi melihat catatan tersebut saat memeriksanya nanti. Pull lebih tenang untuk status yang berubah secara perlahan, tetapi hanya berfungsi jika sebuah sesi benar-benar memeriksanya.

Jika memilih pendekatan tersebut, pertanyaan yang perlu diajukan berkaitan dengan proses, bukan daftar fitur. Sebagai user apa server berjalan, dan apa saja yang dapat dibacanya pada server. Menjalankan server MCP pada VPS membahas penyiapan tersebut. Berbagi skill agen antarrepo membahas kasus yang lebih sederhana ketika hal yang ingin dibagikan antar sesi adalah instruksi, bukan status aktif. Pendekatan ini juga menghilangkan banyak pesan yang seharusnya Anda kirim. Untuk gambaran yang lebih luas, menjalankan agen coding pada VPS adalah titik awalnya.

FAQ

Mengapa /list-agents tidak dikenali dalam 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, tetapi tidak pada Windows native. Fitur ini juga tidak tersedia di Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, dan Microsoft Foundry. Jika keduanya sesuai, periksa shell Anda untuk DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, atau DISABLE_GROWTHBOOK, karena masing-masing menonaktifkan evaluasi feature flag yang diperlukan fitur ini dan membuatnya tetap nonaktif.

Mengapa pesan saya ke sesi lain tidak pernah sampai?

Jika /list-agents berfungsi, fitur perpesanan aktif dan ada masalah yang lebih spesifik yang menghentikan pesan tersebut. Penyebab yang umum adalah mode izin. Sesi yang melewati prompt izin akan menahan setiap pesan masuk untuk persetujuan Anda, kecuali pengirim juga melewati prompt tersebut. Dialog persetujuan itu akan dibuang setelah batas waktu dialogExpiry, yang secara default adalah lima menit. Periksa sesi pengirim untuk melihat notifikasi bahwa pesan ditahan. Untuk memperbaikinya, tetapkan crossSessionInbound ke accept di ~/.claude/settings.json atau teruskan dengan --settings, karena nilai accept di pengaturan project atau lokal akan diabaikan sebagai nilai yang lebih longgar.

Dapatkah sesi Claude Code dalam Docker mengirim pesan ke sesi di host?

Tidak. Sesi saling menemukan melalui file registrasi pada disk dan socket inbox per sesi. Container memiliki filesystem sendiri, sehingga keduanya tidak dapat melihat file yang sama. Dua sesi 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 untuk pengguna sistem operasi yang memilikinya.

Apakah pesan dari sesi Claude Code lain aman untuk ditindaklanjuti?

Perlakukan teks tersebut sebagai input yang tidak tepercaya, karena sesi pengirim mungkin telah membaca halaman web, README, atau komentar issue yang ditulis orang lain. Claude Code sudah mencegah pesan tersebut bertindak sendiri: pesan itu tidak dapat menyetujui prompt izin yang tertunda, tidak dapat mengubah pengaturan izin atau CLAUDE.md atas permintaan, dan slash command di dalam teks diterima sebagai teks biasa serta tidak pernah dijalankan. Perlindungan tersebut mencakup izin, bukan penilaian. Karena itu, baca isi pesan yang diterima sebelum meminta sesi penerima menindaklanjutinya.

Apakah perpesanan lintas sesi mengirimkan kode saya ke Anthropic?

Tidak, jika dilakukan antara dua sesi pada mesin yang sama. Pesan dikirim melalui socket per sesi pada mesin tersebut dan tidak pernah melalui server Anthropic. Hanya teks yang ditulis Claude yang dikirim, bukan riwayat percakapan atau file. Pesan ke sesi pada mesin Anda yang lain atau ke sesi di web dikirim melalui server Anthropic menggunakan koneksi Remote Control. Dalam arah tersebut, Claude hanya dapat membalas pesan yang diterima dan tidak dapat memulai pesan. Tetapkan isolatePeerMachines ke true untuk mengharuskan persetujuan Anda sebelum apa pun meninggalkan mesin.