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

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

İki Claude Code oturumu aynı makinede ve aynı işletim sistemi kullanıcısı altında çalışıyorsa birbirlerine mesaj gönderebilir. Mesaj, bir Claude oturumunun diğeri için yazdığı tek bir düz metin parçasıdır. Mesajda konuşma geçmişi veya dosya bulunmaz. Claude, diğer oturumu ListAgents aracıyla bulur ve metni SendMessage ile iletir; bu nedenle bu araçlardan hiçbirini elle çağırmanız gerekmez. Diğer oturumun ne bilmesi gerektiğini belirtirsiniz; mesajı Claude kendisi yazar.

Bu özellik cross-session messaging olarak adlandırılır. Ekim 2026 itibarıyla macOS ve Linux üzerinde, WSL 2 içindeki Linux dahil, Claude Code v2.1.224 veya sonraki bir sürüm gerekir. Native Windows üzerinde ise v2.1.234 veya sonraki bir sürüm gerekir. Aynı makinedeki oturumlar arasında mesajlaşma, Amazon Bedrock, AWS üzerindeki Claude Platform, Google Cloud's Agent Platform ve Microsoft Foundry dahil olmak üzere tüm sağlayıcılarda çalışır. Bu dört sağlayıcıda v2.1.248 veya sonraki bir sürüm gerekir. Diğer makinelerdeki veya buluttaki oturumlara erişim daha sınırlıdır: Bu işlem, claude.ai oturum açma gerektiren Remote Control üzerinden yapılır. Bu nedenle API key ile veya söz konusu dört sağlayıcıda çalışmaz. Bir oturum bu gereksinimleri karşılıyorsa mesajlaşma zaten açıktır; etkinleştirmek için başka bir işlem gerekmez. Aşağıda açıklanan davranış, cross-session messaging için Anthropic belgelerine dayanmaktadır.

Bu özellik özellikle VPS üzerinde önem kazanır; çünkü oturumlar, kendilerine mesaj gönderilmeye değer olacak kadar uzun süre burada çalışır. Bir dizüstü bilgisayarda kapağı kapatırsınız. tmux altında çalışan bir sunucuda ise pazartesi günü başlattığınız oturum perşembe günü hâlâ çalışıyor olabilir ve bir repository'nin bağlamını koruyabilir. Bu oturumlardan iki tane olduğunda birbirleriyle nasıl iletişim kuracakları teorik bir konu olmaktan çıkar. Henüz bu kurulumu yapmadıysanız, bu kılavuzun varsaydığı oturum altyapısını açıklayan tmux altında bir VPS üzerinde Claude Code çalıştırma bölümünden 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, tıpkı yazdığınız bir istem gibi kullanım kotanızdan düşer. Koordinasyon ücretsiz değildir; aslında tek bir adım dizisi olan işler, oturumlara bölündüğünde yavaşlar ve daha maliyetli hale gelir.

İkinci bir oturumun kendini amorti ettiği durumlar ortak bir yapıya sahiptir. İki iş parçası birbirini beklemeden aynı anda yürütülür ve bunlardan biri, görev esnasında diğerinin ihtiyaç duyduğu bir bilgiyi edinir.

• Bir oturum, diğeri bozulan kod üzerinde çalışırken bir "breaking change" (kırılgan değişiklik) tespit eder. Claude değişikliği özetler ve onu diğer terminale yeniden yazmanız yerine doğrudan gönderir.
• İki oturum, ayrı git worktree yapıları içinde aynı depo üzerinde çalışır ve birinin neyin ana dala eklendiğini bilmesi gerekir.
• Uzun süren bir taşıma işlemi veya test çalışması, sonucunu izlediğiniz oturuma geri bildirir.
• Bir oluşturucu oturum ve bir gözden geçirici oturum; gözden geçirici, oluşturucunun ürettiğini 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 "agent teams" (temsilci ekipleri) özelliğidir ve henüz deneysel bir aşamadadır. Yalnızca aynı konuşmayı başka bir terminalde istiyorsanız, oturumu devam ettirin. Oturumlar arası mesajlaşma, kendi başlattığınız ve yönettiğiniz bağımsız oturumlar içindir.

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

Önce sürümü kontrol edin:

claude --version

Numarayı 2.1.224 ile karşılaştırın. Ardından bir oturum içinde /list-agents yazın; bu komut /peers adıyla da çalışır. Komut, bu oturumun erişebildiği tüm agent'ları ve her birinin yanıt verdiği adı listeler. Komut hiç tanınmıyorsa bu oturumda oturumlar arası mesajlaşma yoktur ve hiçbir crossSessionInbound değeri bunu etkinleştiremez. /status yazın ve Peer address satırını bulun. Bu satır, uds: ile başlayan, bu oturumun kendi gelen kutusu adresini içerir.

Eski sürümleri kullanan VPS kullanıcıları için bir sorun vardır. v2.1.248 öncesinde aynı makinedeki mesajlaşma, feature flag değerlerinin alınmasına bağlıydı. Bazı privacy değişkenleri bu veri alımını devre dışı bıraktığından özellik varsayılan olarak kapalı kalıyordu. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ve DISABLE_GROWTHBOOK değişkenlerinin tümü bunu yapar. Kullanıcılar yeni bir sunucuyu sıkılaştırmak için bu değişkenleri ~/.bashrc içine yapıştırır, ardından /list-agents değerinin neden mevcut olmadığını anlamaya çalışır. v2.1.248 sürümünden itibaren aynı makinedeki oturumlar arası mesajlaşma, veri alımı kapalıyken de çalışır. Bu nedenle güncelleme daha temiz çözümdür. Bu değişkenler, bu makinenin dışındaki oturumlar için hâlâ önemlidir. Veri alımı kapalıyken Claude bu oturumlara yalnızca Remote Control kullanılabilir durumdaysa erişebilir. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC ve DISABLE_GROWTHBOOK ise Remote Control'u kullanılamaz hale getirir. Aynı değerler bir settings dosyasındaki env map'inden veya managed settings üzerinden de gelebilir. Bu nedenle önce shell ortamını kontrol edin.

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

Eski bir sürüm kullanılıyorsa, çıktı veren ilgili değişkeni kaldırın. DISABLE_TELEMETRY ve CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC için boş olmayan herhangi bir değer, 0 dizesi dahil olmak üzere davranışı etkinleştirir. Bu nedenle DISABLE_TELEMETRY=0 göründüğü gibi çalışmaz. Özelliği kapatmak için değişkeni kaldırın veya boş bir dizeye ayarlayın.

Oturumlarınızı adlandırın; aksi halde Claude bunlara hitap edemez

Claude, bir mesaja oturum adıyla hitap eder. Oturumu başlatırken adı belirleyin:

claude --name builder-api

Çalışan bir oturumun içinde /rename kullanarak da ad belirleyebilirsiniz. Herhangi bir ad belirlemezseniz Claude Code, myapp-3f gibi çalışma dizininin klasör adından bir ad türetir. Bu, tek oturum için uygundur; ancak dört oturumda karmaşaya neden olur ve iki oturum aynı ada sahip olabilir. Oturum Remote Control'a bağlı değilse /list-agents çıktısında her yerel oturumun çalışma dizini gösterilir. Bu bilgi, aynı ada sahip oturumları ayırt etmeyi sağlar. Claude'un kendi listesinde de adlar çakıştığında adrese kısa bir tanımlayıcı eklenir. Tanımlayıcıları okumak yerine oturumları kendiniz adlandırmak daha pratiktir. Seçtiğiniz ad, @ typeahead özelliğini de kullanışlı hale getirir: v2.1.232 sürümünden itibaren bir istemde @builder yazıp oturumu seçtiğinizde Claude hangi oturumu kastettiğinizi kesin olarak anlar.

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

Bu, tek bir repository üzerindeki builder oturumu ve reviewer oturumudur. Reviewer ayrı bir git worktree içinde çalışır; bu nedenle iki oturum hiçbir zaman aynı dosyaya yazmaz. git worktree add ile HEAD birlikte kullanıldığında detached checkout elde edilir. Commit yerine okuma yapan bir oturum için gereken yapı budur. İki oturum farklı işler yaptığı için reviewer oturumuna kendine ait bir çıktı stili vermek yararlıdır. Bu işlem, söz konusu oturumun system prompt değerini değiştirir ve bir kez yazılan talimat gibi etkisini kaybetmek yerine her turda geçerli olur.

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 adlarına göre listeler. Böylece istediğiniz pencereyi seçebilirsiniz. Builder penceresinde /list-agents komutunu çalıştırın. Çalışma dizini ~/src/api-review olan reviewer-api değerini görmeniz gerekir. Bu değer yoksa reviewer oturumu başlatılmayı henüz tamamlamamıştır veya sonraki bölümde açıklanan iki sorundan biri geçerlidir. Ardından düz bir dille bir aktarım yapın:

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; Claude'un gönderdiği içerik değişebilir. Reviewer penceresinde mesaj, gönderenin adını ve metnin ilk satırını içeren soluk, tek satırlık bir önizleme olarak görünür; örneğin › Message from @builder-api: …. Bu oturum boşta ise Claude hemen yeni bir tur başlatır. Oturum bir turu yürütüyorsa mesaj, tool call işlemleri arasındaki noktaya kadar bekler; bu nedenle çalışan bir komut hiçbir zaman kesilmez. Ctrl+O komutu, tam metnin bulunduğu transcript viewer görünümünü açar. Claude, mesajı genişletseniz de genişletmeseniz de tamamını okur. Builder değişiklikleri küçük tuttuğunda bu ikili daha verimli çalışır. Dar bir diff, daha kısa bir aktarım ve diğer oturumun tek turda tamamlayabileceği bir review sağlar. lazy senior dev skill alışkanlığının amacı da budur.

Tek VPS üzerinde kim kime ulaşabilir

Aynı makine içindeki iletim Anthropic sunucularından geçmez. Her oturum kendi gelen ileti soketine bağlanır. Bu soket, ilgili makinenin dosya sisteminde bir yolu bulunan Unix domain socket'tir. Bir oturum, diğer oturumların listelerinde yalnızca böyle bir sokete bağlandığında görünür. Bunun sunucuda iki sonucu vardır ve her ikisi de sorun oluşturabilir.

Soket, işletim sistemi kullanıcınızla sınırlandırılmıştır. root olarak başlattığınız bir oturum ile deploy olarak başlattığınız bir oturum, aynı tmux sunucusunda yan yana çalışsalar bile birbirlerini göremez. Bunun nedeni, bir kullanıcının oturumlarının başka bir kullanıcının soketine erişememesidir. Her iki oturum da aynı kullanıcıyla çalıştırılmalıdır.

Bir container'ın kendine ait bir dosya sistemi vardır. Docker içindeki bir oturum ile host üzerindeki bir oturum birbirine ulaşamaz. Aynı container içindeki iki oturum normal şekilde birbirine mesaj gönderebilir. Ajanları izolasyon amacıyla container'larda tutuyorsanız, örneğin kodlama ajanlarını geçici bir VM'de çalıştırma senaryosunda olduğu gibi, mesajlaşmanın container içinde çalışmasını, ancak container sınırını aşmamasını bekleyin.

Diğer makinelerdeki oturumlarınız ve cloud oturumlarınız, yalnızca bu oturum Remote Control'a bağlıyken listede görünür. Diğer makinelerdeki oturumlar Remote Control etiketiyle gösterilir. v2.1.225 sürümünden itibaren Claude, bu oturumlarla yalnızca yanıt vermekle kalmaz; bunlardan biriyle konuşma da başlatabilir. Bu mesajlar Anthropic sunucuları üzerinden iletilir. Claude makine dışına mesaj gönderirken bu oturum Remote Control'a bağlı değilse mesaj yine gönderilir, ancak yanıt adresi olmadan gönderildiği için karşı taraf yanıt veremez.

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

Bunun olağan nedeni ağ ile ilgili değildir. Alıcı oturum, iletiyle ne yapılacağına karar vermiştir ve bu karar iletiyi teslim etmemek olmuştur. Gelen her ileti üç sonuçtan biriyle sonlanır: teslim edilir, beklemeye alınır (onay verilene kadar teslim edilmeden ayrı tutulur) veya reddedilir (teslim edilmeden atılır).

crossSessionInbound değeri uygulanmadığında Claude Code, iki oturumun izin modlarını karşılaştırarak her mesaj için karar verir. İzin istemlerini atlayan oturumları bir sınıfta, diğer tüm oturumları ise diğer sınıfta toplar. auto, acceptEdits ve dontAsk istem gerektiren modlar olarak değerlendirilir. Plan modu, bypass izinlerinin kullanılabildiği etkileşimli bir terminal oturumunda izin istemlerini atlayan mod olarak değerlendirilir. Bir oturumun hangi sınıfa girdiğinden emin olunamıyorsa önce her izin modunun gerçekte ne yaptığı okunmalıdır. Çünkü oturumların çoğu artık auto modunda başlar ve bu mod söz konusu ayrımda istem gerektiren tarafta yer alır. Kural daha sonra simetrik olarak uygulanır:

• İzin isteyen bir alıcı oturumuna her mesaj teslim edilir. Alıcı oturum, yalnızca gönderici oturum kendisini izin istemlerini atlıyor olarak tanımladığında bir mesajı bekletir.
• İzin istemlerini atlayan bir alıcı oturum, onayınız için her mesajı bekletir. Yalnızca gönderici de izin istemlerini atlıyorsa bir mesajı teslim eder.

Bu nedenle çoğu kişinin oluşturduğu ilk iş akışı, çalışmayan iş akışının aynısıdır. Builder'ı gözetimsiz çalıştırmak istediğiniz için --permission-mode bypassPermissions ile başlatırsınız, reviewer'ı varsayılan ayarlarla bırakırsınız ve builder'ın gönderdiği her mesaj, kimsenin izlemediği bir onay iletişim kutusunda bekler. Bu iletişim kutusu dialogExpiry süresinin sonunda kapanır; bu süre varsayılan olarak 5m değerindedir ve mesaj bırakılır. Socket sorununu sorumlu tutmadan önce alıcı oturumunun ekranında bekleyen bir onay iletişim kutusu olup olmadığını kontrol edin.

Bir oturumun iletileri kullanıcı müdahalesi olmadan işlemesini sağlamak için crossSessionInbound değerini accept olarak ayarlayın. Ayarı nereye yaptığınız, hangi kapsamda uygulanacağını belirler. Claude Code önce yönetilen ayarları, ardından --settings bayrağını ve son olarak kullanıcı ayarlarını okur; bulduğu ilk değeri uygular. Proje veya yerel ayarlardaki bir değer yalnızca accept < hold < refuse sıralamasında daha kısıtlayıcıysa uygulanır. .claude/settings.json içindeki bir accept her değerden daha gevşektir. Bu nedenle güvenilir bir kaynak bir değer ayarladığında yok sayılır. Değeri ~/.claude/settings.json içine ekleyin veya yalnızca bir oturum için iletin. v2.1.232 sürümünden itibaren Diğer oturumlarınızdan gelen iletiler adlı /config satırı aynı kullanıcı ayarını sizin için yazar.

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

Headless claude -p worker, etkileşimli bir oturum gibi bir inbox socket bağlar ve listede görünür; ancak approval dialog gösteremez. Claude Code, aynı dialogExpiry son tarihine kadar, varsayılan olarak five minutes, burada bir mesajı bekletir. Mode veya settings değişikliği bu süre içinde mesaja izin verirse mesajı teslim eder. Aksi durumda mesajı siler ve ulaşabildiği bir sender'a süresinin dolduğunu bildirir. Yukarıdaki --settings satırı, böyle bir worker'ın mesaj almasını sağlar. Bare mode ile başlatılan session hiçbir socket bağlamaz; bu nedenle mesaj alamaz ve listede görünmez.

Hand-off işlemlerinin kilitlendiği durumlar

Mesaj döngüleri sizin için yönetilir. Claude Code, gönderen başına tekrarlanan mesajları rate limit uygular, kısa bir zaman aralığında gelen aynı tekrarları yok sayar ve oturum başına okunmayı bekleyen kabul edilmiş mesaj sayısını 50 ile sınırlar. Böylece iki oturum sonsuza kadar karşılıklı mesaj gönderemez. Bekletilen mesaj sayısı 100 ile sınırlıdır; bu sayı aşıldığında en eski mesajlar silinir. v2.1.238 sürümünden itibaren, alıcının inbox'ından bir mesaj silindiğinde gönderen oturuma neden bilgisi bildirilir. Aynı oturumlardan tekrar tekrar geçen relay chain de kesilir.

Gerçekte oluşan hata daha sessizdir ve bir döngüden çok hand-off işlemidir. Session A, devam etmeden önce yanıtlaması gereken bir soruyu session B'ye gönderir ve ardından idle durumuna geçer. B mesajı bekletir, uzun süren bir işlem üzerinde çalışıyor olabilir veya A'nın aslında sormadığı bir soruyu yanıtlayabilir. A bekler. Bir saat sonra geri döndüğünüzde iki idle oturum ve tamamlanmamış işler bulursunuz.

Yanıt gerektirmeyen hand-off mesajları yazın. İyi bir mesaj bir olguyu veya kararı aktarır: ne değişti ve sonuç ne oldu. Kötü bir mesaj diğer oturumdan izin veya gönderenin ilerlemesini engelleyen bir yanıt ister. Claude'a zaten, kendi permission ayarlarının engelleyeceği bir işlem için başka bir oturumdan istekte bulunmaması ve bu işi size yönlendirmesi talimatı verilmiştir. Bu kuralı kendiniz de genişletin. Bir oturum bir yanıt olmadan ilerleyemiyorsa yanıtı vermesi gereken kişi sizsiniz. Context disiplini de burada yardımcı olur; çünkü bağlamı kaybeden bir oturum belirsiz mesajlar yazar. Claude Code'da context yönetimi bu konuyu ele alır.

Gelen bir ileti güvenilmeyen girdi olarak ele alınmalıdır

Claude Code, iletiyi alan Claude'a iletinin sizden değil, başka bir oturumdan geldiğini bildirir ve bu iletinin yapabileceklerini sınırlar. Bu uygulama, modelin uyum gösterme isteğinden ziyade modelin etrafında çalışan programda uygulanır; bir agent harness işlevinin pratik farkı budur. Başka bir oturumdan gelen onay, sizin onayınız olmadığı için bir ileti sizin adınıza bekleyen bir izin istemini yanıtlayamaz. Başka bir oturum istedi diye izin ayarlarını, CLAUDE.md değerini veya diğer yapılandırmaları değiştiremez. Metin içinde bulunan /compact gibi bir slash komutu düz metin olarak gelir ve hiçbir zaman çalıştırılmaz. İleti üzerinde işlem yapmak için alıcı oturumda bulunmayan bir izin gerekiyorsa, diğer işlemlerde gördüğünüz istemin aynısı görüntülenir. Gönderen oturum auto mode ile çalışırken sınıflandırıcısı da her iletiyi Claude Code iletmeden önce inceler ve engellediği bir ileti alıcıya hiçbir zaman ulaşmaz. Bu sınırlar izinleri genişleten modlarda da geçerliliğini korur. Bu nedenle bypass uygulayan bir oturum, gelen iletilere varsayılan olarak güvenmek yerine onları bekletir.

Bu, izinleri kapsar. Ancak içeriği kapsamaz. Gönderen oturum bir pull request açıklamasını, web sayfasını, bağımlılık README dosyasını veya bir yabancı tarafından yazılmış issue yorumunu okumuş olabilir. Okunan her içerik, diğer oturumunuza yazdığı metni şekillendirebilir. İleti veridir. Oturumun dışından gelen diğer metinler gibi ona da şüpheyle yaklaşılmalıdır. Yapay zeka agent'larınızdan gizli bilgileri uzak tutma bölümünde açıklanan yaklaşım budur: bir güven sınırını geçen her şeyin yanlış olabileceği varsayılmalı ve hiçbir içeriğin kendisine yetki vermesine izin verilmemelidir.

Bu davranışı azaltmak için iki denetim kullanılabilir. crossSessionInbound değerinin refuse olarak ayarlanması, gelen peer iletilerini teslim etmeden düşürür. Bu değer proje veya yerel ayarlardan belirlendiğinde diğer tüm kaynaklara üstün gelir; çünkü basamaklandırmadaki en katı değerdir. Bu oturumun ileti göndermesini veya iletileri listelemesini durdurmak için SendMessage ve ListAgents adlarını belirten permission deny kuralları eklenmelidir. Her ikisi de specifier içermeyen yalın tool adları olarak yazılmalıdır. isolatePeerMachines değerinin true olarak ayarlanması, herhangi bir iletinin bu makinenin dışındaki bir oturuma ulaşmasından önce açık onayınızı gerektirir. Bu onay bypassPermissions mode içinde bile gereklidir.

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

SendMessage için deny kuralı eklenmesi, aynı tool her ikisi için de kullanıldığından subagent'lara ileti gönderilmesini de kaldırır. İletileri reddeden bir oturumun kendi /status değerinde veya diğer oturumların listelerinde görünür bir değişiklik olmaz. Bu nedenle ayar, ekrandan değil oturumun yapılandırmasından doğrulanmalıdır.

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 aracılar arasında metin aktarımı yapan yerel aracıdan aracıya köprüler ve birden fazla aracıya okuma/yazma için tek bir paylaşımlı depo sunan MCP (model context protocol) sunucuları. Bunları bir rakip olarak değil, farklı bir yapı olarak değerlendirin ve herhangi bir kurulum komutunu çalıştırmadan önce projenin kendi README dosyası ile 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ı depo ise "pull" (çekme) tabanlıdır; çünkü kimsenin süreci kesintiye uğratılmaz 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ı yetkileriyle çalışıyor ve sistem üzerinde neleri okuyabiliyor? VPS üzerinde MCP sunucuları çalıştırma bu kurulumu ele almaktadır. Aracı yeteneklerini depolar arasında paylaşma, oturumlar arasında canlı durum yerine talimatları paylaşmak istediğiniz daha basit senaryoları kapsar ve aksi takdirde göndermeniz gerekecek birçok mesajı ortadan kaldırır. Daha geniş bir perspektif için VPS üzerinde kodlama aracısı çalıştırma başlangıç noktasıdır.

FAQ

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

Oturumda oturumlar arası mesajlaşma etkin değil. Önce claude --version değerini kontrol edin: Bu özellik macOS ve Linux üzerinde 2.1.224 veya sonraki sürümleri, yerel Windows üzerinde 2.1.234 veya sonraki sürümleri ve Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform ile Microsoft Foundry üzerinde 2.1.248 veya sonraki sürümleri gerektirir. 2.1.248 sürümünden eski bir build kullanılıyorsa shell içinde DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC veya DISABLE_GROWTHBOOK değerlerini de kontrol edin. Çünkü bu seçeneklerin her biri, eski build'lerin mesajlaşma için ihtiyaç duyduğu feature flag alma işlemini devre dışı bırakır. 2.1.248 veya sonraki bir sürüme güncelleme yapıldığında aynı makinedeki oturumlar için bu bağımlılık ortadan kalkar.

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

/list-agents çalışıyorsa mesajlaşma etkindir ve yalnızca bu mesajı etkileyen daha dar kapsamlı bir sorun vardır. Yaygın neden permission mode ayarlarıdır. Permission prompt'larını atlayan bir oturum, gönderen oturum da aynı şekilde davranmadığı sürece gelen her mesajı onayınız için bekletir. Bu onay iletişim kutusu dialogExpiry süresinden sonra silinir; varsayılan süre beş dakikadır. Alıcı oturumda bekleyen bir onay iletişim kutusu olup olmadığını kontrol edin. Sorunu düzeltmek için ~/.claude/settings.json içinde crossSessionInbound değerini accept olarak ayarlayın veya bunu --settings ile aktarın. Çünkü proje veya yerel ayarlardaki bir accept, daha gevşek değer olduğu için yok sayılır.

Docker içindeki bir Claude Code oturumu, host üzerindeki bir oturuma mesaj gönderebilir mi?

Hayır. Her oturumun gelen kutusu, o makinenin dosya sistemindeki bir socket'tir. Container'ın kendine ait bir dosya sistemi olduğu için container içindeki bir oturum ile host üzerindeki bir oturum birbirine ulaşamaz. Aynı container içindeki iki oturum normal şekilde mesajlaşabilir. Benzer kural, root olarak çalışan bir oturum ile normal kullanıcınız olarak çalışan bir oturumun neden birbirine ulaşamadığını da açıklar: socket, onu sahiplenen işletim sistemi kullanıcısıyla sınırlandırılmıştır.

Başka bir Claude Code oturumundan gelen mesaja göre işlem yapmak güvenli midir?

Metni güvenilmeyen girdi olarak değerlendirin. Çünkü gönderen oturum bir web sayfası, README veya başka biri tarafından yazılmış bir issue comment okumuş olabilir. Claude Code, mesajın kendi başına işlem yapmasını zaten engeller: bekleyen bir permission prompt'unu onaylayamaz, istek üzerine permission ayarlarını veya CLAUDE.md değerini değiştiremez ve metindeki slash command düz metin olarak gelir, hiçbir zaman çalıştırılmaz. Bu korumalar permission işlemlerini kapsar, ancak muhakemeyi kapsamaz. Bu nedenle alıcı oturuma işlem yapmasını söylemeden önce gelen içeriği okuyun.

Oturumlar arası mesajlaşma kodumu Anthropic'e gönderir mi?

Aynı makinedeki iki oturum arasında hayır. Mesaj, o makinedeki oturuma özel bir socket üzerinden iletilir ve Anthropic sunucularından geçmez. Ayrıca yalnızca Claude'un yazdığı metin gönderilir; konuşma geçmişi veya dosyalar gönderilmez. Makinelerinizden birindeki oturuma ya da bir cloud oturumuna gönderilen mesajlar Anthropic sunucularından geçer. v2.1.225 sürümünden itibaren Claude bu iletişimi başlatabilir ve yanıtlama da yapabilir. Makineden herhangi bir verinin çıkması öncesinde onayınızın istenmesi için isolatePeerMachines değerini true olarak ayarlayın.