Các AI coding agents như Claude Code, GitHub Copilot CLI, Codex, Gemini và Cursor giờ có thể chạy ở chế độ “autonomous”. Nghĩa là chúng có thể run lệnh, sửa file và cài package mà không cần hỏi bạn từng bước. Claude Code thậm chí có flag tên --dangerously-skip-permissions cho việc này. Agent nhanh hơn, nhưng cũng rủi ro hơn: một agent có thể chạy rm -rf, đọc secret key, hoặc phá service. Nếu chạy trực tiếp trên laptop, agent có thể chạm vào mọi thứ mà tài khoản người dùng của bạn có thể chạm tới.

Quan điểm của Docker rất đơn giản: một mô hình AI không nên tự quyết định giới hạn an toàn của nó. Quyết định đó phải đến từ hệ thống xung quanh, không phải từ chính mô hình. Vì vậy, nhóm Docker giới thiệu công cụ Docker Sandboxes.

Docker Sandboxes cấp cho mỗi AI agent một vùng compute nhỏ, dùng một lần và có thể vứt bỏ. Agent làm gì tùy ý bên trong vùng đó. Khi xong việc, bạn vứt bỏ toàn bộ.

Docker Sandboxes thực sự là gì?

Trước tiên, cần nói rõ công cụ này là gì và không phải là gì.

  • Nó không phải là container. Đúng, nó mang tên Docker và chạy container bên trong. Nhưng mỗi phiên sandbox chạy trong microVM riêng với kernel riêng. Đây là cô lập thật, ở mức phần cứng, như một máy ảo đầy đủ, không phải kiểu cô lập nhẹ mà container thường dùng.
  • Nó không cần Docker Desktop. Nó đi kèm công cụ dòng lệnh riêng là sbx. Bạn có thể dùng trên máy chưa từng cài Docker Desktop.
  • Mỗi sandbox có daemon Docker riêng. Điểm này khác biệt so với các công cụ sandbox agent khác. Agent có thể chạy docker build, docker run và docker compose hoàn toàn bên trong sandbox, không cần dùng chung Docker của host.
  • Ranh giới cô lập là hypervisor, không chỉ là process. Nếu agent bị xâm nhập hoặc chạy sai, nó vẫn không chạm được file host, daemon Docker của host, sandbox khác hay mạng của bạn. Nó chỉ chạm những gì bạn cho phép một cách tường minh.

Để làm được điều này trên mọi nền tảng, Docker tự xây dựng Virtual Machine Monitor (VMM). Họ không dùng Firecracker, vì Firecracker chỉ chạy trên Linux với KVM. Thay vào đó, VMM của Docker chạy native bằng:

  • macOS: Hypervisor.framework của Apple
  • Windows: Windows Hypervisor Platform (WHP)
  • Linux: KVM

Đây là lý do sandbox khởi động gần như tức thì dù dùng cô lập cấp VM.

Cách nó được xây dựng (Kiến trúc)

Dưới đây là các điểm chính, dựa trên tài liệu bảo mật của Docker:

  • Thư mục dự án của bạn là cầu nối mặc định duy nhất tới host. Mặc định, Docker Sandboxes chia sẻ thư mục dự án với sandbox ở chế độ đọc-ghi. Đó là phần duy nhất của máy tính mà agent thấy được. Mọi thứ khác — file khác, daemon Docker của host, mạng — đều nằm ngoài sandbox.
  • Lưu lượng mạng đi qua proxy. Proxy kiểm tra từng yêu cầu đi ra theo danh sách allow/deny. Proxy cũng tiêm credentials như GitHub token hoặc model API key ở tầng proxy, nên agent có thể không bao giờ thấy secret thật. Nó chỉ dùng được secret cho các đích đã được phê duyệt.
  • Mọi thứ bên trong sandbox có thể vứt bỏ. Package đã cài, image đã tải, container đang chạy và shell history đều nằm trong filesystem riêng của sandbox. Khi xóa sandbox, tất cả biến mất. Host không bị ảnh hưởng.

Tuyên bố miễn trừ trách nhiệm: Docker Sandboxes còn mới. Docker giới thiệu lần đầu vào tháng 12 năm 2025 và ra mắt khoảng tháng 3 năm 2026. Công cụ thay đổi nhanh. Phiên bản ổn định hiện tại tại thời điểm viết bài là v0.38.0. Một số tính năng như custom “kits” vẫn bị gắn nhãn Early Access. Lệnh có thể thay đổi. Luôn chạy sbx version để kiểm tra, và xem tài liệu chính thức.

Cài đặt Docker Sandboxes trên Linux, macOS và Windows

Điều kiện tiên quyết theo nền tảng

Linux: Kiểm tra KVM có sẵn

Trước khi thử bất cứ thứ gì khác, hãy kiểm tra module KVM đã bật chưa:

lsmod | grep kvm

Bạn sẽ thấy kvm_intel, kvm_amd hoặc kvm trong đầu ra:

kvm_intel             552960  0
kvm                  1527808  1 kvm_intel
irqbypass              16384  1 kvm

Nếu không thấy gì, chạy kvm-ok để biết lý do. Không có KVM, sbx sẽ không khởi động. Bạn cũng cần thêm user của mình vào nhóm kvm:

sudo usermod -aG kvm $USER

Sau đó đăng xuất rồi đăng nhập lại, hoặc chạy newgrp kvm, để thay đổi có hiệu lực.

Nếu bạn chạy thiết lập này bên trong VM hoặc môi trường VDI, bạn cần bật nested virtualization. Docker Sandboxes tự nó là công cụ hypervisor, nên VM bên ngoài phải cho phép ảo hóa bên trong:

Windows: Bật hypervisor trước

Mở PowerShell với quyền administrator và chạy:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

Lệnh cài đặt

Linux (Ubuntu):

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt install docker-sbx
sbx login

macOS:

brew trust docker/tap
brew install docker/tap/sbx
sbx login

Windows:

winget install -h Docker.sbx
sbx login

Chạy sbx login sẽ in thông báo sau trong terminal:

Your one-time device confirmation code is: XXXX-XXXX
Open this URL to sign in: https://login.docker.com/activate?user_code=XXXX-XXXX
By logging in, you agree to our Subscription Service Agreement. For more details, see https://www.docker.com/legal/docker-subscription-service-agreement/
Waiting for authentication...

Mở trình duyệt, dán URL được cấp và hoàn tất quy trình đăng nhập Docker. Nhấn Configure để đăng ký thiết bị.

Đăng nhập tài khoản Docker là bắt buộc, không phải tùy chọn. Mục giải thích vì sao nằm ở phần “Tại sao bạn phải đăng nhập”.

Nếu không dùng được package manager, bạn có thể tải binary thô từ trang sbx-releases trên GitHub. Muốn có bản sửa lỗi mới nhất trước bản stable, bạn có thể cài nightly, ví dụ brew install docker/tap/sbx@nightly.

Kiểm tra phiên bản sandbox và cập nhật

$ sbx version
sbx version: v0.38.0 c022b14634c4bea846ca12870d1d5e97d5868b54

Để nâng cấp:

# Linux (Ubuntu)
sudo apt-get update && sudo apt-get install --only-upgrade docker-sbx
# macOS
brew upgrade docker/tap/sbx
# Windows
winget upgrade Docker.sbx

Khi nâng cấp trên Windows hoặc qua Homebrew, daemon nền (sandboxd) sẽ được khởi động lại tự động, nên bạn không cần tự làm.

Một số mẹo riêng cho Windows

  • Sau winget install, file sbx.exe có thể nằm dưới %LOCALAPPDATA%\DockerSandboxes\bin\, và PATH có thể chưa cập nhật ngay. Nếu không thấy sbx, hãy đăng xuất rồi đăng nhập lại, hoặc mở terminal mới.
  • Nếu vừa bật HypervisorPlatform, hãy khởi động lại máy trước khi chạy sbx create lần đầu. Bỏ qua bước này thường gây treo hoặc lỗi hypervisor khó hiểu.
  • sbx lưu thông tin đăng nhập và chạy daemon trong phiên desktop thường. Vì vậy, thiết lập hoàn toàn qua SSH mà không có desktop tương tác sẽ không hoạt động tốt trên Windows.

Sandbox đầu tiên của bạn, từng bước

Đăng nhập agent của bạn

Nếu dùng Claude Code với gói đăng ký Claude (Max, Team hoặc Enterprise), bạn không cần thiết lập thêm. Lần đầu dùng bên trong sandbox, chạy /login và nó sẽ đăng nhập qua trình duyệt. Docker nói rõ token đăng nhập nằm trên host, không bao giờ được lưu bên trong sandbox.

Nếu muốn dùng API key, hãy lưu bằng sbx secret set. Để agent mở pull request hoặc làm việc với GitHub:

sbx secret set github -t "$(gh auth token)"

Khởi động sandbox đầu tiên

cd ~/my-project
sbx run --name my-sandbox claude

Lần đầu chạy bất kỳ sandbox nào, sbx sẽ hỏi bạn chọn network policy mặc định:

Initialize the global network policy for your sandboxes:
1. Open         — All network traffic allowed, no restrictions.
❯  2. Balanced     — Default deny, with common dev sites allowed.
2. Locked Down  — All network traffic blocked unless you allow it.

Nếu mới bắt đầu, chọn Balanced. Nó cho phép các dịch vụ phát triển phổ biến như npm registry, PyPI và GitHub, còn lại chặn theo mặc định. Bạn có thể đổi sau, nên đừng lo lắng quá nhiều.

Bạn có thể thay claude bằng agent khác. Hiện Docker Sandboxes hỗ trợ Claude Code, Codex, GitHub Copilot CLI, Cursor, Droid, Gemini, Kiro, OpenCode, Docker Agent và chế độ Shell không có agent.

Lần đầu chạy sẽ lâu hơn vì Docker phải tải base image của agent. Sau đó image được dùng lại, nên các lần sau chỉ mất vài giây.

Xem sandbox có thể chạm vào những gì

Mở terminal thứ hai và chạy:

$ sbx ls
SANDBOX       AGENT    STATUS    PORTS   WORKSPACE
my-sandbox    claude   running           ~/my-project

Cột WORKSPACE cho biết thứ duy nhất sandbox và máy của bạn chia sẻ. Agent đổi file ở đó, bạn thấy ngay trong thư mục làm việc và có thể xem lại bằng git diff như xem thay đổi từ đồng nghiệp.

Kiểm tra và điều chỉnh những gì agent truy cập online

sbx policy ls
sbx policy allow network registry.npmjs.org

Nếu bạn chọn Locked Down, ngay cả API của model cũng bị chặn cho đến khi bạn tự cho phép. Đây là lựa chọn tốt cho repository chứa dữ liệu nhạy cảm.

Dọn dẹp khi xong việc

sbx stop my-sandbox     # pause it; everything stays saved
sbx rm my-sandbox        # delete it for good; packages and images go away too

Sandbox vẫn được lưu giữa stop và lần khởi động sau. Package đã cài, image đã kéo và shell history đều tồn tại qua pause. Nhưng rm xóa mọi thứ bên trong sandbox, kể cả git clone trong sandbox nếu bạn dùng clone mode. Thư mục dự án thật trên host không bao giờ bị rm chạm tới.

Các lệnh sbx cốt lõi bạn sẽ dùng hằng ngày

$ sbx run claude                         # start or reconnect to an agent
$ sbx ls                                 # list your sandboxes and their status
$ sbx stop <name>                        # pause a sandbox
$ sbx rm <name>                          # delete a sandbox for good
$ sbx rm --force <name>                  # force-delete, even mid-session
$ sbx exec -it <name> bash               # open a shell inside a running sandbox
$ sbx cp ./file.json <name>:/home/user/  # copy a file from host to sandbox
$ sbx cp <name>:/home/user/out.log ./    # copy a file from sandbox to host
$ sbx ports <name> --publish 8080:3000   # forward a port for a running sandbox
$ sbx daemon restart                     # restart the background daemon
$ sbx                                     # open the interactive dashboard

Mọi lệnh sbx đều nói chuyện với daemon nền tên sandboxd. Nếu sandbox hoạt động bất thường sau khi đổi config như proxy, hãy thử sbx daemon restart trước khi xóa thứ gì.

Lưu ý bảo mật về sbx cp: Sao chép file từ sandbox ra host từng là mục tiêu của một lỗ hổng bảo mật thật, công khai, có tên CVE-2026-17106, biệt danh “CopyEscape”. Chi tiết ở phần lỗ hổng bảo mật bên dưới. Trước khi dựa vào sbx cp để kéo file từ sandbox chưa đáng tin, hãy chắc chắn bạn đang chạy sbx phiên bản 0.38.0 hoặc mới hơn.

Nếu sbx báo “default network policy has not been configured”, hãy tự đặt:

sbx policy set-default <allow-all|balanced|deny-all>

Lưu ý lệnh dùng từ khác menu trước đó: Open → allow-all, Balanced → balanced, Locked Down → deny-all.

Kết nối lại sandbox và đặt tên

Chạy sbx run hai lần trong cùng thư mục sẽ kết nối lại cùng sandbox thay vì tạo mới:

sbx run claude ~/my-project   # creates the sandbox
sbx run claude ~/my-project   # reconnects to it

Nếu đặt tên, bạn có thể kết nối lại từ bất kỳ đâu:

sbx run claude --name my-project
sbx run --name my-project        # reconnect later, from any folder

Bạn cũng có thể chạy nhiều agent trên cùng repo, miễn mỗi agent có tên riêng:

sbx run claude --name feature ~/my-project
sbx run claude --name spike   ~/my-project

Tạo sandbox mà không mở ngay

sbx create --name my-project claude .
sbx run --name my-project        # attach whenever you're ready

Hai cách làm việc với git

  • Direct mode (mặc định): agent có toàn quyền đọc-ghi vào thư mục làm việc thật của bạn. Thay đổi xuất hiện trên host ngay lập tức.
  • Clone mode (--clone): agent làm việc trên git clone riêng bên trong sandbox. Không gì chạm vào thư mục làm việc thật cho đến khi bạn tự fetch hoặc agent push. Repo hiển thị bên trong sandbox nhưng chỉ đọc.
sbx run --clone claude

Clone mode phù hợp khi chạy nhiều agent trên một repo mà không muốn chúng giẫm lên thay đổi của nhau, hoặc khi bạn chưa đủ tin tưởng agent.

Một vài lưu ý về clone mode:

  • Bạn phải đặt khi tạo sandbox, không bật lại sau được. Muốn đổi phải xóa và tạo sandbox mới.
  • Clone theo branch host đang checkout tại thời điểm tạo, không tự tạo branch mới.
  • Chỉ hoạt động với git repository thật. Không hoạt động từ worktree không phải main, vì mount read-only không theo được file .git của worktree.
  • Xóa sandbox clone-mode thì clone trong sandbox cũng mất. Hãy fetch hoặc push thứ quan trọng trước.

Chia sẻ nhiều thư mục

Bạn có thể mount nhiều thư mục từ host vào sandbox, tiện cho thư viện dùng chung hoặc tài liệu tham khảo mà không muốn agent sửa:

sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro

Đường dẫn đầu tiên trở thành workspace chính và là nơi clone mode dùng. Các đường dẫn sau chỉ là mount bổ sung. Thêm :ro để mount read-only.

Mở port từ bên trong sandbox

Sandbox bị cô lập mạng hai chiều. Công cụ trên host không truy cập được dev server trong sandbox trừ khi bạn publish port:

sbx run --publish 8080:3000 --name my-sandbox claude

Với sandbox đang chạy:

sbx ports my-sandbox --publish 8080:3000

Mở http://localhost:8080 trong trình duyệt.

Nếu chỉ publish port phía sandbox, hệ thống tự chọn port host trống. Tra cứu bằng:

sbx ports my-sandbox --publish 3000
sbx ports my-sandbox

Bảng điều khiển tương tác

Gõ sbx không kèm đối số sẽ mở dashboard toàn màn hình trong terminal. Mỗi sandbox hiển thị dạng thẻ trực tiếp với trạng thái, CPU và bộ nhớ. Từ đây bạn có thể tạo sandbox (c), tạm dừng/stop (s), attach (Enter), mở shell (x) hoặc xóa (r).

Có cả network panel, mở bằng tab, để xem kết nối đi ra theo thời gian thực và đổi rule allow/deny ngay. Nhấn ? bất kỳ lúc nào để xem danh sách phím tắt đầy đủ.

Credentials và Secrets

Docker Sandboxes cố giữ raw secret tránh xa sandbox, để agent bị xâm nhập không đánh cắp được. Có hai cách cấp quyền truy cập secret cho agent.

Dịch vụ tích hợp xử lý qua proxy trên host, nên agent không bao giờ đọc secret trực tiếp:

sbx secret set github -t "$(gh auth token)"

Các biến môi trường khác, ví dụ BRAVE_API_KEY hoặc token nội bộ của công ty, không có dịch vụ tích hợp. Bạn phải ghi chúng trực tiếp vào file môi trường persistent của sandbox:

sbx exec -d <sandbox-name> bash -c "echo 'export BRAVE_API_KEY=your_key' >> /etc/sandbox-persistent.sh"

File này tự tải mỗi khi shell khởi động trong sandbox, nên giá trị tồn tại suốt vòng đời sandbox. Chú ý phần bash -c. Mặc định, sbx exec <name> <command> chạy lệnh không qua shell, nên >> redirect và file môi trường sẽ không hoạt động trừ khi bạn bọc lệnh như trên.

Trên Linux headless, khi không có keyring desktop, sbx tự fallback về file mã hóa lưu ở ~/.config/com.docker.sandboxes. Cách này yếu hơn keychain OS thật, nhưng vẫn hoạt động và sbx luôn báo rõ khi dùng fallback.

Tại sao bạn phải đăng nhập

Không giống lệnh docker run đơn giản, bạn không dùng được sbx nếu chưa có tài khoản. Đăng nhập bằng sbx login là bắt buộc. Lý do từ Docker:

  • Mỗi sandbox có danh tính được xác minh, vì agent tự động build container, cài package và push code thay bạn.
  • Tính năng nhóm như governance toàn tổ chức, môi trường dùng chung và audit log đều cần khái niệm “ai” từ đầu.
  • Sandbox cũng cần xác thực với dịch vụ Docker để kéo image và chạy daemon.

Docker cho biết email tài khoản chỉ dùng để đăng nhập, không dùng cho marketing. CLI chỉ thu thập dữ liệu nhỏ: lệnh nào chạy, có thành công không, mất bao lâu, và username nếu đã đăng nhập. Nó không thu thập prompt hay code của bạn. Muốn tắt hoàn toàn:

export SBX_NO_TELEMETRY=1

Cái gì miễn phí và cái gì tốn tiền

  • Miễn phí, kể cả dùng thương mại: bản thân CLI sbx và mọi thứ trong hướng dẫn này.
  • Trả phí qua gói đăng ký riêng: governance tổ chức, gồm policy mạng/filesystem/MCP quản lý tập trung cho cả đội, bắt buộc sign-in và phân phối audit log.

Một developer có thể dùng toàn bộ mô hình cô lập và an toàn miễn phí. Bạn chỉ trả tiền khi muốn enforce policy tập trung trên toàn công ty.

Agents vẫn tốn tiền

Docker Sandboxes cho bạn một hộp miễn phí để chạy agent, nhưng agent là sản phẩm riêng của công ty khác và thường không miễn phí. Claude Code cần gói Claude hoặc API billing qua Anthropic; GitHub Copilot CLI cần gói Copilot; Codex, Gemini, Cursor và các agent khác đều có định giá riêng.

Sandbox không thêm chi phí, cũng không bỏ đi chi phí agent.

Tại sao agents bỏ qua lời nhắc phê duyệt

Chạy agent với flag như --dangerously-skip-permissions trên máy trần thực sự rủi ro. Nhưng bên trong sandbox, bản thân sandbox là ranh giới an toàn. Các lý do thường dùng cho approval prompt — ngăn lệnh phá hoại, chặn truy cập mạng, bắt thay đổi file chưa xem — đã được xử lý bởi ranh giới VM, network policy và cô lập credentials.

Muốn bật lại approval prompt trong một phiên, hầu hết agent cho phép đổi mode giữa phiên. Trong Claude Code, gõ /permissions.

Muốn chế độ thận trọng làm mặc định cho mọi phiên, bạn có thể tạo kit tùy chỉnh loại flag bỏ qua quyền khỏi lệnh khởi động:

# claude-safe/spec.yaml
schemaVersion: "1"
kind: sandbox
name: claude-safe
sandbox:
image: "docker/sandbox-templates:claude-code-docker"
entrypoint:
run: [claude]

sbx run claude-safe --kit ./claude-safe/

Kits và templates vẫn bị gắn nhãn Early Access trong tài liệu Docker, và định dạng đã đổi một lần. Từ v0.38.0, kit mới mặc định dùng schema v2, tổ chức field thành block rõ ràng như permissions.network.allow/deny và setup.install, thay cho kiểu cũ phẳng hơn như network.allowedDomains và commands.install. Kit v1 cũ vẫn load qua legacy path, nhưng loader nghiêm ngặt về việc trộn hai định dạng. Hãy chạy sbx kit validate ./your-kit trước khi ship, và xem kit reference để có danh sách field đầy đủ. Kits phân phối được dưới dạng thư mục, ZIP, OCI artifact hoặc Git URL.

Tính năng thử nghiệm khác đáng biết

Từ v0.38.0, ba tính năng nằm sau feature flag:

  • GPU passthrough (chỉ Linux): sbx run --gpu cho phép sandbox dùng NVIDIA VFIO GPU passthrough. Bật trước bằng sbx settings set feature.sandbox-gpu true.
  • Local models: sbx run --model <name> claude chạy Claude Code với model GGUF cục bộ thay vì hosted API. Thêm prefix ollama/ nếu muốn dùng bản cài Ollama có sẵn.
  • Enterprise networking: bạn có thể đặt upstream proxy riêng cho sandbox và daemon traffic, cùng NTLM/Kerberos proxy login trên Windows.

Nghĩ về local models để cắt chi phí?

Local model bỏ phí subscription và API, nhưng không tự động rẻ hơn. Bạn vẫn cần GPU đủ bộ nhớ để chạy model có khả năng ở tốc độ dùng được. Local open-weight model cũng thường tụt hậu so với hosted model như Claude cho tác vụ coding đa bước, dù khoảng cách đang thu hẹp.

Lưu ý: sbx run --model vẫn chạy bên trong môi trường Claude Code, chỉ đổi model cung cấp sức mạnh. Nó hữu ích cho test cục bộ hoặc giữ code không đi qua API ngoài.

MCP Gateway

Bắt đầu từ v0.38.0, sbx có hỗ trợ riêng để quản lý Model Context Protocol (MCP) servers. Khác với việc cấu hình MCP trong từng agent, bạn đăng ký server một lần trên host rồi dùng lại cho mọi sandbox và mọi agent, không cần đặt credentials bên trong sandbox:

sbx mcp add notion --url https://mcp.notion.com/mcp
sbx mcp add playwright --command npx --args @playwright/mcp@latest
sbx mcp ls
sbx mcp inspect notion

Nếu remote server cần OAuth, sbx mcp add chạy luồng đăng nhập một lần khi đăng ký rồi lưu token trong credential store của host. Gateway đính token vào request đi ra, nhưng token không bao giờ vào VM.

Khi tạo sandbox, bạn chọn một trong hai chế độ:

  • Static mode (--static-mcp server1,server2) tải trước danh sách cố định và giấu công cụ discovery khỏi agent. Đây là lựa chọn chặt chẽ, an toàn hơn.
  • Dynamic mode (mặc định) cho agent tự tìm và kết nối server đã đăng ký giữa phiên, dùng công cụ mcp-find và mcp-add.

Lưu ý quan trọng: MCP server stdio cục bộ chạy trên host, bên ngoài sự bảo vệ của sandbox, với quyền user host. Docker khuyến cáo chỉ đăng ký lệnh và image đã được kiểm chứng theo cách này. Remote HTTP server không gặp vấn đề này vì gateway proxy chúng.

Các lỗ hổng bảo mật đã biết và vì sao bạn nên cập nhật

Hãy đọc kỹ phần này trước khi giao dữ liệu nhạy cảm cho sandbox.

Docker Sandboxes vẫn còn trẻ, và vì nó xử lý code không đáng tin cậy theo thiết kế, nó đã có vài lỗ hổng bảo mật thật được tiết lộ công khai. Hai lỗ hổng là khoảng trống trong cô lập mạng. Gần đây nhất là lỗ hổng thoát ra filesystem host qua tính năng filecopy. Điểm mấu chốt: network allowlist không phải ranh giới hoàn hảo. Nó chỉ tốt bằng bản phát hành hiện tại, và mỗi bản phát hành phải đóng từng kênh phụ như DNS hay ICMP. Đường filecopy giữa host và sandbox cũng là mục tiêu thật.

Nếu chạy sandbox chứa credentials hoặc dữ liệu nhạy cảm, hãy coi số phiên bản như câu hỏi an toàn chủ động:

sbx version

So sánh phiên bản của bạn với release notes hoặc trang sbx-releases, rồi nâng cấp bằng các lệnh ở phần cài đặt nếu đang tụt hậu.

Tại thời điểm viết, phiên bản 0.38.0 hoặc mới hơn gồm bản sửa cho cả ba lỗ hổng nói trên. Vì CVE-2026-17106 rất mới, hãy cẩn trọng với chiều copy-out của sbx cp cho đến khi xác nhận bạn đang ở 0.38.0 hoặc mới hơn. Khi có thể, hãy ưu tiên xem xét thay đổi qua git diff trong workspace read-only dùng chung thay vì tùy tiện copy file ra khỏi sandbox chưa đáng tin.

Điều này không có nghĩa là thiết kế tổng thể tệ. Cô lập cấp VM cho file và process là cách tiếp cận vững chắc, và Docker đã vá nhanh. Cả hai lỗ hổng tháng 6 năm 2026 được vá trong khoảng hai tuần sau khi báo cáo, còn bản sửa CopyEscape ra cùng bản phát hành nơi lỗ hổng bị tiết lộ.

Đừng cài một lần rồi quên. Kiểm tra phiên bản thường xuyên, nhất là trước khi dùng sbx cp kéo file từ sandbox không hoàn toàn đáng tin, hoặc trước khi coi network allowlist là tường chắn hoàn hảo.

Một vài mẹo thực tế đáng biết

  • sbx run bỏ qua --publish khi kết nối lại. Nếu đang attach vào sandbox đã tồn tại và cần port mới, dùng sbx ports <name> --publish .... Flag --publish trên run chỉ có tác dụng khi tạo sandbox lần đầu.
  • Sandbox không sao chép toàn bộ cài đặt agent từ tài khoản của bạn. Hooks và settings trong các thư mục như ~/.claude nằm trên host. Chỉ config cấp project trong thư mục làm việc được chia sẻ. Ngoại lệ là shared agent skills, bật bằng sbx skills import. Đừng dựa vào symlink trỏ tới đường dẫn host; agent trong sandbox không đi theo link ra ngoài VM của nó.
  • Dán ảnh clipboard bị tắt mặc định, vì bật nó cho phép process trong sandbox đọc clipboard host qua proxy. Muốn dùng, bật bằng sbx settings set clipboard.imagePaste true.
  • Không chắc mình đang bị sandbox? Trong Claude Code, thử /btw are you running in a sandbox?. Đó là kiểm tra nhanh trước khi dán thứ nhạy cảm.
  • Nếu công ty bạn chặn outbound traffic bằng firewall, bạn cần cho phép các domain hạ tầng của Docker để sbx hoạt động: login.docker.com, hub.docker.com, api.docker.com, registry-1.docker.io, auth.docker.io, cùng vài endpoint telemetry/diagnostics. Việc này tách biệt với policy mạng bên trong sandbox.

Tài nguyên và đọc thêm

Cheat sheet token lệnh nhanh

By logging in, you agree to our Subscription Service Agreement. For more details, see https://www.docker.com/legal/docker-subscription-service-agreement/ sbx exec -d <sandbox-name> bash -c "echo 'export BRAVE_API_KEY=your_key' >> /etc/sandbox-persistent.sh" $ sbx exec -it <name> bash               # open a shell inside a running sandbox Open this URL to sign in: https://login.docker.com/activate?user_code=XXXX-XXXX $ sbx ls                                 # list your sandboxes and their status $ sbx ports <name> --publish 8080:3000   # forward a port for a running sandbox sbx rm my-sandbox        # delete it for good; packages and images go away too $ sbx cp ./file.json <name>:/home/user/  # copy a file from host to sandbox $ sbx cp <name>:/home/user/out.log ./    # copy a file from sandbox to host Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All $ sbx                                     # open the interactive dashboard $ sbx run claude                         # start or reconnect to an agent $ sbx rm --force <name>                  # force-delete, even mid-session $ sbx daemon restart                     # restart the background daemon sudo apt-get update && sudo apt-get install --only-upgrade docker-sbx $ sbx rm <name>                          # delete a sandbox for good sbx run --name my-project        # reconnect later, from any folder 2. Locked Down  — All network traffic blocked unless you allow it. sbx mcp add playwright --command npx --args @playwright/mcp@latest ❯  2. Balanced     — Default deny, with common dev sites allowed. 1. Open         — All network traffic allowed, no restrictions. sbx run --name my-project        # attach whenever you're ready sbx version: v0.38.0 c022b14634c4bea846ca12870d1d5e97d5868b54 sbx stop my-sandbox     # pause it; everything stays saved $ sbx stop <name>                        # pause a sandbox Initialize the global network policy for your sandboxes: curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh my-sandbox    claude   running           ~/my-project sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro Your one-time device confirmation code is: XXXX-XXXX sbx policy set-default <allow-all|balanced|deny-all> sbx run --publish 8080:3000 --name my-sandbox claude image: "docker/sandbox-templates:claude-code-docker" sbx run claude ~/my-project   # creates the sandbox sbx mcp add notion --url https://mcp.notion.com/mcp SANDBOX       AGENT    STATUS    PORTS   WORKSPACE sbx run claude ~/my-project   # reconnects to it sbx secret set github -t "$(gh auth token)" sbx policy allow network registry.npmjs.org sbx run claude --name feature ~/my-project sbx run claude --name spike   ~/my-project sbx settings set clipboard.imagePaste true kvm                  1527808  1 kvm_intel sbx settings set feature.sandbox-gpu true sbx ports my-sandbox --publish 8080:3000 sbx run claude-safe --kit ./claude-safe/ sbx create --name my-project claude . irqbypass              16384  1 kvm sbx ports my-sandbox --publish 3000 brew install docker/tap/sbx@nightly %LOCALAPPDATA%\DockerSandboxes\bin\ /btw are you running in a sandbox? sbx run --name my-sandbox claude sbx run claude --name my-project kvm_intel             552960  0 --dangerously-skip-permissions ~/.config/com.docker.sandboxes permissions.network.allow/deny sbx ports <name> --publish ... Waiting for authentication... sbx run --model <name> claude winget install -h Docker.sbx --static-mcp server1,server2 sudo apt install docker-sbx brew install docker/tap/sbx brew upgrade docker/tap/sbx sbx kit validate ./your-kit sudo usermod -aG kvm $USER winget upgrade Docker.sbx export SBX_NO_TELEMETRY=1 sbx exec <name> <command> # claude-safe/spec.yaml sbx run --clone claude sbx mcp inspect notion network.allowedDomains brew trust docker/tap http://localhost:8080 sbx ports my-sandbox Hypervisor.framework registry-1.docker.io schemaVersion: "1" HypervisorPlatform sbx daemon restart name: claude-safe sbx skills import lsmod | grep kvm # Linux (Ubuntu) commands.install login.docker.com cd ~/my-project sbx run --model docker compose winget install sbx secret set hub.docker.com api.docker.com auth.docker.io CVE-2026-17106 $ sbx version sbx policy ls kind: sandbox run: [claude] BRAVE_API_KEY setup.install sbx run --gpu docker build sbx-releases /permissions entrypoint: sbx version Locked Down sbx mcp add sbx mcp ls docker run newgrp kvm sbx create sbx login # Windows kvm_intel WORKSPACE allow-all --publish ~/.claude $ sbx ls sandbox: sandboxd git diff balanced deny-all mcp-find # macOS kvm_amd sbx.exe sbx run --clone bash -c ollama/ mcp-add v0.38.0 rm -rf kvm-ok /login claude sbx cp 0.38.0 PATH stop .git sbx kvm :ro tab run rm >> -t -c 14 c s x r ?