Toollance

Ngừng Duyệt Từng Lệnh Claude Code: Thiết Lập Sandbox Tích Hợp Sẵn

ai-codingclaude-codeworkflow

Nếu bạn chạy Claude Code với permission mặc định, bạn đã bấm “yes” cho cùng vài lệnh cả trăm lần trong tuần này — npm test, git status, ls, thêm một lần build nữa. Một bài viết gần đây trên XDA Developers chỉ ra một tính năng đã có sẵn trong Claude Code từ lâu nhưng ít người dùng đến: sandbox Bash tích hợp.

Sandbox thực sự làm gì

Thay vì duyệt từng lệnh một, bạn định nghĩa ranh giới một lần — thư mục nào một lệnh được ghi vào, domain mạng nào nó được truy cập — và hệ điều hành thực thi các ranh giới đó cho mọi lệnh Bash cùng các tiến trình con của nó. Trên macOS, sandbox dùng framework Seatbelt tích hợp sẵn; trên Linux và WSL2, nó dùng bubblewrap. Không cần cài gì trên macOS. Trên Linux/WSL2 bạn cần bubblewrap và socat:

sudo apt-get install bubblewrap socat   # Ubuntu/Debian
sudo dnf install bubblewrap socat       # Fedora

Chạy /sandbox trong một phiên để mở bảng cấu hình, hoặc bật toàn cục trong ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true
  }
}

Khi bật auto-allow mode, các lệnh Bash trong sandbox chạy mà không cần duyệt — chính ranh giới sandbox là thứ thay thế cú click duyệt, chứ không phải việc tin tưởng mù quáng vào model. Các quy tắc deny rõ ràng, các đường dẫn nguy hiểm kiểu rm -rf /, và các quy tắc giới hạn theo lệnh cụ thể (như Bash(git push *)) vẫn buộc phải duyệt ngay cả trong sandbox.

Vì sao điều này quan trọng hơn vẻ ngoài

Điều này quan trọng vì một lý do vượt ra ngoài sự tiện lợi. OpenAI đã xác nhận trong tuần này rằng GPT-5.6 có thể cố ghi đè biến môi trường $HOME để tạo một thư mục temp — và đôi khi lại xóa mất $HOME thật thay vì thư mục tạm. Ghi chú của chính OpenAI về sự cố này nói rõ khi nào nó xảy ra: “khi chế độ full access được bật, và Codex chạy mà không có bảo vệ sandbox, kể cả khi không bật auto review.” Nói cách khác, kiểu lỗi này không phải giả thuyết, và cách khắc phục không phải là một model thông minh hơn — mà chính là kiểu ranh giới ghi ở cấp hệ điều hành mà sandbox của Claude Code đã mặc định thực thi (quyền ghi giới hạn trong thư mục làm việc và thư mục temp của phiên, không gì ngoài đó nếu không có quy tắc allowWrite rõ ràng).

Sự khác biệt này quan trọng: permission rule ở bất kỳ agent nào cũng được đánh giá bằng cách so khớp chuỗi lệnh trước khi lệnh chạy. Một ranh giới sandbox được kernel thực thi trên tiến trình đang chạy, nên nó vẫn giữ nguyên hiệu lực ngay cả khi kế hoạch của model âm thầm làm nhiều hơn những gì tên lệnh gợi ý.

Một công thức cấu hình cho repo điển hình

Hầu hết repo thực tế cần vài công cụ ghi hoặc đọc ngoài thư mục làm việc. Hãy cấp quyền rõ ràng cho những công cụ đó thay vì tắt sandbox hoàn toàn:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.ssh", "~/.aws/credentials"]
    },
    "credentials": {
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

allowWrite bao phủ các công cụ như kubectl hoặc terraform cần ghi ngoài thư mục project của bạn — các giới hạn này được hệ điều hành thực thi, nên áp dụng cho mọi tiến trình con mà một lệnh sinh ra, không chỉ các tool chỉnh sửa file của riêng Claude. Hãy chạy mọi thay đổi cấu hình qua JSON Validator trước khi lưu settings.json — một dấu phẩy thừa ở cuối có thể âm thầm phá hỏng toàn bộ cấu hình sandbox ở lần khởi động phiên tiếp theo.

Vài điểm cần biết trước khi gặp phải giữa chừng công việc:

Kết luận

Sandbox không làm Claude Code thông minh hơn về việc nên chạy gì — nó thu nhỏ phạm vi ảnh hưởng khi có sự cố xảy ra, đúng là vấn đề mà sự cố $HOME của Codex minh họa. Nếu bạn đang phải duyệt tay từng lệnh npm test và ls, đây là mười lăm phút chỉnh settings.json mà bạn sẽ lấy lại được ở mọi phiên làm việc sau đó.