Claude Code oturumları arası mesajlaşma nasıl çalışır?

Claude Code oturumlarının birbirine mesaj göndermesi ne anlama gelir

İki Claude Code oturumu, aynı makinede ve aynı işletim sistemi kullanıcısı altında çalıştıklarında birbirlerine mesaj gönderebilir. Mesaj, bir Claude örneğinin diğeri için yazdığı düz metin parçasıdır. Bu mesaj herhangi bir konuşma geçmişi veya dosya içermez. Claude, diğer oturumu ListAgents aracıyla bulur ve metni SendMessage ile iletir; bu nedenle hiçbir aracı manuel olarak çağırmanız gerekmez. Diğer oturumun ne bilmesi gerektiğini söylersiniz ve Claude mesajı kendisi yazar.

Bu özellik, oturumlar arası mesajlaşma olarak adlandırılır. Ağustos 2026 itibarıyla Claude Code v2.1.224 veya sonraki bir sürümünü gerektirir ve WSL 2 içindeki Linux dahil olmak üzere macOS ve Linux üzerinde çalışır. Yerel Windows desteği yoktur; ayrıca Amazon Bedrock, AWS üzerindeki Claude Platform, Google Cloud Agent Platform veya Microsoft Foundry üzerinde kullanılamaz. Bir oturum bu gereksinimleri karşıladığında mesajlaşma zaten açıktır ve etkinleştirilecek bir ayar yoktur. Aşağıda açıklanan davranış, oturumlar arası mesajlaşma için Anthropic belgelerinden alınmıştır.

Bu durumun önemli olduğu yer bir VPS'tir, çünkü oturumların adreslenmeye değer olacak kadar uzun süre yaşadığı yer VPS'tir. Dizüstü bilgisayarda kapağı kapatırsınız. tmux altındaki bir sunucuda ise Pazartesi başlattığınız bir oturum Perşembe günü hala çalışıyor ve tek bir deponun bağlamını koruyor olabilir. Bunlardan iki tanesine sahip olduğunuzda, nasıl iletişim kurdukları teorik olmaktan çıkar. Henüz bu kurulumu yapmadıysanız, bu kılavuzun temel aldığı oturum altyapısını kapsayan tmux altında Claude Code çalıştırma rehberi ile başlayın.

İkinci bir oturumun maliyeti ne zaman karşıladığı

Maliyetle başlayın. Her oturum, kendi bağlam penceresine sahip ayrı bir Claude örneğidir; bu nedenle iki oturum, aynı süre zarfında bir oturumun maliyetinin yaklaşık iki katına mal olur. Gönderilen bir mesaj, yazdığınız bir istem gibi tam olarak kullanım kotanızdan düşer. Koordinasyon ücretsiz değildir ve aslında tek bir adım dizisi olan işler, oturumlara bölündüğünde daha yavaş ve daha maliyetli hale gelir.

İkinci bir oturumun kendini amorti ettiği durumlar tek bir ortak özelliğe sahiptir. İki iş parçası birbirini beklemeden aynı anda çalışır ve bunlardan biri, diğerinin görev ortasında ihtiyaç duyduğu bir bilgiyi edinir.

• Bir oturum kodda bozucu bir değişiklik (breaking change) bulurken, diğeri bu değişikliğin bozduğu kod üzerinde çalışmaya devam eder. Claude değişikliği özetler ve siz diğer terminale tekrar yazmak zorunda kalmadan bilgiyi iletir.
• İki oturum aynı depoda (repository) ayrı git çalışma ağaçlarında (worktrees) çalışır ve biri nelerin ana dala eklendiğini bilmek zorundadır.
• Uzun süren bir taşıma (migration) veya test süreci, sonucunu izlediğiniz oturuma geri bildirir.
• Bir oluşturucu (builder) oturumu ve bir gözden geçirici (reviewer) oturumu; gözden geçirici, oluşturucunun ürettiği içeriği okur ve bulgularını geri gönderir.

İş sıralı olduğunda veya her iki oturum da aynı dosyaları düzenleyecekse tek bir oturum kullanın. Claude'un tek bir görev içinde oluşturup denetlediği koordineli bir grup istiyorsanız, bu "ajan takımları" (agent teams) konusuna girer; bu ayrı ve henüz deneysel bir özelliktir. Yalnızca aynı konuşmayı başka bir terminalde istiyorsanız, oturumu kaldığı yerden devam ettirin. Oturumlar arası mesajlaşma, kendi başlattığınız ve yönettiğiniz bağımsız oturumlar içindir.

Planlama yapmadan önce özelliğin mevcut olduğunu doğrulayın

Öncelikle sürümü kontrol edin:

claude --version

Numarayı 2.1.224 ile karşılaştırın. Ardından, bir oturum içindeyken /list-agents komutunu yazın; bu komut /peers ile de çalışır. Bu komut, oturumun erişebildiği tüm aracıları ve her birinin yanıt verdiği ismi listeler. Komut tanınmıyorsa, bu oturumda oturumlar arası mesajlaşma özelliği yoktur ve hiçbir ayar dosyası bunu değiştiremez. /status yazın ve Peer address satırını arayın: bu satır, uds: ön ekiyle oturumun kendi gelen kutusu adresini tutar.

Bir tuzak özellikle VPS kullanıcılarını etkiler. Oturumlar arası mesajlaşma, özellik bayrağı değerlendirmesine bağlıdır ve çeşitli gizlilik değişkenleri bu değerlendirmeyi devre dışı bırakarak özelliğin varsayılan kapalı durumda kalmasına neden olur. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ve DISABLE_GROWTHBOOK değişkenlerinin tümü bunu yapar. Kullanıcılar, bunları ~/.bashrc dosyasına yapıştırarak yeni bir sunucuyu sıkılaştırır, ardından /list-agents neden yok diye merak ederler. Aynı değerler bir ayar dosyasındaki env haritasından veya yönetilen ayarlardan gelebilir, bu yüzden önce shell ortamını kontrol edin.

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

Çıktı veren değişkenin ayarını kaldırın. DISABLE_TELEMETRY ve CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC için, boş olmayan herhangi bir değer (0 dizgisi dahil) davranışı etkinleştirir; bu nedenle DISABLE_TELEMETRY=0 komutu göründüğü gibi çalışmaz. Özelliği kapatmak için değişkenin ayarını kaldırmanız veya değişkeni boş bir dizgiye eşitlemeniz gerekir.

Oturumlarınızı adlandırın, aksi takdirde Claude onlara hitap edemez

Claude, bir mesaja oturum adına göre hitap eder. Oturumu başlatırken adı şu şekilde ayarlayın:

claude --name builder-api

Ayrıca çalışan bir oturumun içindeyken /rename ile de ayarlayabilirsiniz. Hiçbir şey ayarlamadığınızda, Claude Code adı çalışma dizininin klasör adından türetir; örneğin myapp-3f gibi. Bu, tek bir oturum için uygundur ancak dört oturum olduğunda kafa karıştırıcı olabilir ve iki oturum aynı adla sonuçlanabilir. /list-agents çıktısı, her yerel oturumun çalışma dizinini gösterir; bu da aynı adlı oturumları birbirinden ayırmanızı sağlar. İsimler çakıştığında Claude'un kendi listeleme özelliği, adrese kısa bir tanımlayıcı ekler. Oturumları kendiniz adlandırmak, tanımlayıcıları okumaktan daha pratiktir.

Yeniden oluşturabileceğiniz iki oturumlu bir tmux düzeni

Bu düzen, aynı depo üzerinde çalışan bir geliştirici (builder) ve bir incelemeci (reviewer) oturumundan oluşur. İncelemeci ayrı bir git worktree içinde çalıştığından, iki oturum hiçbir zaman aynı dosyaya yazmaz. git worktree add ile birlikte HEAD kullanımı, commit atmak yerine okuma yapan bir oturum için ideal olan ayrık (detached) bir checkout sağlar.

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 ve ardından w komutları, pencereleri isme göre listeler, böylece birini seçebilirsiniz. Geliştirici penceresinde /list-agents komutunu çalıştırın. reviewer-api öğesini, çalışma dizini ~/src/api-review ile birlikte görmelisiniz. Eğer eksikse, incelemeci oturumu henüz başlatılmamıştır veya sonraki bölümde belirtilen iki sorundan biri yaşanıyordur. Ardından, basit bir dille bir aktarım gerçekleştirin:

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

Claude özeti yazar ve gönderir. Mesaj metnini siz yazmazsınız ve Claude'un gönderdiği içerik değişkenlik gösterir. İncelemeci penceresinde mesaj, gönderenin adıyla birlikte konuşma içinde görünür. Eğer o oturum boşta ise, Claude hemen yeni bir tur başlatır. Eğer bir işlem ortasındaysa, mesaj araç çağrıları arasına gelene kadar bekletilir; böylece çalışan bir komut asla kesintiye uğramaz. Claude mesajı okuduğunda, mesaj tek satırlık bir Message from satırına dönüşür ve bu satır Ctrl+O ile genişletilebilir. Bu ikili yapı, geliştirici değişiklikleri küçük tuttuğunda daha verimli çalışır; çünkü dar bir diff, daha kısa bir aktarım ve diğer oturumun tek turda bitirebileceği bir inceleme sağlar. Bu alışkanlık, tembel kıdemli yazılımcı becerisi ile zorunlu kılınmıştır.

Tek bir VPS üzerinde kimin kimi görebileceği

Aynı makine üzerindeki teslimat hiçbir zaman Anthropic sunucuları üzerinden geçmez. Her oturum, kayıt dosyalarını diske yazar ve kendi gelen kutusu soketini bağlar; Claude Code ise diğer oturumlarınızı bulmak için bu dosyaları okur. Bunun sonucunda iki durum ortaya çıkar ve her ikisi de sunucu üzerinde etkilidir.

Soket, işletim sistemi kullanıcınızla kısıtlanmıştır. root olarak başlattığınız bir oturum ile deploy olarak başlattığınız bir oturum, aynı tmux sunucusunda yan yana olsalar bile birbirlerini göremezler; çünkü bir kullanıcının oturumları diğer kullanıcının soketine erişemez. Her iki oturumu da aynı kullanıcı ile çalıştırın.

Bir container kendi dosya sistemine sahiptir. Docker içindeki bir oturum ile ana makine üzerindeki bir oturum, aynı kayıt dosyalarını okumadıkları için birbirlerine erişemezler. Aynı container içindeki iki oturum birbirine normal şekilde mesaj gönderebilir. Eğer ajanları izolasyon amacıyla container içinde tutuyorsanız, kodlama ajanlarını geçici bir VM içinde çalıştırma konusunda olduğu gibi, mesajlaşmanın container içinde çalışmasını ancak container sınırları arasında çalışmamasını beklemelisiniz.

Diğer makinelerdeki ve web üzerindeki oturumlarınız, yalnızca Remote Control bağlıyken listede görünür ve bu şekilde etiketlenirler. Buradaki Claude, yalnızca bu oturumlardan birinden gelen bir mesaja yanıt verebilir. Bu iletişimi kendisi başlatamaz.

Mesajınızın neden hiç ulaşmadığı

Genellikle bunun ağ ile bir ilgisi yoktur. Mesajı alan oturum, mesajla ne yapılacağına karar vermiş ve teslim etmemeyi seçmiştir. Gelen her mesaj üç sonuçtan biriyle biter: teslim edildi, bekletiliyor (siz onaylayana kadar teslim edilmeden kenara ayrıldı) veya reddedildi (teslim edilmeden bırakıldı).

Herhangi bir crossSessionInbound değeri geçerli olmadığında, Claude Code mesaj bazında iki oturumun izin modlarını karşılaştırarak karar verir. İzin istemlerini atlayan oturumları bir sınıfa, diğer tüm oturumları ise başka bir sınıfa gruplandırır. auto, acceptEdits ve dontAsk istemli olarak sayılır. Plan modu, atlama izinleri mevcut olan bir oturumda atlama olarak sayılır. Kural simetriktir:

• İzin isteminde bulunan bir alıcı oturum, her mesajı teslim alır. Yalnızca gönderen oturum kendisini istemleri atlayan olarak tanımladığında mesajı bekletir.
• İstemleri atlayan bir alıcı oturum, her mesajı onayınız için bekletir. Yalnızca gönderen de atlama yapıyorsa mesajı teslim eder.

Bu nedenle çoğu kişinin oluşturduğu ilk iş akışı, tam olarak çalışmayan iş akışıdır. Bir oluşturucuyu (builder) --permission-mode bypassPermissions ile başlatırsınız çünkü gözetimsiz çalışmasını istersiniz, inceleyiciyi (reviewer) varsayılanlarda bırakırsınız ve oluşturucunun gönderdiği her mesaj, kimsenin izlemediği bir onay iletişim kutusunda bekler. Bu iletişim kutusu dialogExpiry süresi dolduğunda kapanır (varsayılanı 5m'tir) ve mesaj bırakılır. Aynı makinede gönderen oturum, mesajı bekletildiğinde bir bildirim alır; alıcı daha sonra mesajı teslim ettiğinde, reddettiğinde veya süresi dolduğunda ise bir takip bildirimi alır. Bu yüzden soketi suçlamadan önce gönderenin ekranını okuyun.

Bir oturumun mesajları gözetimsiz almasını sağlamak için crossSessionInbound değerini accept olarak ayarlayın. Nerede ayarladığınız, geçerli olup olmayacağını belirler. Claude Code önce yönetilen ayarları, ardından --settings bayrağını, sonra kullanıcı ayarlarını okur ve bulduğu ilk değeri uygular. Proje veya yerel ayarlardaki bir değer, yalnızca daha katı olduğunda uygulanır; hiyerarşi accept < hold < refuse şeklindedir. .claude/settings.json içindeki bir accept, her şeyden daha gevşek olduğu için güvenilir bir kaynak bir değer belirlediğinde yok sayılır. Bunu ~/.claude/settings.json içine koyun veya tek bir oturum için iletin:

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

Başsız (headless) bir claude -p çalışanı, etkileşimli bir oturum gibi bir gelen kutusu soketine bağlanır ve listede görünür, ancak bir onay iletişim kutusu gösteremez. Orada bekletilen bir mesaj, daha sonraki bir mod veya ayar değişikliği izin verene kadar bekletilmiş kalır. Yukarıdaki --settings satırı, böyle bir çalışanın mesajları almasını sağlamanın yoludur. Bare modunda başlatılan bir oturum hiçbir sokete bağlanmaz, bu nedenle ne mesaj alabilir ne de listede görünebilir.

Aktarımın kilitlendiği durumlar

Mesaj döngüleri sizin yerinize yönetilir. Claude Code, gönderici başına tekrarlanan mesajları hız sınırına (rate-limit) tabi tutar, kısa bir süre içinde gelen aynı tekrarları reddeder ve okunmayı bekleyen kabul edilmiş mesajları oturum başına 50 ile sınırlar; böylece iki oturum sonsuza kadar birbirine ping-pong yapamaz. Bekletilen mesajlar 100 ile sınırlandırılmıştır ve bu sayıyı aşan en eski mesajlar silinir.

Gerçekleşen hata daha sessizdir ve bir döngüden ziyade bir aktarım sorunudur. A oturumu, devam edebilmesi için yanıt alması gereken bir soruyu B oturumuna sorar ve ardından boşta kalır. B mesajı bekletir, B uzun süren bir işlemin ortasındadır veya B, A'nın aslında sormadığı bir soruya yanıt verir. A bekler. Bir saat sonra geri döndüğünüzde iki boş oturumla karşılaşırsınız ve hiçbir iş yapılmamıştır.

Yanıt gerektirmeyen aktarımlar yazın. İyi bir mesaj bir olguyu veya kararı taşır: ne değişti ve sonuç ne oldu. Kötü bir mesaj diğer oturumdan izin ister veya göndericinin tıkandığı bir soruya yanıt bekler. Claude'a, kendi izin ayarlarının engelleyeceği bir eylemi başka bir oturumdan istememesi ve bu işi size yönlendirmesi konusunda zaten talimat verilmiştir. Bu kuralı kendiniz de genişletin. Bir oturum yanıt almadan ilerleyemiyorsa, yanıt vermesi gereken kişi sizsiniz. Bağlam disiplini de burada yardımcı olur; çünkü konuyu kaybeden bir oturum belirsiz mesajlar yazar; Claude Code içinde bağlam yönetimi bu konuyu ele almaktadır.

Gelen bir iletiyi güvenilmeyen girdi olarak değerlendirme

Claude Code, alıcı Claude'a iletinin sizden değil başka bir oturumdan geldiğini bildirir ve bu iletinin yapabileceklerini kısıtlar. Bir ileti, sizin adınıza bekleyen bir izin istemini yanıtlayamaz; çünkü başka bir oturumdan gelen onay, sizin onayınız değildir. Başka bir oturum talep ettiği için izin ayarlarını, CLAUDE.md veya diğer yapılandırmaları değiştiremez. Metin içindeki /compact gibi bir eğik çizgi komutu, düz metin olarak ulaşır ve asla yürütülmez. İleti üzerinde işlem yapmak, alıcı oturumun sahip olmadığı bir izin gerektiriyorsa, başka herhangi bir işlem için göreceğiniz istemin aynısını görürsünüz. Otomatik modda bir sınıflandırıcı, her iletiyi teslim edilmeden önce inceler; engellediği bir ileti asla alıcıya ulaşmaz. Bu sınırlar, izin verici modlarda dahi geçerliliğini korur; bu nedenle, gelen iletileri güvenli kabul etmek yerine varsayılan olarak bekleten bir oturum, bu kısıtlamaları devre dışı bırakmaz.

Bu durum izinleri kapsar ancak içeriği kapsamaz. Gönderen oturum; bir çekme isteği açıklaması, bir web sayfası, bir bağımlılık README dosyası veya bir yabancı tarafından yazılmış bir sorun yorumunu okumuş olabilir. Okuduğu her şey, diğer oturumunuza yazdığı metni şekillendirebilir. İleti veridir. Dışarıdan bir oturuma giren diğer tüm metinlerle aynı şüpheyi hak eder. Bu, yapay zeka aracılarınızdan sırları uzak tutma bölümünde açıklanan disiplindir: bir güven sınırını aşan her şeyin yanlış olabileceğini varsayın ve hiçbir şeyin kendi yetkilendirmesini yapmasına izin vermeyin.

Bunu daha az yaşamak isterseniz iki kontrol mevcuttur. crossSessionInbound değerini refuse olarak ayarlamak, gelen eş iletilerini teslim etmeden düşürür. Proje veya yerel ayarlardan gelen bu değer, hiyerarşideki en katı kural olduğu için diğer tüm kaynakların üzerinde uygulanır. Bu oturumun gönderim yapmasını veya listeleme yapmasını durdurmak için, herhangi bir belirleyici içermeyen yalın araç adları olarak yazılmış SendMessage ve ListAgents değerlerini içeren izin reddetme kuralları ekleyin. isolatePeerMachines değerini true olarak ayarlamak, herhangi bir ileti bu makinenin ötesindeki bir oturuma ulaşmadan önce açık onayınızı gerektirir; bu onay, bypassPermissions modunda bile zorunludur.

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

SendMessage iznini reddetmek, aynı araç her iki işlem için de kullanıldığından alt aracılara mesaj gönderimini de kaldırır. Reddeden bir oturum, kendi /status kısmında veya diğer oturumların listelerinde görünür bir değişiklik göstermez; bu nedenle ayarı ekrandan değil, oturumun yapılandırmasından doğrulayın.

Köprüler ve paylaşımlı bellek MCP sunucuları

Aynı dönemde benzer işlevlere sahip birkaç üçüncü taraf proje ortaya çıkmıştır: çalışan ajanlar arasında metin aktarımı yapan yerel ajan-ajan köprüleri ve birden fazla ajana okuma/yazma için ortak bir depolama alanı sunan MCP (model context protocol) sunucuları. Bunları birer rakip olarak değil, farklı bir yapı olarak değerlendirin ve herhangi bir kurulum komutunu çalıştırmadan önce projenin kendi README dosyasından doğrulayın. Mesajlaşma "push" (itme) tabanlıdır; çünkü gönderici, metni alıcının sırasına yerleştirir. Paylaşımlı depolama ise "pull" (çekme) tabanlıdır; çünkü kimsenin işi kesintiye uğramaz ve oturum, nota bir sonraki bakışında erişir. "Pull" yöntemi, yavaş değişen durumlar için daha kararlıdır ve yalnızca oturum aktif olarak kontrol ettiğinde çalışır.

Bu yolu tercih ederseniz, sorulması gereken sorular özellik listesinden ziyade süreçle ilgilidir. Sunucu hangi kullanıcı yetkisiyle çalışıyor ve sistem üzerinde nelere erişebiliyor? VPS üzerinde MCP sunucuları çalıştırma bu kurulumu ele alır. Ajan yeteneklerini depolar arasında paylaşma, oturumlar arasında canlı durum yerine talimatları paylaşmak istediğiniz daha basit durumları kapsar ve aksi takdirde göndermeniz gerekecek birçok mesajı ortadan kaldırır. Daha geniş bir perspektif için VPS üzerinde kodlama ajanı çalıştırma başlangıç noktasıdır.

FAQ

/list-agents komutu oturumumda neden tanınmıyor?

Oturum, oturumlar arası mesajlaşma özelliğine sahip değildir. Bu özellik 2.1.224 veya daha yeni bir sürüm gerektirdiğinden, öncelikle claude --version değerini bu sürümle karşılaştırın. Ardından platformu kontrol edin; özellik macOS ve Linux üzerinde çalışır, yerel Windows üzerinde çalışmaz. Ayrıca Amazon Bedrock, AWS üzerindeki Claude Platform, Google Cloud Agent Platform ve Microsoft Foundry üzerinde kullanılamaz. Her iki durum da uygunsa, kabuğunuzda DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC veya DISABLE_GROWTHBOOK tanımlı olup olmadığını kontrol edin; bunların her biri, özelliğin bağlı olduğu özellik bayrağı değerlendirmesini engeller ve özelliği devre dışı bırakır.

Diğer oturuma gönderdiğim mesaj neden hiç ulaşmadı?

Eğer /list-agents çalışıyorsa mesajlaşma açıktır ve mesajı daha dar kapsamlı bir sorun engellemiştir. Yaygın neden izin modlarıdır. İzin istemlerini atlayan bir oturum, gönderen taraf da atlamadığı sürece gelen her mesajı onayınız için bekletir ve bu onay diyaloğu, varsayılan olarak beş dakika olan dialogExpiry süresi dolduğunda düşer. Gönderen oturumda bekletme bildirimini kontrol edin. Sorunu çözmek için ~/.claude/settings.json dosyasında crossSessionInbound değerini accept olarak ayarlayın veya --settings ile geçirin; çünkü proje veya yerel ayarlardaki bir accept, daha gevşek bir değer olduğu için göz ardı edilir.

Docker içindeki bir Claude Code oturumu, ana makinedeki bir oturuma mesaj gönderebilir mi?

Hayır. Oturumlar birbirlerini disk üzerindeki kayıt dosyaları ve oturum başına düşen bir gelen kutusu soketi aracılığıyla bulur. Bir container kendi dosya sistemine sahip olduğundan, iki oturum aynı dosyaları göremez. Aynı container içindeki iki oturum birbirine normal şekilde mesaj gönderebilir. Aynı kural, root olarak çalışan bir oturum ile normal kullanıcı olarak çalışan bir oturumun neden birbirine ulaşamadığını da açıklar: soket, yalnızca ona sahip olan işletim sistemi kullanıcısı ile sınırlandırılmıştır.

Başka bir Claude Code oturumundan gelen bir mesaja göre hareket etmek güvenli mi?

Metni güvenilmeyen girdi olarak değerlendirin; çünkü gönderen oturum bir web sayfasını, bir README dosyasını veya başka biri tarafından yazılmış bir sorun yorumunu okumuş olabilir. Claude Code, mesajın kendi başına işlem yapmasını zaten engeller: bekleyen bir izin istemini onaylayamaz, izin ayarlarını veya CLAUDE.md değerini istek üzerine değiştiremez ve metin içindeki bir eğik çizgi komutu düz metin olarak ulaşır ve asla çalıştırılmaz. Bu korumalar izinleri kapsar ancak yargıyı kapsamaz; bu nedenle, alıcı oturuma işlem yapmasını söylemeden önce gelen metni okuyun.

Oturumlar arası mesajlaşma kodumu Anthropic'e gönderiyor mu?

Aynı makinedeki iki oturum arasında hayır. Mesaj, o makinedeki oturum başına bir soket üzerinden iletilir ve asla Anthropic sunucularından geçmez; ayrıca yalnızca Claude'un yazdığı metin gönderilir, konuşma geçmişi veya dosyalar asla gönderilmez. Başka bir makinenizdeki veya web üzerindeki bir oturuma gönderilen mesajlar, Uzaktan Kontrol bağlantısı üzerinden Anthropic sunucularından geçer. Bu yönde Claude, yalnızca gelen bir mesaja yanıt verebilir, kendisi bir mesaj başlatamaz. Makineden herhangi bir şey çıkmadan önce onayınızı gerektirmek için isolatePeerMachines değerini true olarak ayarlayın.