NanoClaw Telegram botu yanıt vermeyi bıraktığında ilk adım bir düzeltme yapmak değil, gelen mesajların host'a ulaşıp ulaşmadığını belirlemektir; çünkü ayrı ayrı raporlanmış iki NanoClaw hatası bu şikâyeti zıt belirtilerle üretir. Birinde inbound ölürken outbound teslimatı ve zamanlanmış görevler çalışmaya devam eder; bu nedenle operatörün kontrol ettiği her yüzey sağlıklı görünür. Diğerinde ise hiçbir şey gönderilmez ve günlük, hiç gönderilmemiş mesajları teslim edilmiş olarak işaretler. Şikâyet aynı, nedenler farklıdır ve birine yönelik çözüm diğerine hiçbir şey yapmaz.
Her şeyden önce bir ayrım yapın; çünkü bu ifadeye ilişkin arama sonuçları çoğunlukla farklı bir ürünle ilgilidir. OpenClaw ayrı ve çok daha büyük bir projedir — depo API kaydı 21 Eylül 2026'da okunduğunda 390.207 yıldıza ve NOASSERTION lisansına sahipti — ve NanoClaw'un kendi ana sayfası kendisini ona karşı konumlandırır. NanoClaw, nanocoai/nanoclaw'dur: MIT, arşivlenmemiş, fork değil, 30.818 yıldız, 1.068 açık issue, son gönderim 19 Eylül 2026 (GitHub API, aynı tarih). Eski qwibitai/nanoclaw adresi ona 301 döndürür; yani bu ikinci bir proje değil, adı değiştirilmiş aynı projedir. İki proje hiçbir Telegram kod yolunu paylaşmaz — NanoClaw, kendi adapter'ını channels dalından kaynak kodunu kopyalayarak kurar (add-telegram becerisi) — bu nedenle bir OpenClaw çözümü aktarılmaz. Farkın tamamı için NanoClaw ve OpenClaw sayfasına bakın.
Herhangi bir şeye dokunmadan önce belirtiyi okuyun
Aşağıdaki her satır, kendi doğrulama kontrolüne sahip, ayrı ve bağımsız olarak raporlanmış bir arızadır. Sekizinin tamamı 21 Eylül 2026'da NanoClaw'un kendi issue takipçisinden, yayımlanmış becerilerinden ve kanal belgelerinden okundu.
| Gözlemlediğiniz şey | En olası neden | Bunu doğrulayan kontrol |
|---|---|---|
| Gönderdiğiniz hiçbir şey yanıtlanmıyor ancak yanıtlar, zamanlanmış mesajlar ve outbound teslimatı hâlâ çalışıyor | Polling döngüsü başarısız oluyor ve sonsuza kadar yeniden deniyor — issue #3728, açık | Büyük bir consecutiveFailures değeri taşıyan bir Telegram polling request failed satırı; başarı günlükleri hiçbir şey kaydetmez, bu nedenle sessiz bir günlük sağlık kanıtı değildir |
Hiçbir şey gönderilmiyor; ana günlükte Message delivered ile birlikte No adapter for channel type yanında platformMsgId=undefined görülüyor | Aynı anda iki host örneği — ikinci poller Telegram'dan 409 alıyor ve adapter kaydolmadan önce kurulumu durduruyor (/debug skill, PR #2225) | telegram için Channel adapter started satırının bulunmaması ve ps aux çıktısında ikinci bir işlem |
| Doğrudan mesajlar ve gruplar çalışıyor; kanal gönderileri hiç gelmiyor | Bot token'ında eski bir sunucu tarafı güncelleme filtresi — issue #2989, açık | Bu token daha önce NanoClaw v1 veya başka bir bot kitaplığı tarafından yoklandı mı? Telegram'ın kendi Bot API'si allowed_updates hakkında şöyle diyor: "Belirtilmezse önceki ayar kullanılır." |
| Bot doğrudan mesajları yanıtlıyor ancak sıradan grup metinlerini yok sayıyor | Group Privacy açık (add-telegram skill) | BotFather, /mybots, Bot Settings, Group Privacy — ardından botu gruba yeniden ekleyin |
| Mesajlaşma çalışıyor ancak eşleştirme hiç tamamlanmıyor | Açılış zamanındaki getMe bir kez başarısız oldu ve null bot kullanıcı adı işlem ömrü boyunca önbelleğe alındı — issue #3162, açık | Eşleştirmeyi denemenizden dakikalar önce açılışta tek bir Telegram getMe failed uyarısı; issue, yeniden başlatmanın bunu temizlediğini bildiriyor |
| Kurulum "Couldn't reach Telegram" ile duruyor veya başlangıç yaklaşık bir buçuk dakika boyunca takılıyor | IPv6 yapılandırılmış ancak çalışan bir yol yok — issue #2377, açık | curl -4 Bot API'ye karşı başarılı olurken curl -6 bağlanamıyor |
| Yanıtların çoğu geliyor ancak belirli URL'leri içerenler hiç gelmiyor | Alım değil, outbound biçimlendirme sorunu: issue #3569, sabitlenmiş adapter'ın kaçışlanmamış işaretlerin tek sayıda bulunduğu mesajları kestiğini bildiriyor | Telegram gönderimi reddediyor; iki tek alt çizgili URL birbirini iptal ediyor ve sorun aralıklıymış gibi görünüyor |
| Az önce eklediğiniz ikinci bot hiç çevrimiçi olmuyor | Örnek değişkenleri başlangıçta bir kez okunuyor ve yinelenen token atlanıyor (channel documentation) | logs/nanoclaw.error.log'da bir uyarı (add-telegram skill); Telegram token başına bir poller'a izin verir, bu nedenle her botun kendi BotFather token'ı olmalıdır |
NanoClaw'un resmî ilk düzey tanılamaları iki günlük dosyası ile şu komutlardan oluşur: ncl sessions list, ncl dropped-messages list ve ncl wirings list. Yayımlanmış hiçbir sürüm kanal canlılığı komutu sunmaz; bu nedenle aşağıdaki triage bunun yerine günlük satırlarına dayanır.
# 1. Is inbound polling failing, and for how long?
# A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5
# 2. Did the Telegram adapter ever register this boot?
# Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10
# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all # Linux systemd installsInbound ölü durumdayken her şey neden sağlıklı görünüyor?
Bu yapısaldır ve en çok zaman kaybettiren bölümdür. NanoClaw'un README'si yolu mesajlaşma uygulamasından host router'ına, ardından bir inbound veritabanına, container'a, bir outbound veritabanına ve teslimat üzerinden geri dönüş şeklinde açıklar. Teslimat outbound veritabanını bağımsız olarak yoklar ve 60 saniyelik host taraması, süresi gelen ve yinelenen mesajları bağımsız olarak uyandırır. Inbound, Telegram poller'ına bağlı olan tek aşamadır — issue #3728'in bildiricisinin, yaklaşık dört gün süren tam inbound sessizliği boyunca host'un etkin kaldığını, outbound teslimatının çalışmayı ve zamanlanmış görevlerin tetiklenmeyi sürdürdüğünü, 11.178 ardışık başarısızlığın kaydedildiğini görmesinin nedeni tam olarak budur.
Bunu yakalaması gereken sağlık kancası bu sorunu yakalamıyor. NanoClaw'un yayımlanmış adapter arayüzü referansı, isConnected() yönteminin "host tarafından testler dışında şu anda çağrılmadığını" ve "bridge'in her zaman true değerini döndürdüğünü" söylüyor. Trunk o zamandan beri ilerledi: adapter başına bağlantı durumunu bildiren bir ncl status komutu, v2.3.0 sürümünden sonra 15 Eylül 2026'da main dalına eklendi; bu da belgeleri yayımlanmış her sürüm için doğru, trunk için ise güncelliğini yitirmiş kılıyor. Bu komutu bir tavsiye olarak değil, henüz yayımlanmamış dahili bir özellik olarak değerlendirin — gizli ve yalnızca host'a özel olarak kaydedilmiş, hiçbir belgede yer almıyor. Telegram için iki yol yine birleşir: adapter'ın ne 4.29.0 ne de 4.41.0 sürümü isConnected yöntemini uygular (bu sayfa için her iki dist derlemesinde de arama yapıldı); dolayısıyla probe her iki durumda da true değerine geri döner.
Belgelerde buna karşılık gelen bir boşluk da vardır. Sorun giderme sayfası "Webhook channel is silent" başlıklı bir bölüm içerir ancak polling eşdeğeri yoktur; "Agent never replies" walkthrough'u ise ncl dropped-messages list ile birlikte "Did the router accept it?" sorusundan başlar — bu adım mesajın host'a ulaştığını zaten varsayar. Poller ölü olduğunda bulunacak düşürülmüş mesaj satırları yoktur, çünkü router mesajı hiç görmemiştir. Issue #2989 kendi nedeni için aynı çıkmazı kaydeder: günlük satırı yok, düşürülmüş mesaj satırı yok, hata ayıklanacak hiçbir şey yok.
Bir düzeltme sürümü yok; bu nedenle planınızı buna göre yapın
#3728 numaralı issue açık durumda; sıfır yorum, sıfır etiket ve milestone yok. Güncellenme zaman damgası hâlâ 6 Eylül 2026 olan oluşturulma zaman damgasına eşit. En yeni sürüm 24 Ağustos 2026 tarihli v2.3.0 ve 1 Eylül'den bu yana channels dalındaki tek commit Mattermost düzeltmesi. Eski filtre vakası için de durum aynı: açıkça belirtilmiş bir güncelleme listesini sabitleyecek pull request, 22 Ağustos 2026'dan beri channels dalına yönelik olarak açık ve mevcut dal kaynağında allowedUpdates ifadesi hiç geçmiyor. Yinelenen ana makine vakasını önleyecek tekil örnek ana makine kilidi, birleştirilmeden kapatıldı. Bu nedenle dürüst çerçeveleme bir sürüm numarası değil, azaltıcı önlemlerdir.
Kendi yamanızı yazmadan önce bilmeniz gereken üç şey var. Birincisi, src/channels/telegram.ts dosyasında yaptığınız yerel bir düzenleme kalıcı olmaz: add-telegram skill'i, dalın kanonik olduğu gerekçesiyle üzerine yazma talimatıyla bu dosyayı channels dalından kopyalar; update skill'i de kurulu her kanalı yeniler — #3728 raporlayan kişinin bu düzeltmeyi her güncellemede kaybetmesinin nedeni tam olarak budur. İkincisi, raporlayanın watchdog'u bir tarif olduğu kadar bir uyarıdır: yalnızca sayaca dayanan ilk sürüm, üç günlük daha kötü bir kesintiye yol açtı; çünkü poller hata vermek yerine durdu, böylece başka hiçbir hata kaydedilmedi ve sayaç eşiğine hiç ulaşmadı. İkinci sürüm iki bağımsız sinyal kullandı ve poller'ı hiç durdurmadı. Bunların hiçbiri yayımlanmış, onaylanmış veya bağımsız olarak doğrulanmış değildir. Üçüncüsü, ne oluşturursanız oluşturun, kurtarmayı her iki yönde test edin: giden başarılı iletişim gelen iletişim hakkında hiçbir şeyi kanıtlamaz; önemli kontrol, eşleştirilmiş sohbetten gönderilen yeni bir mesajın yeni bir gelen satır oluşturmasıdır.
Telegram kanalı arızası bir model veya API sorunu değildir
Bunu açıkça belirtmekte fayda var; çünkü bir sonraki bariz arama insanları yanlış yöne gönderir. NanoClaw'ın kimlik bilgileri belgeleri, TELEGRAM_BOT_TOKEN gibi kanal token'larının .env içinde tutulduğunu ve konteynerler tarafından değil ana makine süreci tarafından kullanıldığını; model kimlik bilgilerinin ise kasada bulunduğunu ve giden isteklere uçuş sırasında enjekte edildiğini söyler. Gelen mesajlar, herhangi bir sağlayıcı seçilmeden önce yönlendiriciye ve oturumun gelen veritabanına ulaşır; sağlayıcı konteyner başlatıldığında çözülür (agent providers belgeleri). Hiçbir temel URL, anahtar, gateway veya sağlayıcı değişikliği bozuk bir polling döngüsünü, eski bir güncelleme filtresini, poller çakışmasını, Group Privacy sorununu ya da bozuk bir IPv6 rotasını onaramaz.
Gerçek kesişim ters yönde gerçekleşir. NanoClaw README'si, Claude Code'u özellikle /customize, /debug ve her /add-channel skill'i için gereksinimler arasında listeler; dolayısıyla agent gruplarınız başka bir şey üzerinde çalışsa bile bir kanalı onarmak için Claude Code'un ana makinede bulunması gerekir. Ana makine gereksinimleri macOS veya Linux, WSL2 üzerinden Windows, Node.js 22 veya üstü, pnpm 10 veya üstü ve Docker'dır — ayrıca nanoclaw.dev hâlâ Node.js 20 veya üstünü duyururken README ile v2.3.0 changelog'unun 22'yi zorunlu alt sınır yaptığına dikkat edin. Artışı breaking olarak adlandıran changelog'u esas alın.
NanoClaw ve Telegram kanalının gerçek maliyeti
| Kalem | Maliyeti | Kaynak |
|---|---|---|
| NanoClaw'ın kendisi | $0, MIT lisanslı, ücretli katman yok ve kullanıcı hesabı yok | nanoclaw.dev: "NanoClaw, MIT lisansı kapsamında ücretsiz ve açık kaynaklıdır." |
| Topluluk portalı hesabı | Ücretsiz ve isteğe bağlı; geri kalan her şey onsuz çalışır | Proje README'si |
| Telegram bot token'ı | BotFather'da oluşturmak $0'dır ve eşleştirilmiş tek bir sohbet için satın alınacak hiçbir şey yoktur — Telegram'ın isteğe bağlı Paid Broadcasts katmanı yalnızca saniyede 30 mesajın üzerindeki kullanım için geçerlidir | Telegram Bot API; kanal belgelerine göre polling modu ayrıca herkese açık URL, webhook veya açık port gerektirmez |
| Model kullanımı | Bağlı sağlayıcının talep ettiği ücret neyse odur; NanoClaw bunun için ayrıca hiçbir ücret talep etmez | nanoclaw.dev SSS: "Agent sağlayıcınız model kullanımı için ücret talep edebilir." |
| Docker | Ana makinede gereklidir; Docker'ın kendi abonelik koşulları, ücretsiz kullanım eşiklerinin üzerindeki kullanım için geçerlidir | Bu sayfa için kontrol edilmedi — bütçelendirmeden önce Docker'ın fiyatlandırma sayfasını okuyun |
Yanıt vermeyen bir bottan ücretli bir katman satın alarak kurtulamazsınız; bu tablonun size söylediği yararlı şey budur. Para, ancak kanal yeniden çalışıp agent yanıt vermeye başladığında devreye girer. Aşağıdaki rakamlar ölçülmüş görev maliyetleri veya fatura tavanı değil, açıklayıcı token hesaplarıdır: günde 25 tur yapan, tur başına 20.000 önbelleğe alınmamış giriş ve 900 çıkış token'ı kullanan, 30 gün boyunca eşleştirilmiş tek bir sohbet varsayın. Ücretler, milyon token başına güncel Kunavo kataloğu fiyatlarıdır.
| Model | 1 milyon başına giriş / çıkış | Tahmini aylık tutar |
|---|---|---|
| Claude Haiku 4.5 | $0,70 / $3,50 | $12,86 |
| GPT-5.6 Terra | $0,70 / $4,20 | $13,34 |
| Claude Sonnet 4.6 | $2,10 / $10,50 | $38,59 |
| Claude Opus 5 | $3,50 / $17,50 | $64,31 |
Bunu bütçe olarak değerlendirmeden önce kendi trafiğinizle ölçeklendirin ve en çok etkisi olan varsayıma dikkat edin: hiçbir şey önbellekten sunulmuyor. Uzun ömürlü bir agent oturumu bağlamı yeniden gönderir; bu nedenle önbellek davranışı, bu sayıyı komşu iki model arasındaki token başı farktan daha fazla değiştirir. Kunavo katalog tutarı bir tavan değil, faturalandırma tabanıdır — upstream kendi ücretini bildirdiğinde fatura, katalog maliyeti ile geçerli markup uygulanmış upstream maliyetinin çarpımından büyük olanıdır. Minimum bakiye yükleme miktarı, görev ücreti veya abonelik değil, ön ödemeli kredide $10 finansman minimumudur; faturalandırma ayrıntılarına bakın.
| Agent'ın modeli için rota | Şu durumda avantajlıdır | Yapmadığı şey |
|---|---|---|
| Doğrudan sağlayıcı API'si | Tek bir sağlayıcının amiral gemisi modelinde kalmak ve o sağlayıcının kendi önbellekleme ile batch koşullarını kullanmak istiyorsunuz | İkinci bir sağlayıcı, ikinci bir hesap ve ikinci bir bakiye anlamına gelir |
| OpenAI uyumlu veya Anthropic uyumlu bir gateway | Agent grubuna göre model değiştirip tek anahtar ve tek bakiye istiyorsunuz | NanoClaw'ın yerleşik sağlayıcısı Claude Agent SDK'dır; bu nedenle özel bir temel URL'nin bu iletişim biçimini desteklemesi gerekir. OpenAI biçimindeki bir uç noktaya, modelleri OpenCode'un kendi yapılandırması üzerinden yönlendiren OpenCode sağlayıcı becerisi aracılığıyla ulaşılır |
| Abonelik | Sabit ücretli yoğun günlük kullanım, ölçümlü token'lardan size daha uygun | NanoClaw kendi aboneliğini satmaz; sabit ücret sağlayıcıya aittir |
| Yerel model | Barındırılan model faturası olmadan küçük veya özel işler | NanoClaw'ın kendi Ollama skill'i eski bir yapılandırma yolunu hedefliyor olarak açıklanır ve güncel main üzerinde desteklenen doğrudan bir geçiş seçeneği değildir |
Bu dört seçeneğin hiçbiri Telegram yoluna dokunmaz. Sağlayıcı tarafının tamamı — setup'ın okuduğu iki ortam değişkeni, konteynerin gerçekte gördükleri ve OpenCode ile Codex'in konumları — için NanoClaw API maliyetleri ve sağlayıcıları sayfasına bakın. Varsayılan Claude runtime'ını özel bir endpoint'e bağlayacaksanız, yapılandırmayı Claude Code entegrasyon kılavuzu ve temel URL başvurusu açıklar; bir anahtara bakiye yüklemeye hazır olduğunuzda Kunavo hesabı oluşturabilirsiniz. Kunavo NanoClaw'ı runtime üzerinde test etmemiştir ve yayımlanmış bir setup kılavuzu uyumluluk testi değil, yapılandırma başvurusudur.
Sık sorulan sorular
NanoClaw Telegram botum neden yanıt vermeyi kesti?
Mesajların host'tan hâlâ çıkıp çıkmadığını sorarak başlayın. Yanıtlar ve zamanlanmış mesajlar hâlâ geliyor ancak gönderdiğiniz hiçbir şey yanıtlanmıyorsa şüpheli inbound yoklamasıdır: NanoClaw issue #3728, adapter'ın polling döngüsünün getUpdates'i 30 saniyelik geri çekilme tavanıyla sonsuza kadar yeniden denediğini, hiç vazgeçmediğini ve başarılı bir yoklamada hiçbir şey günlüğe kaydetmediğini bildiriyor; dolayısıyla hata görünmez. Hiçbir şey gönderilmiyorsa ve günlükte "Message delivered" girdileri, platformMsgId=undefined ile birlikte "No adapter for channel type" uyarıları görülüyorsa NanoClaw'un kendi /debug becerisi aynı anda çalışan iki servis örneğini neden olarak gösteriyor. Bu iki durumun çözümleri zıttır; bu yüzden herhangi bir şeyi değiştirmeden önce belirtiyi tespit edin.
NanoClaw Telegram polling hatasının sabitlenmiş bir sürümü var mı?
Hayır, 21 Eylül 2026 itibarıyla yok. #3728 numaralı sorun kaydı açık; sıfır yorum, sıfır etiket ve atanmış bir kilometre taşı yok, güncellenme zaman damgası da kaydın açıldığı tarih olan 6 Eylül 2026 ile hâlâ aynı. En yeni NanoClaw sürümü 24 Ağustos 2026 tarihli v2.3.0; dolayısıyla sorunun bildirilmesinden bu yana hiçbir şey yayımlanmadı ve 1 Eylül'den bu yana channels dalındaki tek commit bir Mattermost düzeltmesi. Bunun için belirli bir NanoClaw sürümüne yükseltmenizi söyleyen kişi, var olmayan bir sürümün adını veriyor.
@chat-adapter/telegram'ı yükseltmek sorunu çözer mi?
Sessiz ölüm yolunu çözmez. NanoClaw, @chat-adapter/telegram'ı tam olarak 4.29.0 sürümüne sabitler; bu sürüm 18 Mayıs 2026'da yayımlandı, npm'nin en yeni dist-tag'i ise 18 Eylül 2026 tarihli 4.41.0'dır. Bu sayfa için her iki tarball indirildi ve karşılaştırıldı: getUpdates aktarım hatası dalı iki derlemede esas itibarıyla aynıdır — aynı consecutiveFailures sayacı, aynı 30 saniyelik yeniden deneme bekleme süresi üst sınırı, aynı uyarı satırı; ne vazgeçme ne de hatayı üst düzeye iletme var ve başarılı bir yoklama hâlâ günlüğe hiçbir şey kaydetmiyor. 4.41.0 döngünün diğer bölümlerini yeniden yazdı. Bu sayfa bunu kodla ilgili bir gerçek olarak belirtir ve sabitlenen sürümü yükseltmeyi önermez: NanoClaw'un add-telegram becerisi tedarik zinciri politikasının sürüm aralıklarını reddettiğini söylüyor, bu sayfa için incelenen iki sürüm yükseltme pull request'i (#3460 ve #3570) açık ve birleştirilmemiş durumda ve burada hiç kimse sürüm yükseltmenin başka neleri değiştirdiğini test etmedi.
API sağlayıcımı veya temel URL'yi değiştirmek Telegram sorununu çözer mi?
Hayır. NanoClaw'un kimlik bilgileri belgeleri, TELEGRAM_BOT_TOKEN gibi kanal token'larının .env dosyasında kaldığını ve host işlemi tarafından, container'lar tarafından değil, kullanıldığını; model kimlik bilgilerinin ise kasaya girdiğini ve container trafiğine enjekte edildiğini belirtir. Gelen bir Telegram mesajı, sağlayıcı çözülmeden önce router'a ve oturumun inbound veritabanına ulaşır; sağlayıcı çözümlemesi container başlatıldığında gerçekleşir. Bu nedenle farklı bir endpoint, anahtar veya gateway ölü bir polling döngüsünü, eski bir sunucu tarafı güncelleme filtresini, poller çakışmasını, Group Privacy'yi veya bozuk bir IPv6 yolunu onaramaz. Gerçek tek yönlü bağlantı tersinedir: NanoClaw README'si /debug ve tüm /add-channel becerileri için Claude Code'u gereksinim olarak listeler; dolayısıyla aracının başka bir yerde çalıştığı bir kurulumda bile kanal onarımı için host'ta bulunması gerekir.
Bot doğrudan mesajları yanıtlıyor ama grubu yok sayıyor. Neden?
Bu genellikle bir NanoClaw hatasından ziyade Telegram'ın Group Privacy ayarıdır. NanoClaw'un add-telegram becerisi, Group Privacy açıkken botun normal metinleri değil, yalnızca kendisine yöneltilen komutları ve yanıtları gördüğünü; bunu BotFather'da /mybots, botunuz, Bot Settings, Group Privacy altında kapatmanız ve değişikliğin etkili olması için botu gruptan çıkarıp yeniden eklemeniz gerektiğini belirtir. Benzer görünen ancak farklı olan ayrı bir durum da vardır: NanoClaw issue #2989, daha önce daha dar bir allowed_updates filtresiyle yoklanan bir bot token'ının bu filtreyi sunucu tarafında sonsuza kadar koruduğunu; bunun kanal gönderilerini sessizce düşürdüğünü, doğrudan mesajların ve grupların ise çalışmaya devam ettiğini bildiriyor.
Eşleştirme hiç tamamlanmıyor ama bot hâlâ çalışıyor. Sorun nedir?
NanoClaw issue #3162 tam olarak bu durumu anlatıyor: kanal başlatılırken getMe çağrısı bir kez başarısız olursa bot kullanıcı adı tüm işlem ömrü boyunca null olarak önbelleğe alınır ve gönderdiğiniz her eşleştirme kodu sıradan bir mesaj olarak değerlendirilir; hiçbir deneme kaydedilmez ve yükleyici sonsuza kadar bekler. Tek iz, eşleştirmeyi denemenizden dakikalar önce açılışta görülen tek bir uyarı satırıdır ve issue, başka hiçbir değişiklik olmadan yeniden başlatmanın sorunu çözdüğünü söylüyor. Mevcut channels dalı adapter'ı bu aramayı hâlâ bir kez yapıyor, yeniden denemiyor ve sonucu önbelleğe alıyor. Ayrıca NanoClaw belgeleri, çalıştırma başına en fazla 5 kez yeniden oluşturulabilen tek kullanımlık 6 haneli bir kodu tanımlarken issue #3162 bunu 4 haneli kod olarak adlandırıyor; belgeleri esas alın.
21 Eylül 2026'da kontrol edildi: nanocoai/nanoclaw repository kaydı ve sürüm listesi; #2377, #2989, #3162, #3569 ve #3728 numaralı issue'ların ve #2225, #2697, #3449, #3460 ve #3570 numaralı pull request'lerin açık/kapalı durumları; channels dalındaki Telegram adapter kaynağı; npm'den alınan sabitlenmiş 4.29.0 ve güncel 4.41.0 adapter derlemeleri; NanoClaw'ın kanal, kimlik bilgileri, sorun giderme ve adapter-interface belgeleri; add-telegram ve debug skill'leri; ayrıca Telegram'ın Bot API sayfası. Bu sayfadaki hiçbir şey çalışan bir NanoClaw kurulumunda çalıştırılmadı. Kunavo token ücretleri canlı katalogdan alınmıştır ve dolar rakamları açıklayıcı token hesaplarıdır.