telepty — कई मशीनों में बिखरे AI एजेंट सेशनों के लिए कंट्रोल प्लेन

telepty एक हल्का agent session control plane है, जो कई मशीनों पर चल रहे terminal AI CLI sessions (claude, codex, gemini आदि) को remote निर्देश भेजने और उनकी स्क्रीन पढ़ने की सुविधा देता है — reasoning और काम हर agent अपने स्तर पर वैसे ही करता रहता है (data plane), और telepty सिर्फ उन sessions को address से बुलाने और delivery सुनिश्चित करने वाली layer संभालता है (PTY-आधारित background daemon + session bridge)। हर session को नाम-आधारित address दिया जाता है, और यह इस बात तक की पुष्टि करता है कि निर्देश वास्तव में स्वीकार हुआ या नहीं; macOS·Linux·Windows समर्थित हैं। Cross-machine transport को खुद बनाने के बजाय इसे पहले से साबित Tailscale (WireGuard) के ऊपर बनाया गया है — key exchange, NAT traversal और encryption को फिर से लागू करके attack surface बढ़ाने की बजाय, कई सालों से production में परखी गई layer को जिम्मेदारी दी गई है। यह MIT license वाला open source है.

npm i -g @dmsdc-ai/aigentry-telepty && telepty daemon start  
  
# जिस CLI का आप पहले से इस्तेमाल कर रहे हैं, उसे वैसे ही wrap करके named session बनाइए (हर मशीन पर एक बार)  
telepty allow --id orchestrator claude    # इस मशीन का claude session → "orchestrator"  
  
telepty inject "backend@100.x.y.z" "인증 미들웨어 리팩터링 시작해줘"   # remote session को निर्देश  
telepty read-screen "backend@100.x.y.z"                               # प्रगति देखें  
telepty broadcast "작업 마무리하고 상태 보고해줘"                      # सभी sessions को सूचना

पृष्ठभूमि

कई AI CLI sessions को कई मशीनों पर चलाकर development करना अब आम होता जा रहा है। Execution, session की संख्या के हिसाब से parallel scale हो जाता है, लेकिन sessions के बीच delivery — निर्देश पहुँचाना, प्रगति देखना, नतीजे वापस लेना — अभी भी इंसान को terminal बदल-बदल कर करना पड़ता है। इस टूल की शुरुआत भी इसी bottleneck से हुई: तीन मशीनों पर तीन AI CLI sessions साथ चलाने पर, execution से पहले ही निर्देश और परिणाम ले जाने वाला "delivery" चरण इंसान पर अटक गया।

पहले: 3 terminals के बीच घूमना, focus बदलना → निर्देश copy-paste करना → हर session में progress देखना
telepty: एक ही terminal से नाम@होस्ट address पर निर्देश inject करना और स्क्रीन वापस पढ़ना

मौजूदा tools इस layer को नहीं भरते। tmux/SSH session से "attach" होने वाले tools हैं, इसलिए भेजना और पुष्टि करना अब भी manual रहता है, और agent frameworks आपसे मौजूदा sessions और workflows को अपने तरीके से फिर से लिखने की मांग करते हैं। telepty का लक्ष्य इनके बीच की एक पतली layer है — पहले से चल रहे sessions को ज्यों का त्यों छोड़कर सिर्फ delivery को infra में उतारना।

डिज़ाइन

नाम से session चुनना — सभी sessions को <सेशननाम>@<होस्ट> के रूप में बुलाया जाता है। target किस मशीन या किस OS पर है, इसकी चिंता नहीं करनी पड़ती।
"भेजा गया" और "मिला" को अलग करना — अगर receiving session व्यस्त है, तो message को queue (mailbox) में रखा जाता है, और वास्तव में कब स्वीकार हुआ इसे terminal render state से तय करके confirm किया जाता है। भेजने के बाद इंसान को फिर से जांचने की जरूरत नहीं रहती।
daemon restart होने पर भी session बने रहते हैं — session पकड़ने वाली process (bridge) और routing daemon अलग हैं, इसलिए daemon upgrade चल रहे काम को नहीं तोड़ता।
transport को परखी हुई layer को सौंपना — अपना P2P protocol नहीं बनाया गया। अगर Tailscale मौजूद है, तो daemon tailnet IP को अपने आप पहचानकर उसी पर सीधे connect हो जाता है: 0 port opening, 0 certificate management, 0 firewall rules। जिन environments में tailnet नहीं है, वहाँ SSH tunnel (telepty connect user@host) से connect होता है — दोनों ही मामलों में encryption और identity की जिम्मेदारी पहले से परखे हुए tools की होती है, और telepty उनके ऊपर सिर्फ session addressing और delivery करता है।

Commands सिर्फ inject / read-screen / attach / send-key / broadcast / list ये छह हैं, इसलिए CLI ही API है और इसे shell scripts में तुरंत जोड़ा जा सकता है। और यह सिर्फ इंसानों के लिए नहीं बना है — package में Claude Code·Codex·Gemini CLI के लिए 9 skills शामिल हैं (built-in installer से install), इसलिए agent खुद telepty को tool की तरह इस्तेमाल करता है: sessions देखता है, दूसरी मशीन के agent को निर्देश भेजता है, और स्क्रीन पढ़कर वापस लाता है। नीचे demo में relay ठीक यही दिखाता है — इंसान नहीं, बल्कि हर LLM सीधे telepty inject चलाता है।

शुरुआती संदर्भ संकेतक (0.6.11 build पर माप — मौजूदा release 0.7.1 · network round-trip और PTY initialization overhead सहित)

busy session पर gated inject की queueing→acceptance confirmation: Linux पर लगभग 487ms · Windows पर लगभग 1.2s — अभी और measurements इकट्ठी की जा रही हैं, और यहाँ संख्या से ज्यादा अहम बात यह है कि HTTP accept नहीं, बल्कि receiving side ACK landing को acceptance का मानदंड माना जाता है।
macOS·Linux·Windows, तीनों OS के बीच cross-machine delivery को इसी मानक पर verify किया गया है।

सुरक्षा

daemon सिर्फ localhost (127.0.0.1) और tailnet-विशेष IP पर bind होता है — 0.0.0.0 exposure नहीं है, इसलिए tailnet के बाहर port scan से भी पहुँचना संभव नहीं। सिर्फ tailnet peers पर भरोसा किया जाता है, और PTY पर write permission session के मालिक user की सीमा से बाहर नहीं जाती। 0.7.1 से browser से आने वाले requests को स्पष्ट रूप से reject किया जाता है — किसी visited webpage के localhost control API या WebSocket के जरिए session तक पहुँचने वाले रास्ते को बंद कर दिया गया है (कोई default allowed origin नहीं)।

सीमाएँ

यह beta है। अलग-अलग CLI rendering के edge cases अभी बाकी हैं, और Windows अभी beta टैग के साथ है। चूँकि यह terminal emulation नहीं करता, read-screen cell grid की बजाय output stream का आख़िरी हिस्सा लौटाता है — जिन TUI में repaint बार-बार होता है, वहाँ वही frame बार-बार दिख सकता है। ज्ञात बिंदु README के Limitations section में संकलित हैं।

लिंक

GitHub: https://github.com/dmsdc-ai/aigentry-telepty
README demo: 3 मशीनों (macOS·Linux·Windows) के 3 LLM (Grok·Codex·Claude) एक-दूसरे को relay करते हुए खुद telepty inject चलाते हैं — हर स्क्रीन मूल CLI TUI की attach के जरिए live capture है। यही commands एक ही मशीन के अंदर sessions के बीच भी वैसे ही काम करते हैं (same-machine relay demo सहित)।
npm: @dmsdc-ai/aigentry-telepty (MIT, 0.7.1)

जो लोग कई AI CLI sessions चला रहे हैं, उनके delivery layer के समाधान के बारे में जानना चाहूँगा। Feedback देंगे तो उसे शामिल करूँगा।