dsh eklentileri nasıl çalışır ve nasıl denetlenir?

dsh eklentisi nedir ve ne işe yarar?

dsh eklentileri, DeepSeek Harness'ın kendi süreci içerisine yüklediği Node paketleridir. Bir eklenti yüklemek, başka birinin kodunu, temsilcinizin (agent) izinleriyle ve temsilcinizin zaten erişebildiği makine üzerinde çalıştırmak anlamına gelir. Yüklenen bir eklenti ile harness'ın geri kalanı arasında hiçbir engel yoktur. Bu nedenle, bir eklenti yüklemeden önce sorulması gereken soru, o kodun nelere erişebileceği ve bu erişim alanının nasıl kısıtlı tutulacağıdır.

dsh (DeepSeek Harness), DeepSeek AI'ın Cordis adlı bir eklenti çatısı üzerine inşa edilmiş açık kaynaklı temsilci harness'ıdır. Projenin kendi README dosyası, her şeyin bir eklenti olduğunu belirtir. Model bağdaştırıcısı bir eklentidir. Yazı yazdığınız web arayüzü bir eklentidir. Proje dışından yüklediğiniz her şey, aynı ağaç yapısında ve proje ile birlikte gelen parçalarla aynı güven seviyesinde yer alır. Eğer henüz bir kurulum yapmadıysanız, VPS üzerinde DeepSeek Harness ile başlayın ve herhangi bir ekleme yapmadan önce buraya geri dönün.

Bir eklentinin erişebileceği genişletme noktaları, deponun AGENTS.md kısmında listelenmiştir. Ağustos 2026 itibarıyla bunlar şunları kapsar:

• LLM (büyük dil modeli): API anahtarınızın ödeme yaptığı sağlayıcı
• Shell: yerel ve pwsh sağlayıcıları ile bash yeteneği
• Dosya sistemi: politika kontrollü dosya erişimi
• Web: arama ve veri getirme sağlayıcıları
• Alt süreç (Subprocess): bir süreç ağacı sağlayıcısı
• İş akışı: çalışan iş parçacıkları (worker threads)
• Alt temsilci (Subagent): diğer temsilcilere yetki devri
• Ayarlar ve kimlik bilgileri: kayıtlı yapılandırmanız ve ortam değişkenleriniz

Bir eklenti ayrıca ctx.tools üzerinde araçlar kaydeder ve belgeler, kayıtlı bir aracın şemasının istem (prompt) oluşturma sürecine dahil edildiğini açıkça belirtir. Bu ikinci kısım, insanların gözden kaçırdığı noktadır. Bir eklenti, kendi kodu olağan dışı bir şey yapmasa bile temsilcinizin ne yapacağına karar verme sürecini değiştirebilir; çünkü sağladığı açıklama, modelin okuduğu metnin bir parçası haline gelir. Bu, kodlama temsilcilerine yönelik istem enjeksiyonu ile aynı yapıdaki bir sorundur; tek bir farkla: bu metin siz yükleme yaptığınızda gelir ve siz eklentiyi kaldırana kadar orada kalır.

dsh eklentileri nasıl bulur ve yükler?

Global bir eklenti dizini bulunmamaktadır. Çalışan bir dsh, önyükleme sırasında sıralı katmanlardan oluşturulan bir eklenti ağacıdır ve seçimlerinizi barındıran birim bir profildir. $DSH_HOME varsayılan olarak ~/.dsh değerini alır ve her profil $DSH_HOME/profiles/<name> dizininde yaşar. web ve headless profilleri, ilk kullanımda sağlanan şablonlardan kendilerini oluşturur.

Bir profil dizini, her şeyi belirleyen iki dosya barındırır:

• package.json, ağaç dışı eklenti bağımlılıkları ve sıralı bundles listesini taşıyan bir dsh.profile manifestosu ile birlikte
• cordis.patch.yml, bu paketler üzerindeki kendi yama katmanınız

ls ~/.dsh
ls ~/.dsh/profiles/web

Önyükleme, katmanları bu sırayla uygular ve sonraki katmanlar önceliklidir:

1. boş bir kök dizin
2. manifestonun listelediği sırayla profilin paketleri
3. profilin cordis.patch.yml dosyası
4. $DSH_HOME/cordis.patch.yml
5. komut satırından aktarılan tüm --patch <path> katmanları

İki bayrak, hiçbir şeyi başlatmadan bu kompozisyonun sonucunu yazdırır:

dsh --profile web --dump-default-config
dsh --profile web --dump-config

--dump-default-config, oluşturulan ağacı kendi başına yazdırır. --dump-config, profil ve ev dizini yama katmanlarını ekler; bu nedenle bir sonraki önyüklemenizde nelerin yükleneceğinin en doğru envanteridir. Devraldığınız bir makineye güvenmeden önce bunu okuyun.

Bu yama dosyaları hakkında bir uyarı: Yapılandırma burada durağan bir veri değildir, çünkü format bir eklentinin config bloğu altında !!js etiketli değerlere izin verir. Bir forum gönderisinden kopyalanan bir cordis.patch.yml parçası koddur, bu nedenle ona aynı kaynaktan gelen bir shell betiğine nasıl davranıyorsanız öyle davranın.

dsh plugin add tam olarak ne çalıştırır?

dsh plugin --profile <name> <args>, argümanlarını ilgili profil dizini içindeki pnpm'e iletir; bu nedenle pnpm'in PATH üzerinde bulunması gerekir. Kullanılan fiiller pnpm'in kendi fiilleridir:

dsh plugin --profile web add '<package-or-git-spec>'
dsh plugin --profile web remove '<package-name>'
dsh plugin --profile web why '<package-name>'
dsh plugin --profile web update

Bir dsh eklentisi kurmanın güvenlik modeli, herhangi bir npm tarzı bağımlılığı kurmanın güvenlik modeliyle aynıdır; buna ek olarak sonucun agent'ınıza yüklendiği bir adım daha bulunur. Paket kendi bağımlılık ağacını beraberinde getirir ve bu ağaçtaki her paket aynı süreç içinde çalışır. npm tedarik zinciri saldırılarının bir sunucuya nasıl ulaştığına dair her şey, hiçbir değişiklik olmaksızın burada da geçerlidir.

pnpm 10 ve sonraki sürümler, varsayılan olarak bir bağımlılığın derleme betiklerini çalıştırmaz; onay işlemi onlyBuiltDependencies veya pnpm approve-builds aracılığıyla paket bazında yapılır. Hangi pnpm sürümüne sahip olduğunuzu kontrol edin:

pnpm --version

Bu varsayılan ayar oldukça değerlidir ve aynı zamanda ekosistemdeki en çok göz ardı edilen güvenlik özelliğidir. Engellenen derleme betikleri, kurulum sırasında kodun çalışmasını durdurur. Ancak eklentinin kendisi üzerinde hiçbir etkileri yoktur; çünkü bir eklentinin temel amacı, harness'ın onu içe aktarması ve bir sonraki başlatmada çağırmasıdır. Bir eklentinin postinstall kancasına ihtiyacı yoktur. Eklenti zaten içeri davet edilmiştir.

Bir dsh eklentisi kurmadan önce okunması gerekenler

Yayınlanmış tarball dosyasını indirin ve okuyun. Bir arşivi açtığınızda hiçbir şey çalıştırılmaz.

npm pack '<package-name>@<version>'
tar -tzf '<package-name>-<version>.tgz'
tar -xzf '<package-name>-<version>.tgz'
less package/package.json

package.json içindeki dört alan, ihtiyacınız olan bilgilerin çoğunu size sunar. preinstall, install ve postinstall girdileri için scripts dosyasını okuyun. Tanımadığınız veya bildiğiniz isimlere çok benzeyen isimler için dependencies dosyasını inceleyin. Paketin PATH üzerinde ihtiyaç duyduğu her şey için bin dosyasını okuyun. Giriş dosyası için main veya exports dosyasına bakın, ardından bu dosyayı açın ve içeriğini takip edin.

Daha sonra gerçekten yüklenecek olan kodu okuyun. Bir bildirim aracı olduğunu iddia eden eklentinin ~/.ssh dosyasını okuması, daha önce hiç duymadığınız bir sunucuya çağrı yapması veya bir shell başlatması için hiçbir neden yoktur. Eğer paket yalnızca paketlenmiş veya küçültülmüş (minified) JavaScript içeriyorsa ve halka açık bir depoda eşleşen kaynak kodu bulunmuyorsa, bu durum sizin için bir yanıt niteliğindedir. Kaynak kodunu okuyabildiğiniz eklentileri tercih edin ve küçük boyutlu olanlara öncelik verin.

Ayrıca hiçbir şey kurmadan önce kayıt defterini sorgulayabilirsiniz:

pnpm view '<package-name>' dependencies
pnpm view '<package-name>' versions

Geçen hafta yayınlanmış, tek bir sürümü olan, repository alanı bulunmayan ve popüler bir paketin ismini taklit eden bir paket, her kayıt defterindeki en eski numaradır. İndirmeleri sağlama toplamları ile doğrulama bir sonraki adımdır: çalıştırmasına izin vermeden önce ne indirdiğinizi tam olarak bildiğinizden emin olun.

Sürümü sabitleyin ve kilit dosyasını koruyun

Değişken bir sürüm aralığı, aracı sürecinizdeki kodun, siz herhangi bir karar vermeden her kurulum veya güncellemede değişebileceği anlamına gelir. Sürümü sabitleyin.

dsh plugin --profile web add --save-exact '<package-name>@<version>'

Bayrak yerleşimi pnpm sürümleri arasında farklılık gösterir, bu nedenle komuta güvenmek yerine sonucu kontrol edin. Daha sonra profilin package.json dosyasını açın ve bağımlılığın önünde ^ veya ~ olmadan yalın bir sürüm olarak göründüğünü doğrulayın. Kurulacak olanı bu dosya belirler.

Ardından, yalnızca en üst düzey ismi değil, tüm geçişli ağacı sabitleyen kilit dosyasını koruyun:

find ~/.dsh -maxdepth 3 -name 'pnpm-lock.yaml'

Bunu, profilin package.json dosyasıyla birlikte yedeklediğiniz bir yere kopyalayın. Bu iki dosya, yeni bir makinede aynı ağacı yeniden oluşturur. dsh plugin --profile web update komutunu yalnızca sürüm yükseltmeye karar verdiğinizde çalıştırın, rutin bir temizlik işlemi olarak asla kullanmayın ve sonrasında kilit dosyasındaki farkları inceleyin.

Bir kayıt defteri yerine git üzerinden kurulan eklentiler için dalı değil, commit değerini sabitleyin. github:owner/repo#<full commit sha> biçimindeki bir belirtim size sabit bir ağaç sağlar. Bir dal ismi ise pnpm bir sonraki çözümleme yaptığında o dalda ne varsa onu getirir; bu, kontrolü başkasına devrettiğiniz bir karardır. Harness'ın kendisi de aynı disiplini gerektirir, çünkü yayınlanan her dsh yapısı bir sürüm adayıdır ve sabitlenmemiş bir kurulum herhangi bir günde farklı bir sürüme çözümlenebilir; dsh kurulum ve sürüm hataları vakalarının çoğu bu durumdan kaynaklanır.

Eklenti pazarı ve "küratörlü" olmanın değeri

dsh bir pazar yerine sahiptir ve bir eklenti olarak kurulur; bu durum mimari hakkında size bir fikir verir:

dsh plugin --profile web add dshmarket

Yeniden başlatmanın ardından Ayarlar ve sonrasında Eklenti Pazarı altında görünür. README dosyası sınırlamalar konusunda açıktır. Kurulumlar, küratörlü bir kayıt listesinde yer alan kaynaklarla sınırlandırılmıştır ve diğer her şey reddedilir. Derleme betikleri varsayılan olarak engellenmiştir ve birini etkinleştirmek paket bazında onay gerektirir. Terminal eklentileri, bir web profiline girmeden önce işaretlenir. En önemli cümle, listelemenin bir onay anlamına gelmediğidir; çünkü eklentiler üçüncü taraf kodlarıdır.

Küratörlü bir liste, taban seviyesini yükseltir. Sizin yerinize kodu okumaz ve bir eklentinin yeni sürümünün, geliştirici hesabı el değiştirdikten sonra ne yapacağını size söyleyemez. Tek tıkla kurulumu, aynı yazardan gelen curl | bash dosyasına nasıl yaklaşıyorsanız öyle değerlendirin. README dosyasındaki şu satırı tekrarlamakta fayda var: dışa aktarılan bir yedekleme, profil yapılandırmanızdan kimlik bilgileri içerebilir; bu nedenle bunları asla herkese açık bir hata kaydına veya bir metin paylaşım sitesine eklemeyin. Bir yöntemden ziyade başlangıç listesi arıyorsanız, kurulmaya değer dsh eklentileri bu yazının tamamlayıcı içeriğidir.

dsh aracını root yerine kendi kullanıcısı ile çalıştırma

İnceleme süreçleri, kötü niyetli yazılımların sisteme sızma olasılığını azaltır. En az yetki prensibi ise, bir sızıntı durumunda bu yazılımın nelere erişebileceğini belirler. Bir VPS üzerinde bu ikinci adımı uygulamak oldukça kolaydır.

Harness için kendi ev dizinine sahip ayrı bir unix hesabı oluşturun ve aracı asla root yetkileriyle çalıştırmayın:

sudo adduser --disabled-password --gecos "" dshrun
sudo -iu dshrun

Bu oturum içerisinde, harness aracını kendi ev dizinine yazacak şekilde başlatın:

npx @deepseek-ai/dsh web

Web arayüzü varsayılan olarak http://127.0.0.1:3080 portundan hizmet verir. Bu ayarı değiştirmeyin. Bu porta erişebilen herkes, shell yetkisine sahip bir ajanı yönetebilir; dolayısıyla 3080 portunu dış dünyaya açmak, root yetkisi olmayan ancak kullanıcı dostu bir arayüze sahip bir uzak shell açmakla aynı anlama gelir. Arayüze bunun yerine dizüstü bilgisayarınızdan bir SSH tüneli üzerinden erişin:

ssh -L 3080:127.0.0.1:3080 you@your-vps

Ardından, genel bir IP adresi üzerinde dinleme yapan bir servis olmadığından emin olun:

ss -lnt | grep 3080

Yerel adres 127.0.0.1:3080 olarak görünmelidir. Eğer 0.0.0.0:3080 olarak görünüyorsa, yabancı bir kullanıcı ile ajanınız arasındaki tek engel güvenlik duvarınızdır. Claude Code aracını bir VPS üzerinde güvenli çalıştırma konusundaki mantık, dsh için de aynen geçerlidir. Ajana, bozmasına izin verilen tek bir çalışma dizini atayın ve yeniden oluşturamayacağınız hiçbir veriyi bu makinede tutmayın. Hatta bu makineyi kodlama ajanları için tek kullanımlık bir VM olarak değerlendirin; çünkü bir VPS'i yeniden kurmak bir saat sürerken, güvenliğini denetlemek bir hafta sürebilir.

Anahtarlarınızın konumu ve dosya izinlerinin neden sınırlı bir koruma sağladığı

dsh, API anahtarlarını $DSH_HOME/.credentials.yaml içinde, ortam değişkenlerini $DSH_HOME/.env içinde, model ayarlarını $DSH_HOME/settings.yaml içinde ve oturum geçmişini $DSH_HOME/storages altında tutar. Hangi anahtarın bu dosyalardan hangisine ait olduğu ve her modda dışarıya tam olarak neyin gönderildiği, dsh API anahtarlarını, modellerini ve uç noktalarını yapılandırma konusunun kapsamındadır. Bir eklenti eklemeden önce bu konuyu netleştirmek önemlidir; çünkü sisteme dahil ettiğiniz her anahtar, bir eklentinin okuyabileceği yeni bir veri demektir. Hassas olan iki dosyayı şu şekilde kilitleyin:

chmod 600 ~/.dsh/.credentials.yaml ~/.dsh/.env
ls -l ~/.dsh

600 modu, dosya sahibine okuma ve yazma yetkisi verirken diğer tüm kullanıcılara hiçbir yetki tanımaz; bu durum her iki gösterim biçimi için de bilinmesi gereken bir konudur (sayısal ve sembolik chmod modları). Bu modun sağladığı korumanın sınırları konusunda gerçekçi olun. Dosya modları, ilgili dosyaları sunucudaki diğer hesaplardan korur. Ancak bir eklentiye karşı hiçbir koruma sağlamazlar; çünkü eklenti, dosyaların sahibi olan kullanıcı yetkileriyle ve dosyaları okuyan sürecin içinde çalışır. Sırları bir yapay zeka aracının erişiminden uzak tutmak ifadesinin, bu sırları makineye hiç koymamak anlamına gelmesinin nedeni budur. Bir dsh sunucusu, yalnızca ihtiyaç duyduğu tek bir model anahtarını barındırmalıdır. Bulut kimlik bilgileriniz ve imzalama anahtarlarınız başka bir yerde tutulmalıdır.

Web okuyan bir eklentinin tehdit modelini neden değiştirdiği

Web arayüzü, eklentilere arama ve veri çekme sağlayıcıları sunar. Bir sayfayı oturumunuza çeken eklenti, bir saldırganın yazabileceği metni içeri almaktadır. Model istemi, talimatları veriden ayırmaz; bu nedenle çekilen bir sayfa, temsilcinize yönelik bir komut içerebilir. Kabuk yeteneğine sahip bir altyapı, bu komutu çalıştırmaya sadece bir adım uzaklıktadır.

Denetim mekanizması halihazırda altyapıda mevcuttur. Her profildeki ilk paket olan dsh-base, sandbox ve onay politikasını içerir. Bunu kullanın. Güvenilmeyen sayfaları çekebilen bir oturum, yazma veya yürütme işlemi yapan her şey için onay gerektirmelidir; böylece çekilen bir talimat kendi başına bir eyleme dönüşemez. Temsilci eylemlerini onay mekanizması ile kısıtlama, bu sınırın nereye konulması gerektiğini açıklar. Bu ilişki her iki yönde de işler; zira kendi sunucunuz da bir başkasının temsilcisinin çekeceği bir sayfadır ve bu durum sunucunuzda yapay zeka tarayıcılarını engelleme konusunun temelini oluşturur.

Bir eklentinin neleri değiştirdiğini nasıl kontrol ederim?

Kurulumdan önce anlık görüntü (snapshot) alın, kurulumu yapın, kurulumdan sonra tekrar anlık görüntü alın ve aradaki farkı inceleyin.

dsh --profile web --dump-config > /tmp/dsh-before.txt
dsh plugin --profile web add '<package-name>@<version>'
dsh --profile web --dump-config > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt

Fark çıktısı (diff), kurulumun oluşturulan ağaca hangi eklenti girdilerini eklediğini gösterir. Küçük bir özellik için yüklediğiniz ancak açıklayamadığınız birçok girdi ekleyen bir eklenti, sistemi başlatmadan önce durup kaynak kodunu incelemeniz için bir nedendir. dsh plugin --profile web why <package-name> diğer soruyu yanıtlar: doğrudan bağımlılıklarınızdan hangisi belirli bir paketi içeri çekmiş.

Yüklü paketler $DSH_HOME/profiles/node_modules dizini altına yerleşir, bu nedenle ağacı disk üzerinde de inceleyebilirsiniz:

ls ~/.dsh/profiles/node_modules

Üzerinde deneme yapmadığınız ikinci bir profil tutun. Bir kurulum sistemi bozduğunda, dsh --profile <clean-name> ile başlatmak eklentinin buna neden olup olmadığını saniyeler içinde size söyler.

Bir dsh eklentisi nasıl kaldırılır?

dsh plugin --profile web remove '<package-name>'
dsh --profile web --dump-config > /tmp/dsh-after-removal.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after-removal.txt

Bağımlılığın kaldırılması, yapılandırmayı her zaman silmez. Profilin cordis.patch.yml dosyasına yazılan girdiler orada kalmaya devam eder; çünkü bu dosya size aittir ve araç sizin yerinize dosyayı yeniden yazmaz. Dosyayı açın ve kaldırdığınız paketi adlandıran tüm blokları silin.

less ~/.dsh/profiles/web/cordis.patch.yml

Ardından hiçbir kaldırma komutunun düzeltemeyeceği kısımla yüzleşin. Bir eklentiyi ona güvenmeyi bıraktığınız için kaldırdıysanız, okuyabildiği her şeyi zaten okumuş demektir. Sağlayıcı konsolundan DeepSeek API anahtarını döndürün (rotate) ve $DSH_HOME içinde bulunan diğer her şeyi de yenileyin. Sonrasında, eklentinin çalıştığı unix hesabının ağınızın geri kalanında nerelere erişebildiğini tespit edin.

Kısa özet

• Kurulumdan önce yayınlanan tarball dosyasını, scripts ve giriş dosyasından başlayarak inceleyin.
• Tam sürümü veya git spesifikasyonu için tam commit değerini sabitleyin ve lockfile dosyasını koruyun.
• Tek bir profile kurulum yapın ve bir sorun oluştuğunda önyükleme yapabileceğiniz temiz bir profil tutun.
• Her kurulumdan önce ve sonra --dump-config farklarını (diff) kontrol edin.
• Harness'ı kendi unix kullanıcısı altında, loopback üzerinde ve SSH üzerinden erişilecek şekilde çalıştırın.
• Sunucuda tek bir API anahtarı bulundurun ve artık güvenmediğiniz bir eklentiyi kaldırdığınız gün bu anahtarı yenileyin.

Bunların hiçbiri eklentilerden kaçınmak için bir neden değildir. Eklenti modeli dsh aracını kullanışlı kılan şeydir; genişletemediğiniz bir harness, er ya da geç değiştireceğiniz bir harness'tır. Bu maddeler; neyi, kimden, hangi sürümde kurduğunuzu bilmeniz ve tüm yapıyı yeniden inşa edebileceğiniz bir ortamda çalıştırmanız için birer nedendir.

FAQ

dsh eklentileri birbirinden yalıtır mı?

Hayır. Bir eklenti, Cordis aracılığıyla harness sürecine yüklenir ve shell, dosya sistemi, web, subprocess, subagent ve kimlik bilgileri dahil olmak üzere belgelenmiş yetenek sınırlarına erişebilir. Her profildeki ilk paket olan dsh-base, aracın araçlarının neler yapabileceğini düzenleyen sandbox ve onay politikasını içerir; korumanız bu politikadan gelir. Eklenti bazlı bir izin sınırı yoktur; bu nedenle dürüst model, bir eklenti yüklemenin güveninizi hem eklenti yazarına hem de bağımlılık ağacındaki her pakete genişlettiğiniz anlamına gelir.

Bir dsh eklentisini, kurulum betiklerini çalıştırmadan yükleyebilir miyim?

pnpm 10 ve sonraki sürümler, bağımlılık oluşturma betiklerini varsayılan olarak engeller ve dsh plugin ... add komutu pnpm'e yönlendirme yaptığı için, güncel bir pnpm sürümünde paketi onaylamadığınız sürece kurulum betikleri çalışmaz. Sürümünüzü pnpm --version ile doğrulayın. Bu durum, içeriği incelenmemiş bir eklentiyi güvenli kılmaz. Eklentinin kendi kodu bir sonraki başlatmada çalışır çünkü harness onu kasıtlı olarak yükler; kurulum anındaki hiçbir kısıtlama bunu etkilemez.

dsh eklentileri ve yapılandırmaları aslında nerede bulunur?

$DSH_HOME varsayılan olarak ~/.dsh dizinini kullanır. Profiller $DSH_HOME/profiles/<name> içinde yer alır; her biri eklenti bağımlılıklarını içeren bir package.json, sıralı paketlerin dsh.profile manifestosu ve bir cordis.patch.yml yama katmanı barındırır. Yüklenen paketler $DSH_HOME/profiles/node_modules altına yerleşir. Anahtarlar $DSH_HOME/.credentials.yaml içinde, ortam değerleri $DSH_HOME/.env içinde bulunur ve kullanıcı seviyesindeki bir $DSH_HOME/cordis.patch.yml dosyası tüm profiller üzerinde geçerlidir. Başlatma yapmadan birleştirilmiş sonucu görmek için dsh --profile web --dump-config komutunu çalıştırın.

dsh eklenti marketinden yükleme yapmak güvenli mi?

Market, yüklemeleri küratörlü bir kayıt defterindeki kaynaklarla sınırlar ve paket bazında onay vermediğiniz sürece oluşturma betiklerini engeller; bu, bir sohbet penceresinden paket adı kopyalamaya göre gerçek bir iyileştirmedir. Marketin kendi README dosyası, listelenmenin bir onay anlamına gelmediğini belirtir çünkü eklentiler üçüncü taraflara ait kodlardır. Kaynak kodunu okuyun ve sürümü sabitleyin. Harness'ı, kaybetmeyi göze alabileceğiniz bir kullanıcı hesabında ve ideal olarak ayrı bir makinede tutun.