Bir geliştirici, sayfasındaki hatayı bulması için bir kodlama ajanını tarayıcıya bağladığında ilk beklenti basittir: ajan ekranı açsın, ağ isteklerini izlesin, sorunu anlatsın. Fakat tarayıcı hata ayıklama aracı çoğu zaman ekrandan fazlasına dokunur. Sayfada JavaScript çalıştırabilir, ağ yanıtlarını okuyabilir, ekran görüntüsü ya da indirme yoluyla dosya yazabilir; bağlı olduğu oturumun çerezleri ve açık sekmeleri de bu bağlamın parçası olabilir.
Chrome DevTools ekibi, eylül ayındaki güncellemesinde bu sınırı daha ayrıntılı yönetmek için iki önemli kapı ekledi: ajanın JavaScript değerlendirmesini kapatma ve yerel dosya erişimini çalışma alanı kökleriyle sınırlama. Resmî sürüm notu, bu denetimleri ajanlar için duyuruyor. Bu ayarlar, inceleme sırasında ajanın komut çalıştırmasını ve erişebileceği dosya alanını baştan sınırlıyor.
JavaScript değerlendirmesini kapatan ayar, ajanın verdiği kodu inceleme sayfasında çalıştıran araçları devre dışı bırakıyor. Başlangıç betiği eklemeyi ve `javascript:`, `data:` ya da `vbscript:` adreslerine gitmeyi de engelliyor. Bu, canlı bir sitede sorunu anlamaya çalışan ekip için faydalı bir ilk ayrım. Ajan, DOM'u ve ağ kaydını okuyabilir; kendi komutuyla sayfanın durumunu değiştiremez.
Yine de bu düğmeyi “salt okunur tarayıcı” sözü gibi görmek yanıltır. Yapılandırma belgesi, sayfanın kendi betiklerinin çalışmayı sürdürdüğünü; izin verilen bir tıklama veya yazma işleminin de JavaScript tetikleyebileceğini açıkça söylüyor. Açık bir alışveriş sepeti, yönetim paneli veya müşteri destek hesabı üzerinden bağlanan ajan için fark büyük. Komut değerlendirme kapanmış olsa bile, etkileşim aracı gerçek bir düğmeye basıyorsa tarayıcıdaki oturum o işi yapabilir.
Bu nedenle ekiplerin önce bağlantı türünü seçmesi gerekir. Üretim hesabına bağlı günlük tarayıcı profili, hata ayıklama ajanı için güvenli bir başlangıç olamaz. İnceleme işi ayrı bir profil, sınırlı yetkili test hesabı ve mümkünse verisi ayıklanmış bir ortamla yapılmalı. Aynı tarayıcı profilinde hem kullanıcının oturum verisi hem ajanın etkileşim araçları bulunursa, yeni bir araç işlevi bu oturumun erişebildiği işlemleri de ajana açabilir.
Dosya tarafında da benzer bir ayrım var. DevTools MCP, istemcinin bildirdiği ya da başlatılırken tanımlanan kök dizinleri kullanabiliyor; kök tanımlanmamışsa yerel dosya araçları için varsayılan sınır işletim sisteminin geçici dizini. Geniş yol erişimini açan seçenek, kök bildiremeyen güvenilir bir istemci için düşünülmüş. Bu seçenek bir projenin tamamını ajana açmadan önce sorulması gereken soruyu ortadan kaldırmıyor: Ajanın bu hatayı incelemek için hangi klasöre gerçekten ihtiyacı var?
Burada geliştiricinin yükü araç seçimiyle bitmez. Ajanın hangi URL'lere gidebileceği, hangi sayfalarda tıklama yapabileceği, indirme ve ekran görüntüsü çıktılarının nereye yazılacağı görev tanımına eklenmeli. DevTools MCP'nin güvenlik notları, URL kalıpları ve MCP köklerinin tam bir ağ ya da dosya sistemi yalıtımı sağlamadığını özellikle hatırlatıyor. Güvenilmeyen sayfa metni de ajanın önüne talimat gibi düşebilir; bu yüzden istemci, sayfadan gelen içeriği komut talimatından ayırmayı kendi tarafında kurmak zorunda.
Yakın gelecekte hata ayıklama ekranı, kod yazan ajanın doğal çalışma masasına dönüşecek. Ekip önce inceleme için JavaScript değerlendirmesini kapatıp dar bir tarayıcı profili seçmeli; deneme gerektiğinde ayrı test oturumuna geçmeli; yazma iznini de somut çalışma alanına ve kısa süreli göreve bağlamalı. Böyle kurulan kayıtta, hangi komutun hangi kullanıcı verisine değdiği ve hangi klasöre çıktı yazdığı sonradan incelenebilir.
