telepty, birden fazla makinede çalışan terminal AI CLI oturumlarına (claude, codex, gemini vb.) uzaktan talimat göndermeyi ve ekranı okumayı sağlayan hafif bir ajan oturumu kontrol düzlemidir — çıkarım ve işler her ajan tarafından olduğu gibi yürütülür (data plane), telepty ise yalnızca bu oturumları adresleyip iletimi garanti eden katmanı üstlenir (PTY tabanlı arka plan daemon'u + oturum bridge'i). Her oturuma ad tabanlı bir adres verir, talimatın gerçekten alınıp alınmadığını doğrular ve macOS·Linux·Windows desteği sunar. Makineler arası iletimi kendisi inşa etmek yerine zaten doğrulanmış Tailscale(WireGuard) üzerine kuruldu — anahtar değişimi, NAT traversal ve şifrelemeyi yeniden uygulayıp saldırı yüzeyini büyütmek yerine, yıllardır sahada doğrulanmış bir katmana devretmeyi seçti. MIT lisanslı açık kaynaklıdır.
npm i -g @dmsdc-ai/aigentry-telepty && telepty daemon start
# Zaten kullandığınız CLI'yi olduğu gibi sarıp adlandırılmış bir oturuma dönüştürür (her makinede bir kez)
telepty allow --id orchestrator claude # Bu makinedeki claude oturumu → "orchestrator"
telepty inject "backend@100.x.y.z" "Kimlik doğrulama middleware'ini refactor etmeye başla" # Uzak oturuma talimat
telepty read-screen "backend@100.x.y.z" # İlerlemeyi kontrol et
telepty broadcast "İşi tamamlayıp durum raporu ver" # Tüm oturumlara duyuru
Arka plan
Birden fazla AI CLI oturumunu birden fazla makineye yayarak çalıştırmak yaygınlaştı. Yürütme, oturum sayısı kadar paralel ölçeklenebiliyor; ancak oturumlar arasındaki iletim — talimat yayma, ilerlemeyi kontrol etme, sonuçları geri alma — hâlâ insanların terminaller arasında gidip gelmesiyle yapılıyor. Bu aracın çıkış noktası da bu darboğazdı: üç makinede üç AI CLI oturumunu aynı anda çalıştırınca, yürütmeden önce talimat ve sonuç taşıma "iletim" aşamasının insanda tıkandığı görüldü.
- Mevcut durum: 3 terminal arasında gidip odak değiştirme → talimatı kopyala-yapıştır → her oturum için ilerlemeyi tekrar tekrar kontrol etme
- telepty: Tek bir terminalden
ad@hostadresiyle talimat enjekte etme ve ekranı geri alma
Mevcut araçlar bu katmanı doldurmuyor. tmux/SSH oturuma "bağlanan" araçlar olduğu için gönderme ve doğrulama işleri hâlâ manuel; ajan framework'leri ise mevcut oturumları ve iş akışlarını kendi yöntemleriyle yeniden yazmayı gerektiriyor. telepty, aradaki o ince katmanı hedefliyor — zaten çalışan oturumları olduğu gibi bırakıp yalnızca iletimi altyapıya indirmek.
Tasarım
- Oturumu adla hedefleme — Tüm oturumlar
<oturumadı>@<host>biçiminde çağrılır. Hedefin hangi makinede, hangi işletim sisteminde olduğuyla ilgilenmeniz gerekmez. - "Gönderildi" ile "alındı"yı ayırma — Alıcı oturum meşgulse mesajı kuyrukta (mailbox) tutar ve gerçekten alındığı anı terminal render durumuna göre belirleyip kesinleştirir. Gönderdikten sonra bir insanın tekrar kontrol etmesine gerek yoktur.
- Daemon yeniden başlasa da oturum korunur — Oturumu tutan süreç (bridge) ile yönlendirme daemon'u (daemon) ayrıdır; bu yüzden daemon yükseltmesi devam eden işi kesmez.
- İletimi doğrulanmış katmana devretme — Kendi P2P protokolünü oluşturmadı. Tailscale varsa daemon tailnet IP'sini otomatik algılar ve doğrudan bunun üzerinden bağlanır: port açma 0, sertifika yönetimi 0, firewall kuralı 0. Tailnet olmayan ortamlarda SSH tüneliyle (
telepty connect user@host) bağlanır — her iki durumda da şifreleme ve kimlik zaten doğrulanmış araçların sorumluluğundadır; telepty bunların üzerinde yalnızca oturum adresleme ve iletimi yapar.
Komutlar inject / read-screen / attach / send-key / broadcast / list olmak üzere altı tanedir; CLI aynı zamanda API olduğundan shell script'lerinde doğrudan birleştirilebilir. Üstelik yalnızca insanlar kullansın diye yapılmadı — pakette Claude Code·Codex·Gemini CLI için 9 skill bulunur (yerleşik yükleyiciyle kurulur), böylece ajanların kendisi telepty'yi araç olarak kullanır: oturumları listeler, başka makinelerdeki ajanlara talimat gönderir ve ekranı okur. Aşağıdaki demodaki relay tam olarak bu sahnedir — insan değil, her LLM doğrudan telepty inject çalıştırır.
İlk referans metrikler (0.6.11 build ölçümü — mevcut sürüm 0.7.1 · ağ gidiş-dönüşü ve PTY başlatma overhead'i dahil)
- Meşgul oturum hedefli gated inject için kuyruklama→alım onayı kesinleşmesi: Linux yaklaşık 487ms · Windows yaklaşık 1.2s — daha fazla ölçüm biriktiriliyor; önemli olan sayıdan çok kabul ölçütü olarak HTTP kabulünü değil, alıcı taraftaki ACK varışını almak.
- macOS·Linux·Windows arasında 3 işletim sistemli makineler arası iletim aynı ölçütle doğrulandı.
Güvenlik
Daemon yalnızca localhost(127.0.0.1) ve tailnet'e özel IP'lere bind edilir — 0.0.0.0 açıklığı olmadığı için tailnet dışından port taramasıyla bile erişilemez. Yalnızca tailnet peer'larına güvenir; PTY'ye yazma yetkisi, oturuma sahip kullanıcının kapsamını aşmaz. 0.7.1'den itibaren tarayıcıdan gelen istekleri açıkça reddeder — kullanıcının ziyaret ettiği bir web sayfasının localhost üzerindeki kontrol API'si veya WebSocket üzerinden oturuma erişme yolunu kapattı (varsayılan izinli origin yok).
Sınırlamalar
Beta aşamasında. CLI'lere özgü render edge case'leri hâlâ var ve Windows beta etiketi taşıyor. Terminal emülasyonu yapmadığı için read-screen, hücre grid'i yerine çıktı akışının son kısmını döndürür — sık repaint yapan TUI'lerde aynı frame tekrarlanıyor gibi görünebilir. Bilinen maddeler README'deki Limitations bölümünde derlenmiştir.
Bağlantılar
- GitHub: https://github.com/dmsdc-ai/aigentry-telepty
- README demosu: 3 makinedeki (macOS·Linux·Windows) 3 LLM'in (Grok·Codex·Claude) doğrudan telepty inject çalıştırarak birbirlerine relay yaptığı sahne — her ekran, özgün CLI TUI'nin
attachile canlı yakalanmış halidir. Aynı komut, tek bir makine içindeki oturumlar arasında da aynen çalışır (aynı makine relay demosu dahil). - npm:
@dmsdc-ai/aigentry-telepty(MIT, 0.7.1)
Birden fazla AI CLI oturumu yönetenlerin iletim katmanı çözümlerini merak ediyorum. Geri bildirimlerinizi verirseniz yansıtacağım.
1 yorum
Geliştirme motivasyonuna biraz ek yapayım: 3 çapraz platform makinede 4 Cluade, Codex Gemini ve Grok oturumunu çalıştırırken, "çalıştırma scale-out oluyor ama iletim tek bir kişiye bağlı kalıyor" darboğazını yaşamamla başladı. Bu,
tmux/SSHyerine geçen bir şey değil, paralel kullanılan bir araç — amaç "terminale bağlanmak" değil, "oturumu adreslemek + iletimin ulaştığını doğrulamak". Merak ettiklerinizi rahatça sorabilirsiniz.