Claude Code oturumlar arası mesajlaşma eşzamanlı dosya üzerine yazmayı engellemiyor

Mesajlaşma özelliği gerçekte ne yapıyor

dev.to'da yazan bir geliştirici, aynı depoya karşı iki Claude Code oturumu çalıştırıp yerleşik koordinasyonun beklenenden daha dar bir sorunu çözdüğünü fark ettiğini anlatıyor. Claude Code, oturumlar arası mesajlaşmayla geliyor: Anthropic'in dokümantasyonuna göre bir oturum, yaptığı bir değişikliğin diğerinin bağımlı olduğu bir şeyi bozduğunu bildirebilir ya da bir soruyu yanıtlayarak akranının önünü açabilir. Bunu iki araç destekliyor — erişilebilir oturumları görmek için ListAgents ve isimle bir oturuma hitap etmek için SendMessage. /list-agents komutu (/peers olarak da geçer) bir oturumun kimlerle iletişim kurabileceğini gösterir. Herhangi bir şeyin açılması gerekmiyor ama bir sürüm tabanı var: macOS, Linux ve WSL 2'de 2.1.224 veya üzeri, native Windows'ta 2.1.234 veya üzeri. Daha eski sürümler komutu hiç tanımıyor.

Koordinasyon bir kilit değil

Aynı dokümantasyona göre temel sınırlama şu: Bir mesaj, yalnızca bir Claude'nin diğerine yazdığı metindir — asla göndericinin konuşma geçmişi veya dosyaları değildir. Dolayısıyla iki oturum birbirinden tamamen haberdar olabilir ve yine de ikisi de aynı klasördeki aynı schema.ts dosyasını yazmak üzere olabilir. Anthropic bunu doğrudan söylüyor: paylaşılan bir çalışma dizininde tek bir dosyayı düzenleyen iki agent birbirlerinin değişikliklerinin üzerine yazabilir. Ortada ne bir kaynak dosya kilidi var ne de yazımları uzlaştıran bir merge katmanı. Mesajlaşma diğer oturuma ne olduğunu söyler; bir yazımın gerçekleşmesini engellemez.

Worktrees yalıtımı sağlıyor

Yazıda önerilen koruma, oturum başına bir git worktree. Bir terminalde claude --worktree backend, diğerinde claude --worktree frontend çalıştırmak her oturuma kendi dizinini, kendi dalını ve izlenen dosyaların kendi kopyasını verir. Dokümanlara göre bir oturumdaki düzenlemeler artık diğerindeki dosyalara hiç dokunmuyor ve Claude Code, bir worktree içerisinden ana checkout'a yönelik bir düzenlemeyi reddediyor; böylece sınır araç tarafından dayatılıyor, teamüle bırakılmıyor. Yazar ayrıca .claude/worktrees/ yolunu .gitignore'a eklemeyi öneriyor ki worktree içerikleri ana checkout'ta takipsiz gürültü olarak görünmesin.

Yalıtım yerine oturduğunda mesajlaşma, tasarlandığı biçimde yararlı hale geliyor: A oturumu bir API değişikliğini commit eder ve B oturumuna commit hash'ini birlikte değişen dosyaların listesini gönderir; B rebase ya da cherry-pick yapar ve değişenleri yeniden okur. İkisi de aynı dosyaya dokunduysa git bir conflict çıkarır — bu da geliştiriciyi durdurup çözülebilecek bir şeydir — sonradan, ortaya çıkarsa bile sessizce üzerine yazmak yerine.

Paylaşılan dosyaların sahibi yine birinin olması gerekiyor

Worktrees package gibi dosyaların sahibini kimin olduğunu belirlemiyor. Her iki oturumun da gerçekten değiştirmesi gereken dosyalar için yazarın tavsiyesi bilinçli olarak sıradan: her an için dosya başına tek sahip, paralelde farklı dosyalar ve sırayla aynı dosya — bunlar prompt'lara bir protokol olarak yazılmalı. Her oturum sahibi olduğu adlandırılmış dizinleri alır, bir devir her iki taraf da diğerinin elindeki dosyaya dokunmadan önce mesajla yapılmalıdır ve bu devirden önce bir commit zorunludur.

Agent Teams ve MCP Agent Mail farklı biçimlerde yetersiz kalıyor

Yazı alternatifleri de tartışıyor. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS flag'inin arkasındaki deneysel mod olan Agent Teams, bir lider oturumun takım arkadaşları doğurup denetlemesine izin veriyor ve paylaşılan bir görev listesi, bir posta kutusu ve doğrudan mesajlar sunuyor; bir görevi claim etmek dosya kilidiyle korunuyor. Ama bu kilit görev kaydının üzerinde, kaynak dosyaların üzerinde değil — kimin ne yapacağını koordine ediyor ama iki yazıcının tek bir dosyaya inmesini engellemiyor; sorumluluğu dosyaya göre bölmenin resmi tavsiye olmasının nedeni de bu. Üçüncü taraf bir çaba olan MCP Agent Mail bu boşluğu en çok adresleyen seçenek: kalıcı agent kimlikleri, iş parçacıklı gelen ve giden kutuları, path ve glob'a göre dosya rezervasyonları, bayat rezervasyonlar üzerinde TTL'ler ve opsiyonel bir pre-commit veya pre-push guard. Üç seçenek içinde dosya sahipliğini hiç modelleyen tek seçenek o ama rezervasyonları yol gösterme niteliğinde — sunucu bir conflict bildiriyor, transactional bir yazma kilidi gibi davranmıyor ve guard, paylaşılan bir dizinde hâlâ süren bir yazımı durduramadan bir commit'i engelleyebiliyor. Swarm ya da orchestration araçları olarak pazarlanan plugin'ler ise büyük ölçüde Agent Teams üzerine prompt'ları ve rolleri otomatikleştiriyor ve kendi kilitlemesini eklemiyor.

Neden önemli

Tek bir depoya karşı birkaç yapay zekâ kodlama agent'i çalıştırmak rutin hale geliyor ve burada anlatılan başarısızlık biçimi gürültülü değil sessiz: tamamen haberdar olan bir agent yine de bir akranının işini yok edebilir. Bu yazı, bir iletişim kanalının eşzamanlılık kontrolü olmadığına dair yararlı bir hatırlatma. Agent araçları gerçek dosya düzeyinde kilitleme sunana kadar, güvenilir desen gösterişsiz olan — git worktrees üzerinden sert yalıtım, artı oturumların paylaştığı her şey için açık, insan tanımlı sahiplik kuralları.