Bật sandbox cho coding agent mà không phá vỡ workflow

Bạn bật sandbox cho coding agent lúc 9 giờ sáng. Đến 10 giờ, npm install không ra được registry, dev server không mở nổi port, và bạn tắt sandbox cho xong việc.

Có cách lấy allowlist chính xác hơn là ngồi đoán: đọc chính lịch sử lệnh agent đã chạy trên máy bạn.

Vì sao sandbox deny-by-default hay bị tắt sau một giờ

Theo bài phân tích của Hardik Verma trên Dev.to, mọi coding agent lớn hiện đều có sandbox: "Claude Code has /sandbox, Codex has workspace-write, and there's Anthropic's open-source sandbox-runtime, nono and others." Tất cả cùng mô hình — chặn hết, rồi mở theo danh sách bạn khai.

Vấn đề là danh sách đó phải khai trước khi bạn biết mình cần gì. Tác giả liệt kê đúng thứ vỡ đầu tiên: "npm install can't reach the registry. The dev server can't open a port. pip can't write its cache. git push can't read your SSH key."

Sau vài lần, bạn chọn một trong hai: tắt sandbox, hoặc thêm rule rộng kiểu allow all of ~ — rule thứ hai vô hiệu hoá đúng cái sandbox vừa bật.

Transcript chính là allowlist có sẵn

Dữ liệu bạn cần đã nằm trên disk. Theo bài viết: "Claude Code saves a transcript of every session in ~/.claude/projects, and Codex does the same in ~/.codex/sessions. Every command your agent ran is in there. That history is the allowlist."

Nhưng transcript thô là chưa đủ. Nó ghi npm install, không ghi việc npm đã gọi registry.npmjs.org và ghi vào ~/.npm. Muốn dịch command thành permission, bạn cần parse shell thật — pipe, cd, redirect, heredoc, và wrapper như sudo, npx, python -m.

Nguyên tắc khi generalize: mở quyền ghi tới thư mục cache, không bao giờ tới cả home. Tool cần credential (gh, docker, git push qua SSH) nên chạy ngoài sandbox, thay vì đục lỗ trong sandbox.

Hai nhóm quyền phải chặn, dù history có nói gì

Đây là phần dễ bỏ sót nhất. Tháng 7/2026, theo bài viết, Pillar Security thoát sandbox của Cursor, Codex, Gemini CLI và Antigravity mà không cần phá sandbox: "The agent wrote files that a trusted tool outside the sandbox later acted on: hook configs, IDE task files, git metadata."

Tác giả tóm gọn: quyền nguy hiểm không phải "write anywhere", mà là "write to a file something else will execute later".

Policy nên luôn chặn ghi vào: git hooks và .git/config; file khởi động shell (~/.zshrc, ~/.bashrc); .mcp.json và task config của editor (.vscode); và chính settings của agent — để agent không tự nới sandbox của nó.

Và luôn chặn đọc credential: ~/.ssh, ~/.aws, ~/.npmrc, file .env. Rủi ro này không lý thuyết — bài viết dẫn vụ prompt injection vào GitHub triage bot của Cline năm 2026, kết thúc bằng npm publish credential bị đánh cắp và một release trái phép.

Đo trước khi bật

Tác giả có viết một tool (sandfit) để replay history và ước lượng tỉ lệ lệnh sẽ vỡ. Các con số trong bài — 28% lệnh vỡ nếu bật sandbox ngay, 0% với policy do tool sinh ra — là số liệu tác giả công bố trên dataset mẫu đi kèm repo, không phải đo độc lập. Ý tưởng đáng mượn: đo policy làm vỡ bao nhiêu lệnh trước khi apply.

Một chi tiết nên biết nếu bạn đang pin version

Changelog Claude Code 2.1.316 có một fix đúng chủ đề này: "--restricted sessions no longer upload files from outside the working directories when a Read allow rule covered them." Một allow rule cho quyền đọc từng lan sang được quyền upload. Nếu team bạn dựa vào --restricted như lớp cô lập, hãy update trước khi tin vào nó.

Làm gì tiếp

• Kiểm tra agent của bạn thật sự có đang chạy trong sandbox không — phần lớn team tưởng là có.
• Thêm deny-list cho hook/startup/credential trước: phần này không phụ thuộc history của ai cả.
• Sau đó mới dựng allowlist từ transcript, và test trên lệnh mới chứ không chỉ lệnh cũ.