5 ปลั๊กอิน DeepSeek Harness ที่ควรติดตั้งบน VPS

ปลั๊กอิน DeepSeek Harness ใดบ้างที่ควรติดตั้ง

ปลั๊กอิน DeepSeek Harness คือโค้ดจากภายนอกที่ทำงานภายในเอเจนต์ของคุณ โดยใช้สิทธิ์ของเอเจนต์และรันบนเครื่องที่คุณเป็นผู้จ่ายค่าเช่า รายการจากชุมชนมีมากกว่า 20 หมวดหมู่และมีรายการให้เลือกกว่าหนึ่งพันรายการ สำหรับการใช้งานบน virtual private server (VPS) ที่เช่ามา คุณจำเป็นต้องมี 5 รายการดังนี้: dsh-budget สำหรับจำกัดค่าใช้จ่าย, dsh-permission-rules สำหรับควบคุมการเข้าถึงเครื่องมือ, dsh-defend สำหรับสแกนการฉีดโค้ด (injection) และข้อมูลลับ (secret), dsh-memory สำหรับเก็บข้อมูลที่คงอยู่ยาวนานกว่าเซสชัน และ dsh-web-lan-access ซึ่งควรติดตั้งหลังจากที่คุณตัดสินใจได้แล้วว่าจะใช้วิธีการยืนยันตัวตนแบบใด

Harness คือ dsh ซึ่งเป็น agent harness แบบโอเพนซอร์สของ DeepSeek ที่ออกแบบมาให้ทุกอย่างเป็นปลั๊กอิน ไฟล์ README ของตัวมันเองระบุว่าเป็นรุ่น developer preview และแจ้งเตือนไว้ว่า THERE WILL BE COMPATIBILITY-BREAKING CHANGES ข้อเท็จจริงนี้เป็นตัวกำหนดทุกทางเลือกด้านล่างนี้ ให้ตรึงเวอร์ชันของปลั๊กอินที่คุณติดตั้งไว้ เตรียมใจว่าการอัปเกรดอาจทำให้ปลั๊กอินใช้งานไม่ได้ และจำกัดจำนวนปลั๊กอินให้เหลือน้อยที่สุดเท่าที่คุณจะสามารถตรวจสอบโค้ดทั้งหมดได้ด้วยตนเอง หากคุณยังไม่ได้เริ่มใช้งาน harness ให้เริ่มต้นที่ การติดตั้ง DeepSeek Harness บน VPS แล้วค่อยกลับมาที่นี่ หากส่วนประกอบที่ปลั๊กอินเหล่านี้เข้าไปเชื่อมต่อ ไม่ว่าจะเป็น agent loop, เครื่องมือ, หรือหน่วยความจำ ยังคงเป็นเรื่องที่ไม่ชัดเจนสำหรับคุณ ให้ ศึกษาพื้นฐานให้เข้าใจก่อน เพราะทุกทางเลือกด้านล่างนี้จะตัดสินใจได้ง่ายขึ้นเมื่อคุณเข้าใจการทำงานของแต่ละเลเยอร์แล้ว

วิธีการติดตั้งปลั๊กอินของ dsh และตำแหน่งที่เก็บไฟล์คอนฟิก

dsh ประกอบร่างขึ้นจากปลั๊กอินของ Cordis ดังนั้นอินสแตนซ์ที่กำลังทำงานอยู่จึงเป็นโครงสร้างแบบต้นไม้ของปลั๊กอิน ไม่ใช่โปรแกรมเดี่ยว โปรไฟล์คือการรวมกลุ่มของปลั๊กอินเหล่านั้นโดยมีการตั้งชื่อไว้ ซึ่งจะถูกจัดเก็บไว้ใน harness home ตัว harness มีเทมเพลตโปรไฟล์มาให้ 5 รายการ ได้แก่ web, headless, sdk, sdk-minimal และ acp โดยสองรายการที่มีความสำคัญบนเซิร์ฟเวอร์คือ web และ headless ค่าเริ่มต้นของ $DSH_HOME คือ ~/.dsh และโปรไฟล์จะอยู่ที่ $DSH_HOME/profiles/<name>/ โดยโปรไฟล์จะประกาศตัวเองไว้ใน package.json ภายใต้ฟิลด์ dsh ซึ่ง dsh.profile จะระบุรายการ bundle ของโปรไฟล์นั้น และในไดเรกทอรีเดียวกันจะเก็บปลั๊กอินภายนอก (out-of-tree) ที่ติดตั้งไว้ รวมถึงไฟล์ cordis.patch.yml ของผู้ใช้เอง

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

รูปแบบแหล่งที่มาที่รองรับมี 4 แบบ ได้แก่ ชื่อ npm package แบบปกติ, ชื่อ npm แบบ scoped เช่น @scope/plugin, การอ้างอิง GitHub เช่น github:PerryLink/dsh-budget#main และพาธในเครื่องโดยใช้ link: หรือ ./ แนะนำให้ใช้รูปแบบ GitHub เพราะคุณสามารถแทนที่ #main ด้วย commit hash เพื่อให้มั่นใจว่าจะได้รับโค้ดชุดเดิมในเดือนถัดไป

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

เลเยอร์ต่างๆ จะถูกนำมาใช้ตามลำดับที่กำหนด: เริ่มจาก bundle แต่ละตัวตามลำดับที่ระบุในโปรไฟล์, ตามด้วย cordis.patch.yml ของโปรไฟล์, ต่อด้วย cordis.patch.yml ในระดับ home และปิดท้ายด้วย --patch overlay ใดๆ ลำดับมีความสำคัญเพราะเลเยอร์ที่อยู่หลังสามารถกำหนดค่าใหม่หรือยกเลิกสิ่งที่เลเยอร์ก่อนหน้าตั้งค่าไว้ได้ ดังนั้นเมื่อปลั๊กอินดูเหมือนติดตั้งแล้วแต่ไม่ทำงาน ให้เปิดไฟล์ cordis.patch.yml ของโปรไฟล์แล้วตรวจสอบสองจุด: ตรวจสอบว่ามีบล็อกการแทรก (insert block) อยู่จริง และไม่มีเลเยอร์ที่อยู่ถัดไปมาปิดการทำงานของมัน

ณ วันที่ 17 สิงหาคม 2026 npm package @deepseek-ai/dsh อยู่ที่เวอร์ชัน 0.1.0-rc.7 ในขณะที่ปลั๊กอินด้านล่างถูกสร้างขึ้นสำหรับสายการพัฒนา 0.1.0-rc ณ commit ที่ระบุไว้ที่นี่ dsh-permission-rules และ dsh-defend ประกาศความเข้ากันได้กับ 0.1.0-rc.5 ถึง 0.1.0-rc.6, dsh-budget ประกาศเพียง 0.1.0-rc.6 เท่านั้น, dsh-memory ตั้งค่าเฉพาะ peer ranges ที่เริ่มจาก ^0.1.0-rc.6 และ dsh-web-lan-access ไม่ได้ประกาศเวอร์ชัน dsh เลย เมื่อวันที่ 16 ตุลาคม 2026 แท็ก latest บน npm คือ 0.2.0-rc.2 และในวันที่ 20 ตุลาคม 2026 คือ 0.2.1-rc.2 ดังนั้น commit ที่ระบุไว้เหล่านั้นจึงล้าหลังกว่าตัว harness อยู่หนึ่ง minor line ปลั๊กอินส่วนใหญ่ได้อัปเดตบน branch main ของตนเองแล้ว จากการตรวจสอบเมื่อวันที่ 16 ตุลาคม 2026 พบว่า dsh-budget 0.4.17, dsh-permission-rules 0.7.15 และ dsh-defend 0.3.21 รองรับ dsh ตั้งแต่ 0.1.2-rc.1 จนถึงเวอร์ชันก่อนหน้า 0.3.0 และแต่ละตัวระบุ 0.2.1-alpha.1 ไว้ในรายการ harness releases ที่ผ่านการทดสอบแล้ว dsh-web-lan-access 1.4.0 ซึ่งปล่อยออกมาเมื่อวันที่ 17 ตุลาคม 2026 และตรวจสอบเมื่อวันที่ 18 ตุลาคม 2026 ประกาศรองรับ >=0.2.1-rc.1 โดยมีรายการ release ที่ทดสอบแล้วจนถึง 0.2.1-rc.2 ซึ่ง npm มีให้ทั้งบนแท็ก latest และ next ณ วันที่ 20 ตุลาคม 2026; ไฟล์ README ของปลั๊กอินระบุการจับคู่ระหว่าง harness 0.2.0-rc.x และรุ่นก่อนหน้ากับปลั๊กอิน 1.3.x ส่วน dsh-memory บน main ที่ตรวจสอบเมื่อวันที่ 20 ตุลาคม 2026 ยังคงตั้งค่าเฉพาะ peer ranges จาก ^0.1.0-rc.6 ไม่มีช่วงเวอร์ชันใหม่เหล่านั้นที่ครอบคลุมถึง build 0.1.0-rc ที่เลือกใช้ในการ pin ดังนั้นการย้าย pin ไปยังโค้ดปัจจุบันจึงหมายถึงการต้องย้าย harness ไปด้วย ช่องว่างนี้เป็นเรื่องปกติในระบบนิเวศนี้ และเป็นสาเหตุทั่วไปที่ทำให้ปลั๊กอินหยุดทำงาน: ตัว harness มีการพัฒนาเร็วกว่าปลั๊กอินรอบข้าง ให้ทำการอัปเกรด harness อย่างตั้งใจ จากนั้นจึงทดสอบปลั๊กอินทีละตัว

ตรวจสอบปลั๊กอินก่อนให้ความไว้วางใจ

ปลั๊กอิน dsh ไม่ได้ถูกแยกส่วน (sandboxed) ออกจากตัว harness มันจะโหลดเข้าสู่ Cordis tree เดียวกัน ในกระบวนการ (process) เดียวกัน ภายใต้ผู้ใช้งานระบบปฏิบัติการเดียวกัน โดยสามารถเข้าถึงข้อมูลประจำตัวของโมเดล (model credentials) และ working tree เดียวกันได้ การติดตั้งปลั๊กอินจึงใกล้เคียงกับการรันสคริปต์ของผู้อื่นด้วย sudo มากกว่าการเพิ่มส่วนขยายของเบราว์เซอร์ นี่เป็นประเด็นความไว้วางใจเดียวกันกับที่ ปลั๊กอินของ Claude Code ก่อให้เกิด และคำตอบก็คือสิ่งเดียวกัน: ให้อ่านโค้ดก่อน หรือไม่ก็อย่าติดตั้งมัน

มี 4 สิ่งที่ต้องตรวจสอบตามลำดับดังนี้:

• จุดเชื่อมต่อ (extension points) ที่ปลั๊กอินเรียกใช้ tools/pre-execute หมายความว่าปลั๊กอินเห็นการเรียกใช้เครื่องมือทุกครั้งและสามารถบล็อกได้ agent/pre-step หมายความว่าปลั๊กอินเห็นข้อความของคุณ webServer.tapIndex หมายความว่าปลั๊กอินเขียนหน้าเว็บที่ส่งไปยังเบราว์เซอร์ของคุณใหม่ ปลั๊กอินที่ไม่ได้เรียกใช้จุดเชื่อมต่อเหล่านี้เลยแทบจะทำอะไรไม่ได้เลย แต่ปลั๊กอินที่เรียกใช้ทั้งหมดนั้น คือ ขอบเขตความปลอดภัยของคุณ
• ปลั๊กอินมีการเชื่อมต่อเครือข่ายหรือไม่ ให้ค้นหาในซอร์สโค้ดสำหรับ fetch, http และชื่อโฮสต์ใดๆ ที่ถูกกำหนดค่าไว้ตายตัว (hard-coded) เครื่องมือวัดค่าใช้จ่ายที่ส่งข้อมูลกลับไปยังเซิร์ฟเวอร์ภายนอก (phones home) กำลังส่งรูปแบบการใช้งานของคุณไปยังที่อื่น
• ปลั๊กอินอ่านข้อมูลประจำตัวหรือไม่ สิ่งใดก็ตามที่แตะต้อง credentials.* หรือคีย์ของผู้ให้บริการ (provider key) จำเป็นต้องมีเหตุผลระบุไว้ใน README
• ใบอนุญาตและวันที่คอมมิตล่าสุด ปลั๊กอินที่ไม่มีใบอนุญาตและไม่ได้ถูกแตะต้องมานานหลายเดือน ในระบบนิเวศที่มีการเปลี่ยนแปลงทุกสัปดาห์ ถือเป็นความเสี่ยง

จากนั้นให้ติดตั้งโดยระบุ commit แทนการระบุ branch และอ่านบล็อกการแทรก (insert block) ที่ตัวติดตั้งเขียนลงใน cordis.patch.yml บล็อกนั้นจะระบุ id ของปลั๊กอินและการกำหนดค่าที่ปลั๊กอินลงทะเบียนไว้ ซึ่งเป็นคำอธิบายที่ตรงไปตรงมาและสั้นที่สุดของสิ่งที่คุณเพิ่งเพิ่มเข้าไป ให้เก็บคีย์ของผู้ให้บริการไว้ให้ห่างจากการเข้าถึงของปลั๊กอินในส่วนที่ harness อนุญาตให้ทำได้ ตามแนวทางของ การเก็บความลับให้ห่างจาก AI agents

dsh-budget: ฉันจะหยุดไม่ให้อเจนท์ใช้จ่ายเงินตลอดทั้งคืนได้อย่างไร?

อเจนท์บน VPS ทำงานโดยไม่มีผู้ดูแล ซึ่งเป็นจุดประสงค์ของการนำไปวางไว้ที่นั่น แต่ก็นับเป็นความเสี่ยงเช่นกัน dsh-budget จะวัดผลจำนวนโทเค็นและค่าใช้จ่ายโดยประมาณต่อโมเดล ต่อเซสชัน และต่อวัน พร้อมทั้งบังคับใช้เพดานการใช้งานตามยอดรวมเหล่านั้น

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

ค่าเริ่มต้นที่ให้มานั้นค่อนข้างสูง: 10 USD ต่อเซสชัน, 50 ต่อวัน และ 500 ต่อเดือน ค่าเหล่านี้เหมาะสำหรับทีมที่มีงบประมาณสนับสนุน แต่บนเซิร์ฟเวอร์ส่วนตัว ค่าเหล่านี้สูงเกินไปจนทำให้ลูปที่ทำงานผิดพลาดอาจทำงานจนจบก่อนที่เพดานจะทำงาน ดังนั้นควรปรับลดค่าเหล่านี้ตั้งแต่วันแรก

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

คอลัมน์ที่แนะนำเป็นเพียงจุดเริ่มต้นสำหรับผู้ใช้งานหนึ่งคนบนเครื่องหนึ่งเครื่อง ไม่ใช่ตัวเลขที่กำหนดตายตัว ให้ปรับเพิ่มขึ้นเมื่อการใช้งานจริงตลอดหนึ่งเดือนบอกให้คุณทราบ เพดานรายเดือนที่ 40 USD พร้อมเพดานรายเซสชันที่ 2 จะแจ้งเตือนอย่างชัดเจนและรวดเร็ว ซึ่งเป็นสิ่งที่คุณต้องการในขณะที่ยังเรียนรู้พฤติกรรมการใช้ทรัพยากรของเครื่องมือนี้อยู่

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

การตั้งค่าที่เปลี่ยนพฤติกรรมของเครื่องคือ overLimit ค่าเริ่มต้นคือ alert ซึ่งจะแสดงคำเตือนและยังคงใช้จ่ายต่อไป ดังนั้นเมื่อติดตั้งครั้งแรกปลั๊กอินนี้จึงทำหน้าที่เป็นเพียงแดชบอร์ดเท่านั้น ให้ตั้งค่าเป็น block แล้วระบบจะปฏิเสธการเรียกใช้โมเดลเพิ่มเติมเมื่อถึงเพดานที่กำหนด ซึ่งหมายความว่างานที่ค้างคืนจะหยุดทำงานแทนที่จะเรียกเก็บเงินไปจนถึงเช้า degrade คือโหมดที่สาม: ระบบจะบล็อกการเรียกใช้พร้อมคำแนะนำให้ใช้โมเดลที่ถูกกว่าจากแผนผัง degradation ซึ่งเหมาะสมเมื่องานจำเป็นต้องเสร็จสิ้นแต่ไม่ต้องการโมเดลที่ดีที่สุดของคุณ warnRatio มีค่าเริ่มต้นเป็น 0.8 ดังนั้นคุณจะได้รับแจ้งเตือนเมื่อถึง 80 เปอร์เซ็นต์ของเพดาน

มีข้อจำกัดที่ต้องคำนึงถึงสองประการ ประการแรก ค่าใช้จ่ายถูกคำนวณจากตารางราคาในตัวที่รวมเข้ากับราคาที่คุณระบุไว้ และผู้ดูแลระบบเตือนว่าราคาในตัวอาจมีการเปลี่ยนแปลง prices จะว่างเปล่าโดยค่าเริ่มต้น ณ คอมมิตที่ระบุ 461d478, defaultPrice ซึ่งเป็นค่าสำรองสำหรับโมเดลที่ไม่อยู่ในตารางใดเลย จะอยู่ที่ 1.0 USD ต่อล้านอินพุตโทเค็นและ 3.0 ต่อล้านเอาต์พุตโทเค็น ส่วนใน main ปัจจุบัน ซึ่งตรวจสอบเมื่อวันที่ 10 ตุลาคม 2026 ค่าเริ่มต้นจะเป็นศูนย์และโมเดลจะปรากฏว่าไม่มีการระบุราคา ให้กรอกตัวเลขจริงสำหรับโมเดลของคุณ มิฉะนั้นแดชบอร์ดจะเป็นเพียงการคาดเดาที่ดูเหมือนการวัดผล ประการที่สอง ที่ 461d478 ปลั๊กอินจะรวบรวมข้อมูลในโพรเซสที่กำลังทำงานจากสตรีมเหตุการณ์ของเซสชัน ดังนั้นยอดรวมจะถูกรีเซ็ตเมื่อ harness เริ่มทำงานใหม่ และการเกิด crash loop หรือ supervisor ที่รีสตาร์ท dsh จะทำให้เพดานรายวันถูกรีเซ็ตไปด้วย ปัจจุบัน main จะบันทึกข้อมูลถังรายวันและรายเดือนไว้โดยค่าเริ่มต้น (persistence.enabled: true, บันทึกทุก 10 วินาที) และกู้คืนข้อมูลเหล่านั้นเมื่อเริ่มต้นระบบ ดังนั้นการรีสตาร์ทจึงไม่ล้างเพดานรายวันหรือรายเดือนอีกต่อไป หาก harness จัดเตรียม storage domain ไว้ให้ หากไม่มีการจัดเตรียม ข้อมูลการรวบรวมจะคงอยู่เฉพาะในโพรเซสเท่านั้น main ยังมุ่งเป้าไปที่บรรทัด harness 0.2 ดังนั้นการเปลี่ยน pin จึงหมายถึงการเปลี่ยน harness ด้วยเช่นกัน ไม่ว่าจะอย่างไร ให้ถือว่า dsh-budget เป็นเพียงเครื่องป้องกันงานของคุณเอง และให้คงเพดานการใช้จ่ายไว้ที่บัญชีของผู้ให้บริการเป็นเกณฑ์สูงสุดที่แท้จริง ซึ่งเป็นประเด็นที่กว้างกว่าใน การควบคุมค่าใช้จ่าย AI agent บน VPS

ในแต่ละวัน คุณสามารถใช้ /budget สำหรับภาพรวม, /budget models สำหรับรายละเอียดแยกตามโมเดล และ /budget unblock <scope> เพื่อปลดบล็อกเมื่อคุณตัดสินใจที่จะดำเนินการต่อ

dsh-permission-rules: การเรียกใช้เครื่องมือใดบ้างที่ไม่ควรเกิดขึ้น

dsh-permission-rules จะวางกฎแบบประกาศไว้บน tools/pre-execute waterfall เพื่อให้กฎถูกประเมินก่อนที่เครื่องมือจะทำงาน โดยมี 3 การกระทำ ได้แก่ allow ซึ่งอนุญาตให้การเรียกผ่านไปได้ deny ซึ่งบล็อกการเรียกและส่งคืนเหตุผลที่โมเดลสามารถอ่านได้ และ ask ซึ่งส่งการเรียกไปยังช่องทางการอนุมัติอย่างเป็นทางการ

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

กฎต่างๆ จะอยู่ใน .dsh/rules.yaml โดยอ้างอิงจากไดเรกทอรีทำงานของเซสชัน พร้อมด้วย fallbackPath ส่วนกลาง และ searchUp ทางเลือกสำหรับการไล่ระดับขึ้นไปยัง root ของระบบไฟล์ การจับคู่ครอบคลุมถึง glob ของชื่อเครื่องมือ, glob ของคีย์และค่าพารามิเตอร์, glob ของพาธที่สัมพันธ์กับ workspace, ตัวเลือกเอเจนต์ เช่น main หรือ subagent และเป้าหมายเครือข่าย

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

การประเมินจะยึดตามการจับคู่ครั้งแรกที่พบ ดังนั้น allow แบบกว้างที่อยู่ด้านบนจะยกเลิกกฎที่แคบกว่าทั้งหมดที่อยู่ด้านล่างโดยอัตโนมัติ ให้เขียนกฎการปฏิเสธไว้ก่อนและกฎการอนุญาตไว้ท้ายสุด glob ของชื่อเครื่องมือจะครอบคลุมถึง mcp__* ซึ่งเป็นวิธีที่คุณใช้ควบคุมเครื่องมือที่มาจากเซิร์ฟเวอร์ model context protocol (MCP) แทนที่จะมาจากตัว harness เอง ซึ่งเป็นเรื่องสำคัญทันทีที่คุณเริ่มใช้งาน MCP servers on a VPS

พฤติกรรมหนึ่งที่ต้องวางแผนคือ ask จำเป็นต้องมีผู้ตอบรับ ในโปรไฟล์ headless อาจไม่มีใครคอยเฝ้าดูอยู่ และ ask ที่ไม่มีการตอบรับจะไม่รอให้มีคนปรากฏตัว หากไม่มีการกำหนดผู้ตอบรับไว้ ห่วงโซ่การอนุมัติของ harness จะปิดตัวลงและปฏิเสธการเรียกนั้น ดังนั้นบนเครื่องที่ไม่มีผู้ดูแล กฎ ask จึงมีพฤติกรรมเหมือนกับ deny ที่คุณไม่ได้ตั้งใจเขียนไว้ ให้ใช้ deny สำหรับสิ่งที่คุณจะไม่มีวันอนุมัติ ให้เก็บ ask ไว้สำหรับโปรไฟล์ที่คุณใช้งานอยู่หน้าเครื่อง และหากคุณต้องการให้การอนุมัติทำงานได้โดยไม่ต้องมีคนดูแล คุณจำเป็นต้องมีเส้นทางการตอบรับที่แท้จริง ซึ่งเป็นหัวข้อของ การควบคุมการกระทำของ AI agent ด้วยการอนุมัติ

dsh-defend: แล้วเรื่อง prompt injection และข้อมูลลับรั่วไหลล่ะ?

dsh-defend จะสแกนที่จุดสามจุด ได้แก่ ข้อความขาเข้าที่ agent/pre-step, อาร์กิวเมนต์ของเครื่องมือที่ tools/pre-execute ซึ่งรวมถึงระบบป้องกันการลบข้อมูลแบบทำลายล้าง และผลลัพธ์จากเครื่องมือที่ tools/post-execute จุดสุดท้ายนี้เป็นจุดที่น่าสนใจที่สุด เพราะเป็นจุดที่เนื้อหาซึ่งดึงมาจากหน้าเว็บจะถูกตรวจสอบก่อนที่โมเดลจะดำเนินการใดๆ กับมัน

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

ค่าเริ่มต้นจะเน้นความระมัดระวังมากกว่าความเข้มงวด โดย detection.injectionAction, detection.jailbreakAction และ detection.secretAction จะถูกตั้งค่าเป็น ask ทั้งหมด ในขณะที่ detection.secretBlockCritical ถูกตั้งค่าเป็น true ดังนั้นข้อมูลลับที่สำคัญจะถูกบล็อกเสมอไม่ว่าการตั้งค่าอื่นจะเป็นอย่างไร สำหรับเครื่องที่ไม่มีผู้ดูแล ให้เปลี่ยนการดำเนินการที่คุณให้ความสำคัญเป็น block เพราะ ask ในสถานการณ์ที่ไม่มีใครให้สอบถามนั้นไม่ใช่การตัดสินใจที่เหมาะสม

การออกแบบระบบตรวจสอบ (audit) ถือว่าทำได้ดี defend/detection จะบันทึกเหตุการณ์โดยระบุรหัสกฎ, ตระกูล, หมวดหมู่, ระดับความรุนแรง, การตัดสินใจ และข้อเท็จจริงในการสแกน โดยจะไม่บันทึกข้อความที่ตรวจพบจริง ส่วนข้อมูลลับจะถูกบันทึกตามประเภทเท่านั้น ดังนั้นการเปิดใช้งาน audit log จึงไม่เป็นการสร้างสำเนาของข้อมูลรับรองที่คุณพยายามปกป้องขึ้นมาอีกชุดหนึ่ง

ต้องเข้าใจให้ชัดเจนว่าสิ่งนี้ช่วยคุณได้อย่างไร การตรวจจับนั้นอิงตามกฎ และไฟล์ README ระบุไว้อย่างชัดเจนว่าการใช้ถ้อยคำแบบใหม่หรือการโจมตีหลายขั้นตอนอาจเล็ดลอดผ่านไปได้ ระบบนี้ช่วยลดอัตราการโจมตีที่ชัดเจนได้ แต่ไม่ได้ทำให้เอเจนต์ปลอดภัยพอที่จะนำไปใช้กับเนื้อหาที่ไม่น่าเชื่อถือ ดังนั้นคุณยังคงต้องคงกฎการอนุญาตสิทธิ์ไว้ที่ระดับล่างสุดเช่นเดิม

dsh-memory: เอเจนต์จำอะไรได้ในวันพรุ่งนี้?

มีปลั๊กอินอย่างน้อย 3 ตัวที่ใช้ชื่อว่า dsh-memory ซึ่งเป็นสิ่งที่ควรทราบก่อนพิมพ์คำสั่งติดตั้ง ให้ติดตั้งโดยระบุแหล่งที่มาให้ชัดเจนเพื่อให้ได้ตัวที่คุณต้องการอ่าน สองตัวถูกนำมาเปรียบเทียบไว้ด้านล่าง ส่วนตัวที่สามซึ่งติดตั้งด้วย @dsh-memory/bundle มีการออกแบบที่แตกต่างออกไป โดยจากการตรวจสอบเมื่อวันที่ 20 ตุลาคม 2026 พบว่ามันเก็บไฟล์ markdown ไว้ภายใต้ ~/.dsh/memory/<project>/ และ ~/.dsh/memory/_user/ มีโมเดลสำหรับกลั่นกรองข้อมูลจาก session log, แทรกดัชนีที่จำกัดจำนวน token ของไฟล์เหล่านั้น และมีเพียง memory_read และ memory_expand ให้ใช้เป็นเครื่องมือ เนื้อหาด้านล่างนี้ไม่ได้กล่าวถึงปลั๊กอินตัวดังกล่าว

ตัวที่ผมแนะนำให้ติดตั้งบนเซิร์ฟเวอร์ขนาดเล็กคือรุ่น SQLite ซึ่งลงทะเบียนเป็น memory โดยเก็บไฟล์ไว้ไฟล์เดียวที่ $DSH_HOME/memory/memory.db ซึ่งใช้ร่วมกันในทุกโปรไฟล์ และเปิดใช้งาน memory_write, memory_search และ memory_forget การค้นหาจะเป็นแบบใช้คำหลัก (keyword-based) บนข้อความและแท็กที่จัดเก็บไว้ ไม่มีการใช้บริการ embedding, ไม่ต้องใช้ API key และไม่มีกระบวนการทำงานเพิ่มเติม

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

การตั้งค่าที่คุณต้องปรับแต่งมีเพียงเล็กน้อย ได้แก่ path สำหรับไฟล์ฐานข้อมูล, promptRecentCount (ค่าเริ่มต้นคือ 10) สำหรับจำนวนหน่วยความจำที่ไม่ได้ปักหมุดที่จะถูกแทรกเข้าไป และ promptMaxChars (ค่าเริ่มต้นคือ 2000) สำหรับงบประมาณในการเรนเดอร์ มันทำงานโดยอาศัย node:sqlite ซึ่ง Node 22 ยังคงระบุว่าเป็นฟีเจอร์ทดลอง และ Node 24 เพิ่งเลื่อนสถานะเป็น release candidate ในเวอร์ชัน 24.15.0 (ตรวจสอบเมื่อวันที่ 20 ตุลาคม 2026) ดังนั้นการอัปเกรด Node จึงเป็นสิ่งที่ควรทดสอบก่อน ไม่ควรทึกทักเอาเองว่าใช้งานได้ทันที

นี่คือสิ่งที่ memory เปลี่ยนแปลงบนเครื่องของคุณ: หน่วยความจำที่ถูกแทรกจะอยู่ใน system prompt ในทุกรอบการสนทนา promptMaxChars เป็นเพดานสำหรับส่วนที่เรนเดอร์ ไม่ใช่จำนวนที่ตายตัว แต่เมื่อหน่วยความจำที่คุณเก็บไว้เต็ม งบประมาณ 2000 ตัวอักษรจะกลายเป็น input token เพิ่มเติมอีกหลายร้อย token ในทุกคำขออย่างต่อเนื่อง ซึ่งนั่นหมายถึงค่าใช้จ่ายที่เพิ่มขึ้นจริง และเป็นเหตุผลว่าทำไม dsh-budget จึงควรอยู่บนเครื่องก่อนที่จะติดตั้ง dsh-memory ควรคุม promptMaxChars ให้กระชับและหมั่นลบข้อมูลที่ไม่จำเป็นด้วย memory_forget แทนที่จะปล่อยให้ไฟล์ขยายขนาดขึ้นเรื่อยๆ

รุ่นทางเลือกจะเก็บหน่วยความจำไว้ในไฟล์ YAML และทำการค้นหาแบบ embedding พร้อมการแทรก prompt อัตโนมัติ โดยติดตั้งด้วย dsh plugin --profile web add github:towzai/dsh-memory การค้นหาแบบ embedding จำเป็นต้องมี instance ของ ollama ในเครื่องและโมเดล embedding โดยค่าเริ่มต้นคือ qwen3-embedding:0.6b ซึ่งสามารถแทนที่ได้ด้วย DSH_MEMORY_EMBED_MODEL หากไม่มี ollama ระบบจะกลับไปใช้การค้นหาด้วยคำหลักเพียงอย่างเดียว การเรียกคืนข้อมูลเชิงความหมาย (semantic recall) ให้ผลลัพธ์ที่ดีกว่าการใช้คำหลัก แต่ก็หมายถึงการต้องมีบริการที่สองและชุดน้ำหนักโมเดล (model weights) ที่ทำงานอยู่บนเซิร์ฟเวอร์เดียวกัน ซึ่งสำหรับแผนบริการขนาดเล็กถือเป็นการดึงทรัพยากร RAM ไปจากงานหลักที่คุณเช่าเซิร์ฟเวอร์มาทำ ให้เลือกใช้ตัวเลือกนี้เมื่อคุณมี RAM เหลือเฟือเท่านั้น การแลกเปลี่ยนระหว่างคุณภาพการเรียกคืนข้อมูลกับทรัพยากรที่ต้องใช้ถูกอธิบายไว้ใน หน่วยความจำภายในสำหรับเอเจนต์

dsh-web-lan-access: web UI ควรฟังการเชื่อมต่อภายนอก loopback หรือไม่?

npx @deepseek-ai/dsh web ให้บริการอินเทอร์เฟซบน 127.0.0.1:3080 เบราว์เซอร์จะเปิดใช้งาน crypto.randomUUID() เฉพาะในบริบทที่ปลอดภัยเท่านั้น ดังนั้นในการ build harness จนถึงบรรทัด 0.2.0 การโหลดหน้าเว็บเดียวกันผ่าน HTTP ธรรมดาจากเครื่องอื่นจะล้มเหลว dsh-web-lan-access 1.3.x แก้ไขปัญหานี้โดยใช้ webServer.tapIndex เพื่อแทรก polyfill ขนาดเล็ก และเปลี่ยนการ binding ของเซิร์ฟเวอร์ไปที่ 0.0.0.0 เวอร์ชัน 1.4.0 ซึ่งปล่อยออกมาเมื่อ 17 ตุลาคม 2026 สำหรับ dsh 0.2.1 ได้นำ polyfill ออก: harness ดังกล่าวสร้าง UUID ด้วย crypto.getRandomValues ดังนั้นหน้าเว็บ LAN แบบ HTTP ธรรมดาจึงแสดงผลได้โดยไม่ต้องใช้ patch ปลั๊กอินยังคงใช้ webServer.tapIndex เพื่อแทรก bootstrap script ที่ช่วยให้หน้าเว็บระยะไกลใช้การตั้งค่าที่รองรับโดย Host และยังคง bind ที่ 0.0.0.0 บน 0.2.1 ตัว harness เองปฏิเสธการ bind แบบ wildcard โดยเตือนว่าการ bind ทุกอินเทอร์เฟซจะทำให้เกิดความเสี่ยงต่อการรันโค้ดจากระยะไกล (remote code execution) บนเครือข่าย และปลั๊กอินจะเข้ามาแทนที่เว็บเซิร์ฟเวอร์เดิมเพื่อข้ามการตรวจสอบนั้น ตรวจสอบเมื่อ 18 ตุลาคม 2026

โปรดอ่านคำเตือนก่อนทำการติดตั้ง ใน commit ที่อ้างถึงที่นี่ e27e909 ไฟล์ README ระบุว่าการ bind 0.0.0.0 จะทำให้ agent สามารถเข้าถึงได้โดยไม่ต้องมีการตรวจสอบสิทธิ์จากใครก็ตามบนเครือข่ายท้องถิ่น (LAN) เดียวกัน และบนเซิร์ฟเวอร์ที่มี IP สาธารณะจะเข้าถึงได้จากทั้งอินเทอร์เน็ต โดยมีรายการเมธอดที่ละเอียดอ่อน (settings.*, credentials.*, llm.discoverModels) ที่ถูกจำกัดไว้ที่ loopback และส่งค่า 403 จากแหล่งที่มาภายนอก สิ่งนี้ได้เปลี่ยนไปแล้ว harness build ปัจจุบันที่ตรวจสอบเมื่อ 10 ตุลาคม 2026 จะทำการตรวจสอบสิทธิ์เบราว์เซอร์: launch token ใน URL ที่แสดงจะถูกแลกเปลี่ยนเป็น signed session cookie ซึ่งทุกเส้นทางและสตรีมของ Host API จำเป็นต้องใช้ README ปัจจุบันของปลั๊กอินเรียก trustedHosts ว่าเป็น Origin/Host fence ไม่ใช่การระบุตัวตน และระบุว่าการ bind 0.0.0.0 จะเปิดเผยพื้นผิวการตรวจสอบสิทธิ์บนทุกอินเทอร์เฟซที่เข้าถึงได้ และตอนนี้เปิดใช้งานการตั้งค่าที่รองรับโดย Host สำหรับหน้าเว็บระยะไกลที่ผ่านการตรวจสอบสิทธิ์แล้ว ดังนั้นใน build ปัจจุบัน เบราว์เซอร์ระยะไกลที่ลงชื่อเข้าใช้แล้วจึงสามารถเข้าถึงการตั้งค่า Host ได้เช่นกัน ความเสี่ยงได้เปลี่ยนรูปแบบไปแทนที่จะหายไป: ใครก็ตามที่เข้าถึงพอร์ตได้สามารถทดสอบการเข้าสู่ระบบได้ URL ที่แสดงนั้นเป็นข้อมูลประจำตัวในตัวมันเอง และผ่าน HTTP ธรรมดา token นั้นจะถูกส่งผ่านเครือข่ายโดยไม่มีการเข้ารหัส

ส่วนใหญ่แล้วคุณไม่จำเป็นต้องใช้ปลั๊กอินนี้เลย ให้ใช้วิธี forward พอร์ตผ่าน SSH แทน

ssh -N -L 3080:127.0.0.1:3080 you@your-server

จากนั้นเปิด http://127.0.0.1:3080 ในเบราว์เซอร์ในเครื่องของคุณ harness จะยังคงฟังเฉพาะบน loopback ดังนั้นจึงไม่มีข้อมูลใดถูกเปิดเผย และเนื่องจากเบราว์เซอร์ถือว่า 127.0.0.1 เป็นแหล่งที่มาที่ปลอดภัย crypto.randomUUID() จึงพร้อมใช้งานและไม่จำเป็นต้องใช้ polyfill ใช้เพียงคำสั่งเดียว ไม่ต้องใช้ปลั๊กอิน และไม่สร้างพื้นผิวการโจมตีใหม่

ติดตั้งปลั๊กอินเฉพาะเมื่อการ forward ไม่สามารถใช้งานได้ เช่น เมื่อโทรศัพท์บนเครือข่ายเดียวกันจำเป็นต้องเข้าถึง UI หากคุณทำเช่นนั้น ให้ bind ไว้หลัง private network interface, รักษา firewall rule ที่อนุญาตเฉพาะอินเทอร์เฟซนั้น และระบุชื่อโฮสต์ที่คุณจะใช้ภายใต้ trustedHosts ในปลั๊กอิน 1.4.0 รายการนั้นจะอยู่ที่รายการ connection และรายการแบบ literal จะเข้ามาแทนที่ที่อยู่อินเทอร์เฟซที่ปลั๊กอินได้รับมาแทนที่จะเป็นการเพิ่มเข้าไป ดังนั้นให้เก็บ IP เหล่านั้นไว้ในรายการ สำหรับการเข้าถึงแบบหลายผู้ใช้อย่างแท้จริงจะมี dsh-passwords ซึ่งเพิ่มการเข้าสู่ระบบ, สิทธิ์ subuser, token รายชั่วโมงและขีดจำกัดเวลาต่อวันสำหรับ subuser, ใบรับรอง TLS (transport layer security) อัตโนมัติผ่าน Let's Encrypt บนการติดตั้งโฮสต์, audit log และการเข้ารหัสฟิลด์ที่ละเอียดอ่อนใน SQLite store ของมัน ให้พิจารณามันในฐานะแพลตฟอร์มมากกว่าปลั๊กอิน เส้นทางที่แนะนำซึ่งตรวจสอบเมื่อ 17 ตุลาคม 2026 คือ Docker container ที่เผยแพร่บน loopback เท่านั้น (-p 127.0.0.1:3088:3088) ซึ่งให้บริการ HTTP ธรรมดาและคาดหวังให้มี reverse proxy อยู่ด้านหน้าสำหรับ HTTPS การทำ HTTPS อัตโนมัติเป็นส่วนหนึ่งของการติดตั้งโฮสต์และต้องการพอร์ตสาธารณะ 80 และ 443; พอร์ต 80 ไม่จำเป็นหากคุณจัดเตรียมใบรับรองของคุณเองผ่าน MCP_GATEWAY_TLS_CERT และ MCP_GATEWAY_TLS_KEY เส้นทางด่วนของการติดตั้งโฮสต์จะส่ง shell script จากเครือข่ายตรงไปยัง sudo bash หากคุณติดตั้งบนโฮสต์ ให้เลือกใช้ npm install -g dsh-passwords ตามด้วย sudo dsh-passwords install เพื่อให้โค้ดอยู่บนดิสก์ที่คุณสามารถอ่านได้ก่อนที่มันจะทำงาน

วิธีการลบปลั๊กอินอย่างหมดจด

การถอนการติดตั้งมีสองขั้นตอน แต่ผู้ใช้มักข้ามขั้นตอนที่สองไป

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list ไม่ควรแสดงปลั๊กอินนั้นอีกต่อไป จากนั้นให้เปิด $DSH_HOME/profiles/web/cordis.patch.yml แล้วลบ block การแทรกที่เหลืออยู่ซึ่งระบุชื่อปลั๊กอินนั้นทิ้ง เนื่องจากรายการดังกล่าวคือสิ่งที่โหลดปลั๊กอินเข้าสู่ tree ให้รีสตาร์ท harness เพื่อให้ระบบสร้าง tree ขึ้นใหม่ เพราะปลั๊กอินที่โหลดไปแล้วจะยังคงทำงานอยู่จนกว่าคุณจะรีสตาร์ท สุดท้าย โปรดจำไว้ว่าข้อมูลจะยังคงอยู่แม้ตัวโค้ดจะถูกลบไปแล้ว $DSH_HOME/memory/memory.db และ .dsh/rules.yaml จะยังคงอยู่หลังการถอนการติดตั้ง ให้คุณลบไฟล์เหล่านี้ด้วยตนเองหากเป้าหมายของคุณคือการลบข้อมูลทั้งหมดออกไป

สิ่งที่ฉันอ่านและช่วงเวลาที่อ่าน

การอ้างอิงทุกจุดในที่นี้คือ commit ไม่ใช่ branch เนื่องจาก main จะเป็นโค้ดที่แตกต่างออกไปเมื่อคุณอ่านเนื้อหานี้ ฉันอ่านข้อมูลทั้งหมดนี้เมื่อวันที่ 17 สิงหาคม 2026 และตัว harness เองอยู่ที่ 0.1.0-rc.7 บน npm ในวันนั้น ฉันตรวจสอบค่าเริ่มต้นและพฤติกรรมที่อธิบายไว้ข้างต้นเทียบกับแหล่งข้อมูลหลักอีกครั้งเมื่อวันที่ 10 ตุลาคม 2026 ซึ่งในขณะนั้น tag latest บน npm คือ 0.2.0-rc.2 และได้ตรวจสอบความเข้ากันได้ของ harness ที่ประกาศไว้ในปลั๊กอินอีกครั้งเมื่อวันที่ 16 ตุลาคม 2026 ซึ่งยังคงเป็นค่าเดิม เมื่อวันที่ 17 ตุลาคม 2026 ฉันตรวจสอบโครงสร้าง profile เทียบกับเอกสารสถาปัตยกรรมของ harness, README ของ dsh-memory ทั้งสองฉบับ และ README ของ dsh-passwords อีกครั้ง โดยในวันนั้น latest ยังคงเป็น 0.2.0-rc.2 เมื่อวันที่ 18 ตุลาคม 2026 ฉันตรวจสอบทั้ง build ของ dsh-memory รวมถึงแพ็กเกจและ README ปัจจุบันของ dsh-web-lan-access อีกครั้ง โดย latest ยังคงเป็น 0.2.0-rc.2 และมี 0.2.1-rc.2 อยู่ที่ tag next เมื่อวันที่ 20 ตุลาคม 2026 ฉันตรวจสอบ README ของ SQLite dsh-memory ที่ def7c6a และ peer ranges ของ main, README ของ YAML build, เอกสาร Node node:sqlite และ dist-tags ของ npm อีกครั้ง โดยทั้ง latest และ next ชี้ไปที่ 0.2.1-rc.2

โปรดตรวจสอบค่าที่ระบุไว้เหล่านี้อีกครั้งก่อนที่คุณจะคัดลอกคำสั่งไปใช้งาน ในระบบนิเวศที่เป็น developer-preview หมายเลขเวอร์ชันที่ระบุวันที่กำกับไว้คือสิ่งเดียวที่มีความหมายชัดเจน

FAQ

ควรติดตั้งปลั๊กอิน DeepSeek Harness ตัวใดก่อนบน VPS?

ให้ติดตั้ง dsh-budget และ dsh-permission-rules ก่อนสิ่งอื่นใด การตั้งงบประมาณด้วย overLimit: block จะช่วยป้องกันไม่ให้การรันงานแบบอัตโนมัติใช้ทรัพยากรจนหมดทั้งคืน และไฟล์ .dsh/rules.yaml จะช่วยระงับการเรียกใช้เครื่องมือที่คุณไม่อนุมัติ เพิ่ม dsh-defend เมื่อเอเจนต์เริ่มอ่านข้อมูลจากเว็บสาธารณะ และเพิ่ม dsh-memory เมื่อคุณพบว่าตนเองต้องคัดลอกบริบทเดิมซ้ำๆ ในทุกเซสชัน สำหรับธีมและสถานะต่างๆ ให้ข้ามไปก่อน เพราะเป็นการเพิ่มโค้ดที่รันด้วยสิทธิ์ของเอเจนต์โดยไม่ได้เปลี่ยนการทำงานของเครื่อง

ปลั๊กอิน dsh ถูกแยกส่วน (sandbox) ออกจากตัว harness หรือไม่?

ไม่ ปลั๊กอินจะโหลดเข้าสู่ Cordis tree เดียวกับ harness ในกระบวนการ (process) เดียวกัน ภายใต้ผู้ใช้ระบบปฏิบัติการเดียวกัน ด้วย credential ของโมเดลชุดเดียวกัน และทำงานใน working tree เดียวกัน ปลั๊กอินที่เชื่อมต่อกับ tools/pre-execute จะเห็นและสามารถบล็อกการเรียกใช้เครื่องมือทุกอย่างได้ ส่วนปลั๊กอินที่เชื่อมต่อกับ agent/pre-step จะเห็นข้อความของคุณ ดังนั้นควรตรวจสอบซอร์สโค้ด ตรวจสอบไลเซนส์และวันที่คอมมิตล่าสุด และติดตั้งโดยระบุเลขคอมมิตแทนการใช้ชื่อ branch เพื่อป้องกันไม่ให้โค้ดเปลี่ยนแปลงโดยที่คุณไม่ทราบ

dsh-budget จะหยุดการทำงานของเอเจนต์จริงๆ หรือแค่แจ้งเตือน?

ขึ้นอยู่กับ overLimit ค่าเริ่มต้นคือ alert ซึ่งจะแจ้งเตือนที่ warnRatio และยังคงให้ใช้จ่ายต่อไป ส่วน block จะปฏิเสธการเรียกใช้โมเดลเพิ่มเติมเมื่อถึงขีดจำกัด และ /budget unblock <scope> จะปลดล็อกเมื่อคุณเลือกที่จะดำเนินการต่อ ส่วน degrade จะบล็อกการทำงานพร้อมคำแนะนำให้ใช้โมเดลที่ราคาถูกกว่าจากแผนผัง degradation มีข้อจำกัดหนึ่งที่สำคัญคือ ณ คอมมิตที่ระบุ 461d478 ยอดรวมจะถูกคำนวณในกระบวนการที่กำลังรันอยู่ ดังนั้นการรีสตาร์ท harness จะทำให้ยอดรีเซ็ต และการรีสตาร์ทแบบวนซ้ำจะทำให้ขีดจำกัดรายวันใช้งานไม่ได้ สำหรับ main ในปัจจุบันจะเก็บข้อมูลยอดใช้จ่ายรายวันและรายเดือนไว้แม้จะรีสตาร์ทก็ตาม อย่างไรก็ตาม ควรตั้งค่าขีดจำกัดการใช้จ่ายไว้ที่บัญชีของผู้ให้บริการเพื่อเป็นเพดานที่แท้จริง

จะลบปลั๊กอิน dsh ออกอย่างถาวรได้อย่างไร?

รันคำสั่ง dsh plugin --profile web remove <package-name> ยืนยันด้วย dsh plugin --profile web list จากนั้นเปิดไฟล์ $DSH_HOME/profiles/web/cordis.patch.yml แล้วลบส่วน insert block ที่เหลืออยู่ของปลั๊กอินนั้นออก เพราะรายการดังกล่าวคือสิ่งที่โหลดปลั๊กอินขึ้นมา จากนั้นให้รีสตาร์ท harness เพื่อสร้างปลั๊กอิน tree ใหม่ ข้อมูลที่ปลั๊กอินเขียนไว้จะยังคงอยู่บนดิสก์ โดยทั้ง $DSH_HOME/memory/memory.db และ .dsh/rules.yaml จะยังคงอยู่หลังการถอนการติดตั้งจนกว่าคุณจะลบออกด้วยตนเอง

การเปิดใช้งาน dsh web UI ผ่านเครือข่ายมีความปลอดภัยหรือไม่?

ไม่ปลอดภัยหากทำโดยลำพัง dsh web จะฟังที่ 127.0.0.1:3080 และ dsh-web-lan-access จะเปลี่ยนการผูกพอร์ตไปที่ 0.0.0.0 ณ คอมมิตที่อ้างถึงนี้ README ระบุว่าการตั้งค่าดังกล่าวทำให้เอเจนต์เข้าถึงได้โดยไม่ต้องมีการยืนยันตัวตนจากใครก็ตามที่อยู่ในเครือข่ายเดียวกัน โดยมีเพียง settings.*, credentials.* และ llm.discoverModels เท่านั้นที่ถูกจำกัดไว้ที่ loopback สำหรับ harness รุ่นปัจจุบันที่ตรวจสอบเมื่อวันที่ 10 ตุลาคม 2026 จะมีการยืนยันตัวตนเซสชันเบราว์เซอร์ด้วย launch token ใน URL ที่แสดงและ signed session cookie แต่หน้าล็อกอินจะถูกเปิดเผยบนทุกอินเทอร์เฟซ และ URL แบบ HTTP ปกติจะส่ง token ดังกล่าวเป็นข้อความธรรมดา (cleartext) ควรใช้ SSH port forward, ssh -N -L 3080:127.0.0.1:3080 you@your-server หรือวางพอร์ตไว้หลัง private network interface ร่วมกับกฎไฟร์วอลล์ และใช้ TLS ครอบหน้าบริการที่เข้าถึงได้จากภายนอกเสมอ