Cline hatası VS Code Remote-SSH üzerinden komut çıktısını ve çıkış durumunu sessizce kaybediyor

Rapor ne diyor

dev.to'da yayımlanan bir rapora göre, bir Linux sanal makinesine bağlanan VS Code Remote-SSH oturumu üzerinden Cline 4.0.12 kullanan bir kullanıcı, eklentinin execute_command aracının çalıştırdığı shell komutlarının gerçek stdout, stderr ve exit status değerlerini attığını fark etti. Shell'de gerçekte ne olursa olsun, modele geri iletilen sonuç genel bir başarıydı. Kullanıcı sorunu Cline'ın GitHub takipçisinde 12723 numaralı issue olarak kaydetti.

Pratikteki sonuç, gerçekte başarısız olan bir Ruff lint kontrolünün geçmiş olarak kaydedilmesiydi. Dev.to gönderisinde aktarıldığı üzere muhabir, hatanın "bir Ruff başarızlığını geçmiş gibi göstermesine ve proje issue takipçisine yanlış doğrulama kanıtı işlenmesine neden olduğunu" söylüyor. Bir agentic workflow için bu, olabilecek en kötü hata biçimlerine yakın: ajan kendi doğrulama kanıtını üretiyor, kanıt yanlış ve süreç boyunca hiçbir yerde hata sinyali verilmiyor.

Yeniden üretim

Gönderide anlatılan minimal yeniden üretim bilinçli olarak küçük: stdout ve stderr'ye farklı işaretler yazan ve ardından 7 durumuyla çıkan tek satırlık bir bash komutu. VS Code terminali her iki çıktı akışını ve exit code'u doğru gösterdi. Cline'ın araç sonucu ise yine başarı bildirdi. İnsanın görebildiği terminal ile modelin aldığı sonuç iki farklı hikâye anlatıyordu.

Gönderi, aynı yanlış pozitif davranışın hem Cline 4.0.11 hem de 4.0.12'de yeniden üretildiğini ekliyor; yani hata, biri tarafından bildirilmeden önce bir sürüm döngüsünden sağlam çıkmıştı.

Raporun ortaya koymadığı şeyler

Dev.no yazarı değil, dev.to yazarı bulgunun sınırları konusunda açık: Bu, tek bir dosyalanmış, doğrulanmış ve yeniden üretilebilir rapor ve özellikle VS Code'un Remote-SSH terminal moduna odaklı. Aynı hatanın Cline'ın diğer terminal entegrasyonlarında da yaşandığını göstermiyor ve maintainers henüz bir kök neden doğrulamış ya da bir düzeltme yayımlamış değil. Gönderi ayrıca, bu örnekte veri kaybı yaşanmadığı ve yanlış sonuca dayanarak bir şey deploy edilmediği gerekçesiyle soruna 3.8 gibi düşük bir önem puanı veriyor.

Neden önemli

Bu tek vakadaki dar etki alanı, hata sınıfını zararsız kılmıyor. Bir ajan ile araçları arasındaki temel sözleşme, kendi bildirdiği komut çıktısının gerçeği yansıtmasıdır; başarısız bir kontrol geçmiş olarak dönebiliyorsa, ajanın verdiği her aşağı akış kararı uydurulmuş kanıta dayanır. Lint, test ve build sonuçları, geliştiricilerin elle yeniden çalıştırmadan en çok güvenme eğiliminde olduğu çıktılardır ve bu hata o güveni sessizce kırdı.

VS Code terminalinin hâlâ doğru çıktıyı göstermesi iki yönlü çalışıyor. Yakından izleyen bir insan tutarsızlığı yakalayabilirdi, ancak ajan yalnızca araç sonucunu görüyor ve araç sonucu yanlıştı. Sessiz başarı, gürültülü bir hatadan daha zor yakalanır: execute_command hata verseydi, başarısızlık modele ve çevresindeki döngüye görünür olurdu; sessiz bir geçiş hiçbir sinyal vermez.

Uzaktan geliştirme kurulumları üzerinde kodlama ajanları çalıştıran ekipler için makul tepki paniğe kapılmak değil, ölçülü olmaktır. Bu hata sınıfı elenene kadar uzak yapılandırmalarda ajanın iddia ettiği komut başarılarına bir miktar şüpheyle yaklaşın, kritik adımlarda exit code'ları kontrol edin veya anahtar kontrollerin yanlış bildirilmesi daha zor olan artefaktlar üretmesini sağlayın. Daha geniş bir çerçevede bu, bir eklenti, uzak shell ve ajanın context window'u arasındaki entegrasyon katmanının, çıktının ne insana ne de modele herhangi bir hata göstermeden kaybolabildiği bir yer olduğunun hatırlatıcısıdır.