# ให้ AI Agent มีไฟล์ซิสเต็ม โดยไม่ต้องให้ไฟล์ซิสเต็มทั้งหมดของคุณ

> คู่มือที่เน้นเรื่องความปลอดภัยสำหรับการแยกการเข้าถึงไฟล์ของ AI agent ด้วย filesystem MCP server Octofs จำกัด working root อย่างไร ตระหนักเรื่อง gitignore บังคับใช้ non-interactive shell และตัดหมวดหมู่ของ foot-gun ทั้งหมดที่ bash ดิบและ rm ส่งต่อให้ agent — รวมถึงการป้องกันที่ไม่มี และวิธีกำหนดค่าเพื่ออยู่รอบ ๆ สิ่งเหล่านั้น

ไดเรกทอรีหายไปก่อนที่ใครจะอ่านบรรทัด 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](/blog/introducing-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 ของคุณ](/blog/custom-mcps-belong-in-your-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:

```bash
# จำกัด 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 จะมีลักษณะดังนี้:

```json
{
	"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](https://github.com/muvon/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](https://github.com/muvon/octofs/issues)._