- Cách sử dụng an toàn cờ
--dangerously-skip-permissions của Claude Code
- Sau khi xem xét nhiều môi trường thực thi cách ly như Docker, VM, Firejail, tác giả kết luận máy ảo (VM) dựa trên Vagrant là phù hợp nhất
- Với Vagrant, có thể duy trì cách ly hoàn toàn bằng VM, cấu hình có thể tái lập, chia sẻ thư mục cục bộ, đồng thời tránh được vấn đề Docker-in-Docker
- Claude Code được cấu hình để tự do thao tác hệ thống với quyền sudo trong VM, và thực tế đã chạy ứng dụng web, cấu hình DB, tự động hóa kiểm thử, v.v.
- Cách này hiệu quả trong việc ngăn hỏng hệ thống tệp do thao tác nhầm, và khi cần có thể xóa rồi tạo lại VM để khởi tạo lại một cách an toàn
Bối cảnh
- Khi dùng Claude Code, để tránh sự bất tiện vì phải xác nhận yêu cầu quyền hạn mỗi lần, tác giả thử dùng cờ
--dangerously-skip-permissions
- Cờ này sẽ tự động thực hiện mọi tác vụ mà không cần phê duyệt trước, như cài gói, thay đổi cấu hình, xóa tệp, v.v.
- Dù hiệu quả hơn vì không làm gián đoạn luồng làm việc, nó vẫn tồn tại rủi ro làm hỏng hệ thống tệp
- Để ngăn điều đó, tác giả nhận ra cần chạy trong một môi trường tách biệt với tài khoản OS của máy chủ
Các phương án đã cân nhắc
- Tác giả ưu tiên xem xét cách ly bằng Docker, nhưng vì Claude phải build image Docker và chạy container nên sẽ cần cấu hình Docker-in-Docker
- Trong trường hợp này phải dùng chế độ
--privileged, khiến mục tiêu sandbox trở nên vô nghĩa
- Việc lồng mạng, vấn đề quyền mount volume, v.v. làm tăng độ phức tạp và tính bất ổn
- Các lựa chọn khác cũng được xem xét gồm
- Chạy trên bare metal: có các trường hợp hư hại nghiêm trọng như xóa cơ sở dữ liệu hoặc thư mục home trong các ví dụ trên Reddit
sandbox-runtime: kiểm soát truy cập dựa trên ACL, Claude không thể truy cập ngoài mã nguồn nhưng thiếu mức độ tự do hoàn toàn- Firejail: tồn tại các hạn chế tương tự Docker
- Tự thiết lập VM thủ công: thiếu tính tái lập
- VM trên cloud: có vấn đề về chi phí, độ trễ, và nhu cầu phải tải mã nguồn lên
Cách tiếp cận dựa trên Vagrant
- Dùng Vagrant để đạt được cách ly hoàn toàn bằng VM và cấu hình có thể tái lập
- Nhờ thư mục chia sẻ, có thể truy cập gần như ở môi trường cục bộ
- Không có vấn đề Docker-in-Docker, và khi cần có thể dễ dàng xóa rồi tạo lại VM
- Trong lúc dùng VirtualBox 7.2.4, tác giả phát hiện lỗi CPU chiếm 100%, rồi xác nhận nguyên nhân qua issue trên GitHub
- Cấu hình Vagrantfile cuối cùng có các đặc điểm sau
- Dùng image nền
bento/ubuntu-24.04
- Cấp phát 4GB bộ nhớ, 2 CPU
- Cài Docker, Node.js, npm, git, unzip
- Cài toàn cục
@anthropic-ai/claude-code
- Thêm người dùng
vagrant vào nhóm Docker
Cách sử dụng thực tế
- Trong thư mục dự án, chạy lần lượt
vagrant up → vagrant ssh → claude --dangerously-skip-permissions
- Lần khởi động đầu tiên mất vài phút để provisioning, và với mỗi dự án chỉ cần đăng nhập Claude một lần
- Khi kết thúc công việc, có thể tạm dừng VM bằng
vagrant suspend
- Claude được cấp quyền sudo trong VM để thực hiện các tác vụ như sau
- Chạy API của ứng dụng web và kiểm tra bằng
curl
- Cài trình duyệt rồi kiểm tra ứng dụng thủ công và tạo kiểm thử E2E
- Cấu hình DB PostgreSQL và kiểm thử migration
- Build và chạy image Docker
- Nhờ môi trường này, Claude có thể tự xử lý việc chạy lệnh, kiểm tra đầu ra, và lặp lại quy trình
Hiệu năng và an toàn
- Trên môi trường Linux + VirtualBox, tài nguyên khá dư dả, không có độ trễ đồng bộ tệp
- Những gì có thể bảo vệ
- Hỏng hệ thống tệp do thao tác nhầm
- Cài gói bừa bãi và thay đổi cấu hình
- Những gì không thể bảo vệ
- Xóa thư mục dự án (do đồng bộ hai chiều)
- Tấn công khai thác lỗ hổng escape khỏi VM
- Sự cố ở cấp độ mạng
- Rò rỉ dữ liệu (VM vẫn có thể truy cập Internet)
- Cấu hình này nhằm ngăn ngừa tai nạn, không phải để phòng thủ trước các cuộc tấn công nâng cao
- Với dự án dùng Git, việc khôi phục khi hư hại cũng dễ dàng; nếu cần có thể dùng đồng bộ một chiều bằng
rsync để cách ly nghiêm ngặt hơn
Kết luận
- Sau khi khắc phục lỗi CPU của VirtualBox, tác giả đã hoàn thiện một môi trường chạy gần như không ma sát
- Có thể tự do chạy Claude Code trong sandbox VM hoàn chỉnh
- Nếu có vấn đề xảy ra, chỉ cần xóa rồi tạo lại VM, và một Vagrantfile duy nhất là đủ để bảo đảm tính tái lập
- Nếu sử dụng cờ
--dangerously-skip-permissions, rất nên thiết lập một môi trường cách ly như thế này
1 bình luận
Ý kiến Hacker News
Khi dùng Claude một thời gian, cuối cùng bạn cũng sẽ rơi vào mệt mỏi khi ra quyết định (decision fatigue) và vài tháng sau thì chỉ bấm Enter đại thôi
Vì vậy tôi thấy chạy ở chế độ YOLO nhưng dựng sẵn môi trường sandbox còn an toàn hơn nhiều
Trên Ubuntu 22.04, tôi đã kết hợp bubblewrap và Landlock LSM để xây dựng sandbox phân tầng
Landlock giới hạn quyền truy cập hệ thống tệp theo whitelist, đồng thời kiểm soát cả truy cập cổng TCP
bubblewrap tách mount namespace để tạo
/tmpriêng theo từng dự án và ẩn các khóa bí mậtTôi dùng dnsmasq để thiết lập whitelist DNS, chỉ cho phân giải những tên miền cần thiết
Nhờ cấu trúc này, căng thẳng vì phải liên tục giám sát agent đã giảm đi
Việc phải duyệt thủ công từng mẩu elisp mà Claude đề xuất là một trải nghiệm kiệt sức
Dù tôi chỉ cần cẩn thận để Bash không cài linh tinh thứ gì đó, nó vẫn rất mệt
/sandboxTôi là Srini từ Docker
Rất nhiều lập trình viên đang dùng Docker để giải quyết vấn đề này, và chúng tôi cũng nhận được nhiều phản hồi về các hạn chế của Docker-in-Docker
Vì thế chúng tôi đã thử nghiệm phát hành Docker Sandboxes ở dạng preview
Vẫn còn ở giai đoạn đầu, nhưng chúng tôi đang phát triển phiên bản tiếp theo dựa trên MicroVM để tránh vấn đề Docker-in-Docker
Tôi muốn biết liệu Claude có thể khởi chạy các container khác bên trong Docker Sandbox mà không cần đặc quyền hay không
Có vẻ đa số mọi người đang cố tránh tự chạy VM cục bộ, nhưng tôi không hiểu tại sao
Thực ra VM cục bộ là cách đơn giản nhất và giải quyết được mọi vấn đề
Nếu bạn dùng Docker trên Mac thì nó vốn đã chạy trên một Linux VM, nên chỉ khác môi trường thực tế đúng một lớp
Bạn cũng có thể SSH thẳng từ IDE để kiểm tra mã
Tôi bật tùy chọn
--dangerously-skip-permissionsvà xử lý mọi thay đổi qua PRTôi đã dùng như vậy vài tháng nay cùng với workmux, và nó rất hiệu quả vì có thể xử lý nhiều PR cùng lúc
Lý do nó tốt hơn cloud VM là vì nếu chạy nhiều container đồng thời thì sẽ tốn rất nhiều bộ nhớ
Chạy cloud VM cấu hình cao 24/7 thì chi phí quá lớn
Một AI độc hại không cần khai thác lỗ hổng thoát VM, nó vẫn có thể thêm mã tùy ý vào Vagrantfile để giành quyền truy cập host
Ngay cả khi chỉ lo các lỗi vô ý, nếu Claude sửa commit hook thì lúc nó chạy cũng có thể gây vấn đề
Tôi cảm nhận rất rõ rằng việc vừa giữ cách ly hoàn toàn vừa duy trì sự tiện lợi khi phát triển thực sự rất khó
Ví dụ dùng Docker volume mount để chỉ cho phép sửa thư mục
sandbox/, còn.gitthì không thể truy cậpTôi thì chụp snapshot, khởi chạy một VM nhỏ để chạy agent, rồi so sánh lại snapshot sau đó
Tôi tuyệt đối không tự động đồng bộ vì như vậy sẽ phá vỡ mục tiêu cách ly
Tôi đang thử một cách tiếp cận khác — chặn lại những gì Claude định chạy
Shannot ghi lại ý định trước khi thực thi và chặn các system call trong sandbox PyPy
Lệnh và thao tác ghi tệp chỉ được ghi log chứ không thực sự thực thi
Chỉ khi người dùng xem xét trên TUI và phê duyệt thì nó mới chạy
Khác với VM ở chỗ VM cho phép chạy tự do trong một môi trường cách ly hoàn toàn, còn Shannot áp dụng các thay đổi lên hệ thống thật theo cơ chế phê duyệt của con người
Nó phù hợp cho các việc như chỉnh sửa máy chủ
Nó cũng có tích hợp Claude MCP, thực thi từ xa qua SSH, và tính năng checkpoint/rollback
Cuối cùng nó vẫn dừng ở yêu cầu phê duyệt đầu tiên, nên agent không thể tự do khám phá
Điều tôi muốn là agent có thể thử đến cùng mà không bị ngắt giữa chừng rồi mới đánh giá kết quả
Như vậy mới tiết kiệm được nhiều thời gian
Nó tương tự chế độ system extension native trên macOS của Leash, nhưng vẫn chưa có chế độ phê duyệt tương tác hoàn chỉnh
Đây là một dự án thú vị
Khi mệt mỏi vì phải phê duyệt quá nhiều, cuối cùng bạn sẽ muốn dùng
--dangerously-skip-permissionsVì vậy tôi chạy Claude Code bên trong devcontainer
Quyền truy cập tệp chỉ giới hạn trong kho mã, mạng chỉ cho phép theo whitelist
Sau đó tôi đã khái quát hóa nó bằng docker compose, và bước tiếp theo là thêm hỗ trợ cho các agent khác như Codex hay OpenCode
Tôi định ép mọi lưu lượng mạng đi qua proxy trên host để tăng cường ghi log và kiểm soát
Hiện tại tôi đang xử lý tạm bằng iptables
Mọi thứ vẫn còn sớm nhưng hoạt động khá ổn
Mã nguồn: agent-sandbox
Tôi dùng mitmproxy làm proxy mạng; chưa hoàn hảo nhưng gần như xong rồi
Claude đã tự cấu hình hệ thống trong vài giờ và hoàn thành ứng dụng
Chúng tôi không viết lấy một dòng mã nào mà kết quả lại tốt một cách đáng kinh ngạc
Tôi thực sự cảm nhận được tốc độ của phát triển bằng AI là quá khủng khiếp
Giải pháp của tôi rất đơn giản
Làm vậy thì lệnh npx sẽ chạy một cách trong suốt bên trong sandbox Bubblewrap, chỉ lộ ra thư mục hiện tại
Có thể triển khai chỉ bằng vài dòng shell POSIX thuần
sandbox-run
Một nhược điểm khác là một khi đã hạ quyền xuống thì không thể khôi phục lại được
Tôi thì chỉ việc nhét nó vào container LXC không đặc quyền là xong
Mô hình đe dọa của tôi không phải các cuộc tấn công phức tạp, mà là kiểu “lỡ tay xóa mất thư mục home”
Tôi đặt các script tiện ích trong thư mục
run/của dự án và khởi chạy container theo kiểu composedevcontainer được ánh xạ volume với thư mục trên host
Claude xử lý khá tốt các việc như cấu hình dịch vụ, cập nhật script, và chẩn đoán vấn đề runtime
Không có tích hợp trình duyệt, nhưng có vẻ Playwright hoặc Puppeteer là đủ dùng
Tôi muốn nghe ý kiến về sandboxing tích hợp sẵn của Claude Code
Liên kết tài liệu chính thức
Claude Code có một escape hatch cho phép tắt sandbox khi cần
Nếu lệnh thất bại vì giới hạn sandbox, Claude có thể phân tích nguyên nhân và thử lại với
dangerouslyDisableSandboxViệc agent có thể tự tắt sandbox nghe giống một điểm yếu, nên tôi muốn biết trong trường hợp này có quy trình yêu cầu người dùng phê duyệt hay không
Các issue liên quan: #14268, #13583, #10089