ไดเรกทอรีหายไปก่อนที่ใครจะอ่านบรรทัด log ที่อธิบายว่าทำไม

agent ที่เรากำลังรันบน scratch repo ได้รับคำสั่งให้ "ทำความสะอาด build artifacts" มันใช้เหตุผลจนมาถึง rm -rf ด้วย path ที่ประกอบจากตัวแปรที่สอง turn ก่อนหน้านี้เงียบ ๆ ถูก resolve เป็นสตริงว่าง rm -rf / เป็นเวอร์ชันในตำราของเรื่องตลกนี้ ตัวจริงเงียบกว่า: rm -rf "$BUILD_DIR/" ที่ $BUILD_DIR คือ "" และตอนนี้คุณกำลังลบจาก working directory ขึ้นไป เราโชคดี — มันเป็น clone แบบทิ้งได้ และความเสียหายที่หนักที่สุดคือบ่ายวันหนึ่ง แต่ฉันดู transcript ของ agent มามากพอที่จะรู้ความแตกต่างระหว่าง "สิ่งนี้ไม่ได้ทำร้ายเรา" กับ "สิ่งนี้ทำร้ายเราไม่ได้" และโมเดลที่ถือ shell ดิบอยู่ในหมวดแรกอย่างมั่นคง

เหตุการณ์นั้นคือเหตุผลทั้งหมดที่ฉันสนใจว่า agent สัมผัสดิสก์อย่างไร บทเรียนไม่ใช่ "โมเดลอันตราย" โมเดลไม่มีเจตนาร้าย; มันผิดอย่างมั่นใจ และการผิดอย่างมั่นใจเมื่อมี rm -rf ในมือเป็นปัญหาความปลอดภัยไม่ว่าจะมีใครตั้งใจทำร้ายหรือไม่ การแก้ไขเป็นแบบเดียวกับที่เราใช้กับโค้ดที่ไม่น่าไว้ใจมาห้าสิบปี: อย่าส่งมอบทั้งเครื่องให้มัน ให้ interface ที่แคบ มี type และสังเกตได้ จำกัดขอบเขตที่ interface นั้นจะเอื้อถึง และทำให้การดำเนินการที่อันตรายเป็นไปไม่ได้หรือดัง

interface นั้นสำหรับไฟล์คือ filesystem MCP server โพสต์นี้เกี่ยวกับ Octofs — ตัวที่เราสร้างและรัน — จากมุมความปลอดภัย: มันจำกัดอะไรจริง ๆ อะไรที่ตั้งใจไม่จำกัด และจะกำหนดค่าอย่างไรให้ rm -rf ครั้งต่อไปไม่มีอะไรจะเกาะ

โมเดลภัยคุกคาม: shell ดิบให้อะไรจริง ๆ

เริ่มด้วยความซื่อสัตย์เกี่ยวกับสิ่งที่คุณกำลังมอบเมื่อคุณให้ bash กับ agent

shell ไม่ใช่ "เครื่องมือไฟล์" มันเป็น launcher สำหรับโปรแกรมตามอำเภอใจที่มี ambient authority เต็มที่ของ process ที่ให้กำเนิดมัน — user account ของคุณ environment variables ของคุณ SSH agent ของคุณ cloud credentials ที่นั่งอยู่ใน ~/.aws kubeconfig ของคุณ ทุก volume ที่ mount ต้นไม้ทั้งหมดจาก / ลงไป เมื่อโมเดลปล่อย curl ... | sh shell ก็รันมัน เมื่อมันปล่อย rm -rf กับ path ที่มัน hallucinate shell ก็ลบมัน เมื่อมันรัน git push กับ remote ที่ผิด shell ก็ push งานของ shell คือทำตามที่บอกทันที โดยไม่มีแนวคิดว่า "คุณหมายถึงอย่างนั้นจริง ๆ เหรอ?"

วาง failure modes ของโมเดลทับบน authority นั้น และคุณจะได้ชุดของเหตุการณ์ที่เฉพาะเจาะจงและเกิดซ้ำ:

  • Path drift Agent สร้าง path จากตัวแปร ผลลัพธ์ของเครื่องมือก่อนหน้า หรือความจำของตัวเองเกี่ยวกับโครงสร้าง repo ตัวแปรว่างเปล่า ผลลัพธ์ถูกตัดทอน ความจำเก่า — และ path ตอนนี้ชี้ไปที่ไหนที่ไม่ตั้งใจ shell ไม่สน
  • Destructive verbs บน path ที่ผิด rm -rf, mv ทับไฟล์ที่มีอยู่, truncation ด้วย > file, git checkout -- . ที่ล้างงานที่ยังไม่ commit แต่ละอันอยู่ห่างจากเวอร์ชันที่ไม่เป็นอันตรายแค่หนึ่ง token
  • อ่านสิ่งที่ไม่ควรอ่าน dump ของ cat ~/.ssh/id_ed25519 หรือ env ที่ดึง secrets เข้าไปใน context window ซึ่งถูก log, cache และอาจส่งไปยัง model API การ exfiltration ไม่ต้องการเจตนาร้าย; ต้องการ agent ที่ "อย่างช่วยเหลือ" รวมไฟล์ที่ผิด
  • Interactive hangs คำสั่งที่ prompt รหัสผ่านหรือเปิด pager โดยไม่มี TTY ที่จะตอบ และ session ค้าง
  • Orphaned processes background server ที่ agent spawn แล้วลืม ยังคงถือ port อยู่หลังจาก session จบ

ไม่มีข้อใดต้องการ jailbreak สิ่งเหล่านี้คือพฤติกรรม ที่คาดไว้ ของระบบที่อาศัยความน่าจะเป็นที่เชื่อมต่อโดยตรงกับระบบที่เป็น imperative การลดความเสี่ยงเป็นเชิงสถาปัตยกรรม: แทนที่ launcher แบบเปิดด้วยชุดปิดของการดำเนินการที่มีชื่อ และจำกัดขอบเขตพื้นผิวที่การดำเนินการเหล่านั้นจะเอื้อถึงได้

ทำไมเครื่องมือไฟล์ที่จำกัดขอบเขตถึงดีกว่า bash ดิบ

กรณีสำหรับ filesystem MCP server โดยเฉพาะเหนือการเข้าถึง shell ดิบเป็นกรณีเดียวกับที่เราเสนอสำหรับ การเก็บ custom tools ไว้ใน repo ของคุณ: เครื่องมือที่แคบและมีชื่อให้ทางที่ผิดน้อยกว่าแก่โมเดล และให้ คุณ สถานที่ในการบังคับใช้กฎ

ในทางปฏิบัติ การสลับ bash ด้วยเครื่องมือไฟล์เปลี่ยนสี่สิ่งพร้อมกัน:

  1. Verbs มีจำกัดและมีชื่อ แทนที่จะเป็น "โปรแกรมใดก็ได้ใน PATH" โมเดลเห็น view, text_editor, batch_edit, extract_lines, shell, workdir แต่ละตัวมี schema ไม่มีการดำเนินการของ text_editor ที่หมายถึง "ลบ tree แบบ recursive" เพราะการดำเนินการนั้นไม่เคยถูกกำหนด คุณยิงเท้าตัวเองด้วยปืนที่ไม่อยู่ในลิ้นชักไม่ได้
  2. พื้นผิวเริ่มต้นคือโปรเจกต์ของคุณ ไม่ใช่ home directory Octofs ใช้ working root และ resolve relative paths กับมัน โหมดการทำงานตามธรรมชาติของ agent — "แก้ src/main.rs" — ไม่ออกจาก root นั้น
  3. การอ่านถูกกรอง directory traversal ตระหนักเรื่อง .gitignore และข้าม dotfiles โดยค่าเริ่มต้น ดังนั้น .env, .ssh, node_modules และทุกอย่างที่คุณบอก git ให้ ignore ไม่ปรากฏใน listings หรือ content searches Agent ไม่อ่านสิ่งที่มองไม่เห็น
  4. ทุกการดำเนินการสังเกตได้และย้อนกลับได้ การแก้ไขผ่าน atomic writes ที่มี undo ได้ถึงสิบระดับต่อไฟล์ ไม่มีสถานะ "ไฟล์เขียนครึ่งเดียวและ process ตาย" และมี undo_edit สำหรับ "การแก้ไขนั้นผิด"

shell ไม่หายไป — agent ต้องรัน builds และ tests จริง ๆ — แต่มันหยุดเป็น primary file interface และนั่นคือส่วนใหญ่ของการต่อสู้ ยิ่งการดำเนินการไฟล์ผ่าน shell ดิบน้อยลง โมเดลยิ่งมีโอกาสน้อยลงที่จะทำให้ path ลอยไปสู่สิ่งที่ทำลายล้าง

Octofs เปิดเผยอะไรจริง ๆ

หก MCP tools และนั่นคือพื้นผิวทั้งหมด การรู้รายการที่แน่นอนมีความสำคัญ เพราะ argument ด้านความปลอดภัยคือ "เหล่านี้และไม่มีอะไรอื่น"

เครื่องมือ มันทำอะไร ทำไมปลอดภัยกว่าคู่เทียบใน shell
view อ่านไฟล์ (เดี่ยว พร้อม line ranges) list directories ด้วย glob patterns ค้นหา file contents ตระหนักเรื่อง gitignore และกรอง dotfiles — แทน cat/grep/find/ls โดยไม่เปิดเผย paths ที่ถูก ignore
text_editor create, str_replace, delete, undo_edit บนไฟล์ Atomic writes, undo history, fuzzy match แทนการ corruption เงียบ ๆ ด้วย sed
batch_edit การดำเนินการ insert/replace หลายรายการบนไฟล์เดียว ที่ใช้ atomic Conflict detection ปฏิเสธการแก้ไขที่ทับซ้อนหรือคลุมเครือก่อนแตะดิสก์
extract_lines คัดลอก line range จากไฟล์หนึ่งและต่อท้ายไปอีกไฟล์ การคัดลอกที่จำกัดและมี type แทน pipe ที่สร้างเองด้วย head/tail
shell รันคำสั่ง foreground หรือ background บังคับ non-interactive, process-group cleanup, misuse hints
workdir รับ ตั้ง หรือ reset working directory ของ session ทำให้ขอบเขตชัดเจนและตรวจสอบได้ แทนที่จะอยู่ใน cd โดยปริยาย

configuration flags สองตัวกำหนดรูปแบบทั้งหมด ตั้งเมื่อคุณ launch server:

# จำกัด working root และใช้ stable hash-based line IDs
octofs mcp --path /path/to/your/project --line-mode hash

--path ตั้ง working root --line-mode hash สลับ line identifiers จาก sequential numbers เป็น 4-character hashes ที่ derive จาก content ซึ่งคงที่ระหว่างการแก้ไข — ฟีเจอร์ด้านความน่าเชื่อถือ แต่ก็ใกล้เคียงกับความปลอดภัยด้วย เพราะ stable references หมายถึงข้อผิดพลาด "แก้ผิดบรรทัดเพราะตัวเลขขยับ" น้อยลง ยังมี --bind host:port เพื่อรันผ่าน Streamable HTTP แทน stdio เมื่อคุณต้องการ remote หรือ multi-client setup

ใน Claude Desktop, Cursor หรือ Windsurf config จะมีลักษณะดังนี้:

{
	"mcpServers": {
		"octofs": {
			"command": "/path/to/octofs",
			"args": ["mcp", "--path", "/path/to/your/project", "--line-mode", "hash"]
		}
	}
}

--path นั้นคือการตัดสินใจด้านความปลอดภัยที่สำคัญที่สุดที่คุณทำกับเครื่องมือนี้ มันคือความแตกต่างระหว่าง "agent ทำงานบนโปรเจกต์นี้" กับ "agent ทำงานบน laptop ของฉัน" ตั้งมันไปที่ directory ที่แคบที่สุดที่งานต้องการ

การป้องกัน เรียงตามความถี่ที่ช่วยคุณ

นี่คือสิ่งที่ Octofs บังคับใช้จริง ๆ อิงจากโค้ด ไม่ใช่จาก brochure

Scoped working root

Relative paths resolve กับ working root ที่คุณส่งไปยัง --path (หรือ current directory ถ้าคุณไม่ส่ง) Agent ที่พูดว่า view src/main.rs resolve เป็น <root>/src/main.rs mental model ทั้งหมดของโมเดลเกี่ยวกับ "โปรเจกต์" ถูกยึดกับ root นั้น และตราบเท่าที่มันทำงานใน relative paths — ซึ่งเป็นค่าเริ่มต้น — มันไม่เคยเอื้อถึงภายนอก

Gitignore-aware, dotfile-filtered traversal

Directory listing และ content search ใช้ walker ของ ignore crate ด้วย git_ignore(true) และ hidden files ถูก исключёнโดยค่าเริ่มต้น ผลในทางปฏิบัติ: เมื่อ agent list directory หรือค้นหา string มันไม่เห็น .git/, .env, .ssh/, build output, node_modules หรืออะไรก็ตามใน .gitignore ของคุณ Secrets ที่คุณ исключёнออกจาก version control แล้วก็ исключёнออกจากมุมมองของ agent ด้วย นี่คือการป้องกันที่ถูกที่สุดและถูกประเมินต่ำที่สุด — agent ไม่สามารถ leak ไฟล์ที่ไม่เคยรู้ว่ามีอยู่

Atomic writes พร้อม undo history

ทุกการแก้ไขเขียนไปยัง temporary file ใน directory เดียวกัน แล้ว rename ทับ target — atomic operation ที่ระดับ filesystem ไฟล์ไม่เคยถูกสังเกตว่าเขียนครึ่งเดียว; ถ้า process ตายกลางแก้ไข original ยังอยู่ครบ Original file permissions ถูก preserve ข้าม write (fix ที่มาถึงใน 0.4.2 โดยเฉพาะเพื่อที่ write จะไม่ขยาย file mode เงียบ ๆ) ก่อน write แต่ละครั้ง content ก่อนหน้าถูก snapshot ได้ลึกถึงสิบระดับต่อไฟล์ เข้าถึงได้ผ่าน undo_edit ของ text_editor "Agent ทำไฟล์พัง" หยุดเป็น recovery operation และกลายเป็น tool call เดียว

Batch conflict และ duplicate detection

batch_edit ตรวจสอบทุก operation กับทุก operation อื่น ก่อน เขียน Overlapping replace ranges ถูกปฏิเสธ Inserts สองตัวที่ anchor เดียวกันถูกปฏิเสธว่าคลุมเครือ Batch ทั้งหมดถูกจำกัดที่ 50 operations และทุก replacement ถูกตรวจสอบ boundary duplication — failure แบบคลาสสิกที่โมเดลรวมบรรทัด "context" เพิ่มหนึ่งบรรทัดและ duplicate เข้าไปในไฟล์เงียบ ๆ ไม่มีสิ่งเหล่านี้แตะดิสก์จนกว่าแผนจะ consistent ภายใน

Non-interactive shell enforcement

เมื่อ agent ใช้ shell คำสั่งรันด้วย stdin ตั้งเป็น null ใน process group ของตัวเอง ด้วย GIT_TERMINAL_PROMPT=0, DEBIAN_FRONTEND=noninteractive, PAGER=cat, และ GIT_PAGER=cat คำสั่งที่จะ prompt credential ล้มเหลวเร็วแทนที่จะค้าง session คำสั่งที่จะ page output ปล่อยมันออกมาตรง ๆ แทนที่จะเรียก less กับ TTY ที่ไม่มีอยู่ Session ไม่สามารถค้างบน interactive prompt ที่โมเดลตอบไม่ได้

Process-group cleanup เมื่อปิด

Foreground commands ถูก spawn ใน process group ของตัวเองและติดตามด้วย PID เมื่อ SIGTERM หรือ EOF Octofs ส่ง SIGKILL ไปยังทุก tracked group — รวมถึง grandchildren — ดังนั้นไม่มีอะไรที่คำสั่งทิ้งไว้ครึ่ง ๆ ที่จะอยู่เกิน session Background commands (background: true) เป็นข้อยกเว้นโดยตั้งใจ: พวกมันถูก detach เพื่อให้อยู่เกิน call ได้ Octofs ส่ง PID ให้ agent และการ kill มันเมื่องานเสร็จเป็นงานของ agent — kill <pid>

Shell-misuse hints

อันนี้เป็นการ nudge ไม่ใช่กำแพง แต่มัน shape พฤติกรรมตลอด session เมื่อ agent รัน cat, grep, find, ls, sed, หรือ awk ผ่าน shell Octofs ต่อท้าย hint ไปยัง response เพื่อ steer ไปยัง dedicated tool: ใช้ view เพื่ออ่านหรือค้นหา ใช้ text_editor เพื่อแก้ไข ตลอด session agent เรียนรู้ที่จะ route file operations ผ่าน tools ที่มี safety net แทน shell ที่ไม่มี Destructive verbs ที่ไหลผ่าน open-ended interface น้อยลงคือเป้าหมาย

Octofs ไม่ทำอะไร — และทำไมฉันถึงบอกคุณ

โพสต์ความปลอดภัยที่ list แค่ protections เป็น marketing นี่คือขอบเขต ที่กล่าวตรง ๆ เพราะการ configure รอบ ๆ มันอย่างถูกต้องขึ้นอยู่กับการรู้ว่ามันอยู่ที่ไหน

Octofs ไม่ใช่ chroot jail Working root จำกัด relative paths มันไม่ confine absolute paths resolve_path เป็นสอง branch: relative path ถูก join กับ working root; absolute path ถูกใช้ as-is ไม่มีการปฏิเสธ .. traversal และไม่มี check ว่า resolved path ยังอยู่ใต้ root ถ้าโมเดลปล่อย view /etc/passwd หรือ text_editor กับ /Users/you/.ssh/config Octofs จะ resolve absolute path นั้นและทำงานกับมัน Scoping เป็น default ที่แข็งแกร่งและ convention ที่แข็งแกร่ง — agent ที่ทำงานใน relative paths ไม่เคยออกจากโปรเจกต์ — แต่มันไม่ใช่ขอบเขตที่แข็งตัวต่อ path ที่ตั้งใจหรือบังเอิญกลายเป็น absolute

นี่คือจุด design ที่ตั้งใจ ไม่ใช่ oversight: Octofs เป็นเครื่องมือ productivity สำหรับ cooperative agent ไม่ใช่ containment layer สำหรับ hostile แต่มันเปลี่ยนวิธีที่คุณควร deploy มันเมื่อ blast radius สำคัญ:

  • รันมันกับ dedicated directory ไม่ใช่ home ของคุณ --path ที่แคบที่สุดที่คุณหลีกเลี่ยงได้ ถ้างานต้องการแค่ repo เดียว ชี้ไปที่ repo นั้น
  • สำหรับ hard isolation ใช้ OS เครื่องมือ filesystem ไม่สามารถ out-sandbox kernel ได้ ถ้าคุณไม่ไว้ใจจริง ๆ ว่า agent อาจทำอะไร — untrusted code, autonomous loop, CI runner — รัน Octofs และ agent ภายใน container, VM, หรือ user account ที่ ไม่สามารถ เห็น secrets ของคุณ โดย mount แค่ project directory แล้ว absolute-path gap ก็ไม่เกี่ยว เพราะไม่มีอะไรนอก mount ให้ไปถึง Defense in depth: scoped tool ทำให้ common case แคบลง; OS sandbox จับ path ที่กลายเป็น absolute
  • เก็บ secrets ไม่ให้อยู่ใน working root และไม่อยู่ใน git เพราะ traversal ตระหนักเรื่อง gitignore secrets ที่คุณ gitignore แล้วยังคงมองไม่เห็นใน listings และ search นั่นคือการลด accidental exposure จริง — พึ่งมัน credential ที่ agent enumerate ไม่ได้คือ credential ที่ paste เข้า context window ไม่ได้

สรุปตรง ๆ หนึ่งบรรทัด: Octofs ลบ accidental foot-guns — rm -rf ที่ตัวแปรว่าง, sed ที่ corruption เงียบ ๆ, ไฟล์ที่เขียนครึ่งเดียว, pager ที่ค้าง — และทำให้ default surface แคบลง มันไม่ contain agent ที่ determined หรือสับสนอย่างถึงที่สุดที่ construct absolute path ด้วยตัวเอง จับคู่มันกับ OS sandbox เมื่อคุณต้องการ guarantee นั้น

การ configure อย่างเข้มงวด: checklist

ถ้าคุณต้องการความปลอดภัยสูงสุดที่เครื่องมือนี้ให้ได้ ให้ configure แบบนี้:

  1. ตั้ง --path ไปที่ project directory ที่แคบที่สุดที่งานต้องการ ไม่ใช่ home ไม่ใช่ / ไม่ใช่ parent ที่มี repo อื่นอีกห้า หนึ่งโปรเจกต์ หนึ่ง root
  2. Gitignore secrets ของคุณก่อนที่จะชี้ agent ไปที่ repo .env, *.pem, credential files, local config พวกมันกลายเป็นมองไม่เห็นใน view listings และ search ฟรีและใช้งานได้
  3. ใช้ --line-mode hash สำหรับ multi-step editing agent ใด ๆ Stable line references หมายถึงข้อผิดพลาด "แก้ผิดบรรทัด" น้อยลง ซึ่งเป็นทั้งความน่าเชื่อถือและความปลอดภัย
  4. Prefer typed tools เหนือ shell ในคำสั่งของ agent ของคุณ Misuse hints ผลักไปในทิศทางนี้; เสริมมัน ทุกไฟล์ที่อ่านผ่าน view แทน cat คือไฟล์ที่เคารพ ignore rules
  5. Gate destructive operations ใน permission layer ของ agent runtime Octofs เปิดเผย tools; runtime ของคุณตัดสินว่าตัวไหนต้อง approval Auto-approve view Always-ask shell และ text_editor delete นี่คือที่ที่มนุษย์อยู่ใน loop สำหรับ verbs ที่ undo ด้วย undo_edit ไม่ได้
  6. เมื่อ blast radius เป็นจริง ใส่ทั้งหมดใน container Mount แค่ project directory ตอนนี้ absolute-path gap ถูกปิดโดย kernel ไม่ใช่โดยความหวัง

การเปลี่ยน mental model คือประเด็น คุณไม่ได้ไว้ใจโมเดลว่าจะระมัดระวัง คุณจัดโลกให้ความไม่ระมัดระวังมี blast radius เล็ก — scoped root, filtered reads, reversible writes, non-interactive shell, และ explicit working directory

FAQ

Octofs ป้องกัน agent ไม่ให้รัน rm -rf ได้หรือไม่?

ไม่โดยตรง — shell ยังคงรันคำสั่งตามอำเภอใจ รวมถึง rm สิ่งที่ Octofs เปลี่ยนคือ file editing และ reading ไม่ต้องการ shell แล้ว ดังนั้น destructive shell commands จึงถูกสร้างน้อยลงตั้งแต่แรก; และ working root บวก gitignore-aware traversal หมายความว่าการดำเนินการตามธรรมชาติของ agent อยู่ภายในโปรเจกต์ สำหรับ hard guarantee ว่า rm -rf ไม่สามารถไปถึงอะไรที่สำคัญ ให้รัน Octofs ภายใน container ที่ mount แค่ project

Working root เป็น sandbox ไหม?

มันเป็น scoped default ไม่ใช่ jail Relative paths resolve กับ root; absolute paths ถูกใช้ as-is โดยไม่ปฏิเสธ .. มอง --path เป็น "ที่ที่ agent ทำงาน" ไม่ใช่ "ที่ที่ agent ถูก confine" สำหรับ confinement ใช้ OS-level sandbox

มันหยุด secrets ไม่ให้รั่วเข้า context ได้อย่างไร?

Directory listing และ content search ตระหนักเรื่อง .gitignore และข้าม dotfiles โดยค่าเริ่มต้น ไฟล์ที่คุณ исключёнออกจาก git แล้ว — .env, key files, อะไรก็ตามใน .gitignore — ไม่ปรากฏใน listings หรือ searches ดังนั้น agent จึงอ่านเข้า context ไม่ได้ การป้องกันดีเท่าที่ .gitignore ของคุณเท่านั้น ดังนั้นจัดการมันก่อนที่จะชี้ agent ไปที่ repo

ไฟล์ที่เขียนครึ่งเดียวถ้า process crash กลางแก้ไขล่ะ?

เป็นไปไม่ได้ Writes ไปยัง temp file ใน directory เดียวกันและถูก rename ทับ target แบบ atomic ถ้า process ตาย original ยังอยู่ครบ Permissions ถูก preserve ข้าม write

ทำไมหก tools แทนที่จะเปิดเผยแค่ filesystem?

ชุดการดำเนินการที่จำกัดและมีชื่อคือฟีเจอร์ความปลอดภัย โมเดลไม่สามารถหยิบ verb "ลบ tree" ที่ไม่เค�ยถูกกำหนด และคุณได้สถานที่เดียว — tool boundary — เพื่อบังคับ atomic writes, undo, conflict detection, และ ignore rules Tools ที่น้อยและแคบกว่ายังเลือกได้ง่ายกว่าสำหรับโมเดล

มันทำงานนอก Octomind ได้ไหม?

ได้ Octofs พูด MCP ผ่าน stdio หรือ Streamable HTTP และทำงานกับ MCP client ใดก็ได้ — Claude Desktop, Cursor, Windsurf, Zed — บวกกับ Octomind agent runtime

agent ที่เกือบลบ scratch directory นั้นยังคงรันใน setup ของเราทุกวัน โมเดลไม่ได้ระมัดระวังมากขึ้นกว่าเดิม มันมีสิ่งที่จะพังน้อยลงมาก

สิ่งที่เปลี่ยนคือโลกรอบ ๆ มัน: มันอ่านผ่าน view แก้ผ่าน text_editor ทำงานภายใน --path ที่ scoped ไปยัง repo เดียว และเมื่อเดิมพันเป็นจริง ทั้งหมดนั่งอยู่ภายใน container ที่มองไม่เห็นอะไรอื่น

ให้ agent มีไฟล์ซิสเต็ม แค่อย่าให้ของคุณ

— Don

Octofs เป็น open source ภายใต้ Apache-2.0 — Rust binary เดี่ยว เวอร์ชันปัจจุบัน 0.5.0 scoping, gitignore-aware traversal, atomic writes, และ non-interactive shell ที่อธิบายไว้ที่นี่ล้วนอยู่ใน source; absolute-path caveat ก็เช่นกัน ถ้าการป้องกันที่คุณต้องการไม่อยู่ที่นั่น เปิด issue.