Cursor Projects Çok Oyunculu İş Birliği Rehberi (2026 Beta)

Cursor, 10 Kasım 2026'da Projects'i tek kişinin yönettiği bir orkestrasyon aracından ekiplerin birlikte çalışabildiği çok oyunculu bir çalışma alanına dönüştürdü. Artık koordinatör ajanınız bir ekip arkadaşının koordinatörüyle doğrudan konuşabiliyor, çakışan kod değişikliklerini erkenden işaretleyebiliyor ve tamamlanmamış pull request'leri devredebiliyor. Ancak bu yapıyı güvenle kullanmak için Teams hesabında Cursor 3.26.13 veya üzeri bir sürüm ve paylaşılan bağlam dosyalarına ilişkin net kurallar gerekiyor; aksi halde bir ajanın onaylanmamış varsayımı, depodaki diğer mühendislerin planını değiştirebilir.

10 Kasım güncellemesiyle tek koordinatör modelinden ekip çalışmasına geçiş

Cursor Multiplayer Projects, 10 Eylül 2026 tarihli tek kullanıcılı Projects betasını çok kullanıcılı bir çalışma alanına taşıyor. Her ekip üyesi, kendi izole bire bir koordinatör sohbetini yönetirken tek bir Task Board'u ve tek bir Project Agent Store'u (/cursor/stores/self) paylaşıyor. Resmî Cursor Projects dokümantasyonuna göre 10 Kasım güncellemesi, kişisel yürütme akışlarını ve ekipçe paylaşılan durumu sekiz temel başlıkta ayırıyor:

Kimler kullanabilir? Davetler ve iki aşamalı kurulum

Cursor Projects dokümantasyonuna göre çok oyunculu bir Project paylaşmak için Cursor Teams veya Enterprise hesabı, 3.26.13 ya da üstü istemci sürümü ve davet edilen herkesin depoya ayrı ayrı erişimi gerekir. Multiplayer paylaşım Free, Plus ve Legacy Hobby planlarında kullanılamaz. Privacy Mode (Legacy) etkinse, Project self-hosted machines üzerinde çalışıyorsa veya arşivlendiyse ekip arkadaşı davet edemezsiniz.

Aşama 1: Temel Project'i 4 adımda oluşturun

İş birliği davetlerini göndermeden önce Project sahibi, çalışma alanını Cursor'daki Agents Window üzerinden başlatır:

1. Soldaki menüden Projects'i açın: Agents Window'u açın, kenar çubuğundaki Projects bölümünü bulun ve New Project seçeneğine tıklayın.
2. Project'e bir ad verin: Bir simge seçin ve sonucu net biçimde tanımlayan, kapsamı belli bir ad girin. Alan boş bırakılırsa varsayılan ad New Project olur. Depo başına tek ve devasa bir Project oluşturmak yerine; şema geçişi, çoklu PR içeren bir özellik ve düzenli CI bakımı gibi teslimatlara göre ayırmak daha sağlıklıdır.
3. Workspace ve koordinatör modelini seçin: Workspace altında hedef GitHub deposunu seçin. GitHub bağlı değilse Connect GitHub seçeneğine tıklayın. Ardından Model bölümünden koordinatörünüz olacak modeli belirleyin.
4. Create Project'e tıklayın: Cursor, Project için bir bulut bilgisayarı hazırlar ve koordinatör ajanınızla bire bir bir sohbet açar.

Uygun bir üst seviye Cloud Agent sohbetinde işin kapsamını zaten belirlemeye başladıysanız, önceki konuşmanın koordinatör tarafından alınması için bu sohbeti kenar çubuğundan Project satırına sürükleyin. Alternatif olarak sohbetin kenar çubuğu menüsünden Add to Project seçeneğini kullanabilirsiniz. Bu işlem yerel bir sohbetten yapılırsa Cursor, sohbeti Project'e eklemeden önce Remote Control moduna dönüştürür.

Aşama 2: Ekip arkadaşlarını 3 adımda davet edin

Project etkinleştirilip depoya bağlandıktan sonra, sahibi veya mevcut üyelerden herhangi biri ekip arkadaşlarını dokümante edilmiş şu üç adımla davet edebilir:

1. Davet menüsünü açın: Project'in üst kısmındaki Invite seçeneğine tıklayın. İlk davetten sonra bu kontrol, yüz simgelerinden oluşan bir satıra dönüşür.
2. Kişi davet edin ya da paylaşım bağlantısını kopyalayın: Invite teammates to this project altında ada veya e-posta adresine göre arama yapıp daveti gönderin. Project URL'sini Slack ya da Linear üzerinden paylaşmak içinse Copy link seçeneğini kullanın.
3. Ekip arkadaşı daveti kabul eder ve kendine ait sohbetini alır: Davet edilen kişi Project'in davet kartında Accept Invite seçeneğine tıklar. Ardından kendi Project sohbetine, kendi koordinatör ajanına ve paylaşılan Project bağlamına okuma/yazma erişimine sahip olur.

Üyelik ve bağlantı denetimleri

Erişim sınırları hem Cursor ekip düzeyinde hem de Git deposu düzeyinde uygulanır:

• Aynı ekip ve depo erişimi şartı: Kişisel hesap kullanıcıları ile harici Cursor ekiplerindeki geliştiriciler katılamaz. Davet edilen ekip arkadaşlarının ayrıca Project'in bağlı olduğu depoya bağımsız erişimi olmalıdır.
• Sızan bağlantıları geçersiz kılma: Davet bağlantısını yalnızca mevcut Project üyeleri kopyalayabilir. Bir bağlantı gereğinden geniş paylaşılmışsa Project sahibi davet menüsünden Reset Share Link seçeneğini kullanarak önceki tüm kopyaları geçersiz kılabilir.
• Ayrılma veya üyeleri kaldırma: Her katılımcı kenar çubuğu menüsündeki Leave Project seçeneğiyle ayrılabilir ve daha sonra geçerli bir davet ya da bağlantıyla tekrar katılabilir. Project sahibi ise davet menüsündeki Remove seçeneğiyle bir katılımcıyı kaldırabilir.

Paylaşılan bağlam (/cursor/stores/self) ve kişisel depo (/cursor/stores/user) farkı

Cursor Projects Context and Personal Store dokümantasyonunda belirtildiği üzere Cursor Multiplayer Projects, özel geliştirici ayarlarını ekip çapındaki bilgiden ayırmak için her ajanın ortamına iki ayrı dosya sistemi yolu bağlar: paylaşılan Project bağlamı için /cursor/stores/self, kişisel kullanıcı deposu için /cursor/stores/user. Resmî depo kurallarına göre, bir ekip arkadaşı paylaşılan bir Project'e katıldığında koordinatörü /cursor/stores/user içindeki ilgili çalışma tercihlerini Project kurallarına kopyalamayı önerebilir. Ancak yalnızca kullanıcının açıkça onayladığı girdiler kopyalanır.

Koordinatör ajanlar güvenilmeyen yan sohbetlerde nasıl konuşuyor?

Bir koordinatör, ekip arkadaşının işi hakkında bilgiye ihtiyaç duyduğunda Cursor Projects multiplayer spesifikasyonu, alıcının normal sohbetinden Chat with {name}'s agent adlı bir yan sohbet dallandırarak o ekip arkadaşının koordinatörüne doğrudan mesaj göndermesine izin verir. Cursor, gelen sorgunun alıcının aktif akışını kesmesini veya gizli verileri dışarı aktarmasını önlemek için bu dallanmış yan sohbetlerin çalıştırabileceği işlemleri sınırlar.

Cursor ürün yöneticisi Aryaman Khandelwal, 10 Kasım 2026 tarihli multiplayer duyurusunda ajanlar arası koordinasyonun iki temel kullanım senaryosunu öne çıkardı:

• Arayüz ve özellik çakışması: Bir mühendis ürün sayfasına müşteri değerlendirmeleri eklerken bir tasarımcı da aynı sayfayı yeniden tasarlıyorsa, koordinatörleri bu çakışmayı erken fark eder. Böylece değerlendirme bileşeni sonradan yeniden düzenlenmek yerine yeni yerleşime baştan dahil edilir.
• Şema ve okuyucu sıralaması: Bir geliştirici veritabanı şemasını değiştirirken diğer ekip arkadaşı bu veritabanından okuyan bir özellik geliştiriyorsa, ajanlar birleştirme sırasında entegrasyon çakışması yaşamamak için işlem sırasını baştan belirler.

Resmî Cursor Projects dokümanlarında How coordinators message each other başlığı altında açıklandığı gibi, bu iletişim dört katı kurala dayanır:

1. Giden sorgu: Ekip arkadaşı A'nın koordinatörü, ekip arkadaşı B'nin işine bağımlı olduğunu tespit eder ve B'nin koordinatörüne doğrudan mesaj yollar.
2. Dallanmış yan sohbetin oluşturulması: Gelen mesaj, ekip arkadaşı B'nin normal sohbetinden dallanan ve Chat with {Teammate A}'s agent adını taşıyan bir yan sohbet oluşturur.
3. Güvenilmeyen girdi olarak değerlendirme: Gelen koordinatör mesajları ajan girdisi olarak etiketlenir; alıcıya mesajın hangi ekip arkadaşının ajanından geldiği bildirilir. Alan ajan, mesajı kendi kullanıcısından gelen doğrudan talimat olarak değil, değerlendirilmesi gereken güvenilmeyen içerik olarak ele alır.
4. Ana sohbet bilgisiyle yanıt ve sonraki turda bildirim: Yan sohbet, alıcının ana sohbetinde mevcut olan bilgilerden yararlanarak yanıt verir ve cevabı gönderen koordinatöre iletir. Ekip arkadaşı B'nin ana sohbeti anında kesilmez; bunun yerine bir sonraki turda iletişim hakkında not görür.

Cursor Projects dokümantasyonu, dallanmış her Chat with {name}'s agent yan sohbeti için izin sınırını açık biçimde tanımlar:

Planlamadan teslimata: Betada ortak kararların koptuğu noktalar

Cursor'un resmî örnekleri, vardiyaya gelen mühendisin koordinatörünün aktif olayları, Linear panolarını ve Slack ileti dizilerini devraldığı kurum içi on-call rotasyonlarına odaklanıyor. Buna karşılık tek kullanıcılı Projects beta raporları, dört aşamalı yaşam döngüsünde ekiplerin önlem almasını gerektiren dört operasyonel hata biçimine işaret ediyor:

Değiştirilebilir Project Notes ve “ortak hatalar” sorunu

Cursor Community Forum'da yayımlanan Cursor Projects betasına ilişkin 3 günlük tek kullanıcılı saha testinde geliştirici Lutz Leonhardt, senkronize bağlam klasörünü ve orkestratör transkriptlerini inceledi. Test; 5 oturumu, yaklaşık 14 saati, 20 ajanı, 32 görevi, 49 ajan turunu ve 4'ü birleştirilmiş 5 pull request'i kapsıyordu. Görev dağıtımı ve teslimat başarılı olmuş, Codex inceleme botunun bulduğu 18 bulgunun tamamı düzeltilmişti. Buna rağmen Project bellek katmanında görülen iki hata, paylaşılan çok oyunculu depoya taşındığında daha da büyük risk oluşturuyor:

• 1 açık okuma karşısında 111 not yeniden yazımı: Koordinatör, 3 günlük test boyunca Project Notes dosyasını tam dosya değişimi yoluyla 111 kez yeniden yazdı; fakat dosyayı açıkça yalnızca bir kez okudu. 1. kilometre taşı, ikinci gün arşivleme başlamadan notlardan silindi. Podcast LLM analizi için verilen açık onay ise iki yeniden yazımdan sonra "done" olarak sıkıştırıldı; bunun sonucunda koordinatör ertesi gün aynı onay için yeniden beklemeye başladı.
• Onaylanmamış varsayımlar karar diye kaydedildi: Koordinatör 5 anahtar kelime ve 3 açık soru listeledikten sonra geliştirici bir API anahtarı hakkında soru sordu ve 2. kilometre taşının başlayıp başlayamayacağını sordu. Koordinatör, doğrulanmamış varsayımları "accepted for the start" olarak değerlendirdi ve önceki önerisiyle çelişecek biçimde sürekli çalışan bir cron adaptörü geliştiren ajanı başlattı. Başka bir iletişimde koordinatör, zaten gerçekleştirdiği bir çalışan ajan devrini almadığını söyledi ve bu yanlış geçmişi bağlam klasörüne iş akışı kuralı olarak yazdı.

Leonhardt'ın raporu tek kullanıcılı Projects'i test etmiş olsa da multiplayer modelinde her ekip üyesinin ajanları /cursor/stores/self alanını okur ve yazar. Dolayısıyla kirlenmiş bir not ya da doğrulanmamış bir ajan varsayımı, daha sonra ortak depoyu okuyan her ekip arkadaşı ajanını etkileyebilir. Multiplayer dağıtımından sonra geliştirici @avisinghdotdev, X'te bunu şöyle dile getirdi:

"Açıkçası, özellikle farklı kural ve beceri setlerine sahiplerse, bir ajanın ekip arkadaşımın ajanıyla konuşması fikrini sevmiyorum. Tek bir saçmalık kaliteyi düşürebilir." — @avisinghdotdev

Multiplayer Projects için önerilen önlem: Koordinatörlerin /cursor/stores/self içinde tek bir değiştirilebilir Markdown dosyasını hem taslak alanı hem de karar kaydı olarak kullanmasına izin vermeyin. Project kurallarınızı durumu iki dosyaya ayıracak şekilde yapılandırın:

1. Görev durumu ve etkin dal işaretçileri için değiştirilebilir bir plan.md.
2. Yalnızca ekleme yapılabilen bir ajan kuralıyla yönetilen, depoya işlenmiş bir decisions.md. Sıkı yaptırım gereken yerlerde Git diff incelemesi veya branch protection ile desteklenmelidir. Dosyada date, decided_by (human:@handle veya agent:proposed), status (proposed, accepted, superseded), applies_to (dosya yolu glob'u) ve tek satırlık rationale kaydedilmelidir.

Eski checkout'lar, bulut MCP farkları ve yerel worktree devirleri

İkinci beta sorun grubu, Cursor'un varsayılan olarak bulutu kullanan yürütme mimarisinden kaynaklanıyor. Day 7 Cursor Projects receipt ve r/cursor başlıklarındaki doğrulanmış kullanıcı raporlarına göre Projects'i benimseyen ekipleri etkileyen dört operasyonel tuzak var:

1. Uzun ömürlü Project'lerde eski Git checkout'ları: Uzun süren bir bulut Project'i, main dalında birleştirilen değişiklikleri otomatik olarak pull etmez. Day 7 Report R1'de Cursor çalışanları bunun beklenen davranış olduğunu doğruladı ve koordinatörden pull yapmasını istemeyi önerdi. Multiplayer kullanımında, yeni görev dağıtmadan önce koordinatörünüze her zaman git pull çalıştırmasını söyleyin.
2. Yalnızca bulutta yüklenen MCP sunucuları: Koordinatör Cloud Agent olarak çalıştığı için yalnızca Cursor bulut ayarlarınızda yapılandırılmış Model Context Protocol (MCP) sunucularını okur (Day 7 Report R6). Sadece yerel masaüstü düzenleyicinizde tanımlanan MCP sunucuları Project koordinatörüne yüklenmez.
3. “No self-hosted workers available” anahtarı tuzağı: Bulut Project'inden yerel test çalıştırmak için Settings > Agents altında Remote Control'ü, yani yerel self-hosted worker'ları etkinleştirmeniz; ardından depo kökünde agent login ve agent worker start çalıştırmanız gerekir. Ancak Remote Control'ü açmak, ekip kontrol panelinde Self-hosted Machines seçeneğini de açabilir ve Require Self-hosted Machines and Personal Machines ayarını etkinleştirebilir. Bu da Cloud Agents ve Projects'in Cursor bulutunda çalışmasını engeller. Hibrit bulut/yerel yürütmeyi korumak için ekip yöneticileri bu Require anahtarını kapatmalıdır.
4. Bulut token tüketimi: Paralel olarak 10 ila 20 bulut alt ajanı çalıştırmak, plan kullanımını hızla tüketir. r/cursor kullanıcısı u/Shirc, Reddit'te şöyle yazdı:

"Projects'in potansiyeli var ama şu an biraz dağınık ve token'ları kesinlikle hızla tüketiyor." — r/cursor'da u/Shirc

Geliştirici u/dryu12, aynı r/cursor başlığında token tüketimini kontrol etmek için Composer'ı koordinatör modeli olarak seçmeyi ve hangi devredilen görevlerin hangi modellere gideceğini açık kurallarla belirlemeyi öneriyor. Ekibiniz Cursor'un yerleşik faturalandırmasının dışında harici CI inceleme botları veya özel ajan betikleri de kullanıyorsa, bu API çağrılarını AIReiter üzerinden yönlendirmek; DeepSeek V4.1 Flash gibi düşük maliyetli modelleri Claude Opus 5.5 gibi inceleyicilerle tek bir kullandıkça öde bakiyesinde birleştirmenizi sağlar.

PR inceleme çakışmaları: Her pull request'in tek bir sahibi olmalı

Cursor Projects subscriptions dokümantasyonuna göre, en az 1 abonelik bulunduğunda—bir Slack kanalını, PR etkinliğini, bir daldaki CI çalıştırmalarını veya every day at 8:00 AM gibi bir zamanlamayı izleyen abonelik—sohbet giriş alanının üzerinde Listening rozeti görünür.

Leonhardt'ın 3 günlük tek kullanıcılı testinde bile PR incelemelerinin ele alınması belirsizdi. Koordinatör, ilk uygulama yapan çalışan ajan ve sonradan oluşturulan düzeltme ajanları inceleme olaylarına tepki verebiliyordu. Bir PR'da koordinatör, ilk ajanın zaten üzerinde çalıştığı düzeltmeler için yazara iki kez soru sordu. Başka bir PR'da ise 3 ajan aynı durum dosyasını yeniden yazdı ve yanlış yazar bilgisini bıraktı.

Aynı depoda birden çok ekip üyesi koordinatör çalıştırdığında, birden fazla koordinatörü depo geneli PR olaylarına abone etmek yinelenen düzeltme commit'leri ve boşa harcanan bulut turları riskini artırır. Geliştirici @LabubuNoBB'nin X'te belirttiği gibi:

"Zor olan hiçbir zaman ajanları konuşturmak değildi. İkisi de aynı dosyayı istediğinde, neyin kime ait olduğuna karar vermekti." — @LabubuNoBB

Önerilen PR sahipliği kuralı: Paylaşılan Task Board üzerinde her PR için bir insan sahibi ve atanmış tek bir ajan belirleyin. Bu sahiplik, ilgili daldaki tüm inceleme yorumlarının sorumluluğunu da kapsamalıdır. Her ekip üyesinin koordinatör aboneliklerini, depo geneli joker kuralları yerine yalnızca kendi PR'larıyla sınırlayın.

Ekipler için karar matrisi: Project ne zaman paylaşılmalı, sohbetler ne zaman ayrı kalmalı?

Bir ekip iş akışını ortak Cursor Project'ine taşımadan önce, görev yapınızı 3.26.13+ betada doğrulanan sınırlamalarla karşılaştırın: