Cấu hình rào chắn

Hướng dẫn này chỉ cho bạn cách cấu hình rào chắn: những quy tắc quyết định một hành động của agent được chạy, hỏi phê duyệt trước, hay bị từ chối.

Rào chắn bao phủ mười ba lớp hiệu ứng mà mọi công cụ có thể thay đổi trạng thái đều khai báo. Chúng được thực thi phía máy chủ ngay tại thời điểm công cụ được gọi, chứ không bao giờ bằng một chỉ dẫn trong prompt.

Đặt quyết định cho một lớp hành động

Vào Cài đặt → Không gian làm việc → Quyền của agent
Chọn một phạm vi bằng điều khiển phân đoạn: Không gian làm việc, Agent (rồi chọn agent), hoặc Space (rồi chọn space)
Trên hàng của lớp hành động, chọn Cho phép, Hỏi trước hoặc Từ chối
Để bỏ một quy tắc bạn đã đặt, nhấn nút đặt lại xuất hiện ở cuối hàng đó (Xóa về kế thừa) — quyết định sẽ quay về phạm vi rộng hơn

Mỗi hàng hiển thị quyết định hiệu lực dưới dạng thẻ trạng thái và một huy hiệu cho biết nó đến từ đâu: Phạm vi này, Kế thừa hoặc Mặc định tích hợp. Ma trận này được giải quyết ở chế độ Agent (chat), nên Preset chế độ không bao giờ xuất hiện ở đây — hãy dùng công cụ thăm dò Nếu như với một chế độ chỉ đọc được chọn để thấy lớp đó.

Việc viết một quy tắc cần vai trò admin. Việc đọc ma trận thì không.

Điểm kiểm tra: đặt Push lên remote thành Từ chối ở phạm vi không gian làm việc, rồi chạy công cụ thăm dò Nếu như bên dưới trên git push origin main. Kết quả đọc là deny với nguồn workspace.

Hiểu cách một quyết định được giải quyết

Việc giải quyết tuân theo mức cụ thể trước, rồi đến mức hạn chế:

Quy tắc Space, rồi agent, rồi không gian làm việc. Phạm vi đầu tiên có quy tắc khớp sẽ quyết định và việc giải quyết dừng lại
Nếu không quy tắc nào khớp, preset chế độ được áp dụng — một chế độ chỉ đọc (plan, review, orchestrate) từ chối mười một trong mười ba lớp
Nếu chế độ không có gì để nói, mặc định tích hợp được áp dụng

Trong cùng một phạm vi, một quy tắc lệnh được giải quyết theo tiền tố khớp dài nhất và một xung đột có cùng mức cụ thể được giải quyết theo hướng hạn chế nhất — từ chối thắng hỏi trước thắng cho phép. Một hành động khai báo nhiều lớp sẽ giải quyết từng lớp độc lập rồi kết hợp chúng theo hướng hạn chế nhất.

Một quyết định Hỏi trước đưa ra một yêu cầu phê duyệt duy nhất bao trùm mọi lớp đã được giải quyết thành prompt. Khi không có người phê duyệt nào được kết nối thì nó bị từ chối, với cả lệnh shell lẫn các lệnh gọi công cụ của harness. Điều này là có chủ đích: một lượt chạy không qua cổng còn tệ hơn một lượt chạy bị từ chối.

Các lớp hành động và mặc định tích hợp

Lớp hành động	Mặc định tích hợp
Xóa một tệp	Hỏi trước
Ghi bên ngoài cây làm việc	Cho phép
Tạo một commit	Cho phép
Push lên remote	Hỏi trước
Mở một pull request	Hỏi trước
Xuất bản review hoặc merge	Hỏi trước
Ghi vào tracker bên ngoài	Hỏi trước
Truy cập mạng	Cho phép
Đọc một secret	Cho phép
Cài một gói	Cho phép
Chạy một tiến trình	Cho phép
Thay đổi cấu trúc không gian làm việc	Cho phép
Điều khiển một enclosure (rig)	Cho phép

Danh mục này là đóng. Một công cụ mới được phát hành mà không khai báo các lớp của nó sẽ trượt một bài kiểm thử ratchet trong CI, nên không thứ gì xuất hiện với một tập hiệu ứng rỗng một cách âm thầm.

Kiểm thử một quy tắc bằng công cụ thăm dò Nếu như

Trước khi thay đổi một quy tắc, hãy kiểm tra xem chính sách hiện tại đã giải quyết nó thế nào.

Trên cùng trang đó, cuộn tới Nếu như?
Chọn một Hành động (một trong mười ba lớp)
Tùy chọn điền Lệnh (ví dụ git push origin main), Agent, Space và Chế độ
Đọc kết quả: quyết định, lý do và Nguồn:

Công cụ thăm dò chạy đúng bộ giải quyết mà đường thực thi dùng, dựa trên các quy tắc đang hoạt động của bạn, nên câu trả lời là chính xác. Nếu nó khiến bạn bất ngờ, hãy sửa một quy tắc trong ma trận bên trên rồi thăm dò lại.

Đặt nút tự chủ của một space

Nút này là theo từng agent trên từng space và nó kết hợp với các quy tắc thay vì thay thế chúng.

Mở space
Mở Quản lý người tham gia từ tiêu đề của space
Dưới Tự chủ trên hàng của agent, chọn một mức:

Mức	Tác dụng
Mặc định	Không có cài đặt space — hoạt động như Hành động khi được duyệt
Chỉ đề xuất	Mọi công cụ có cổng đều bị từ chối dứt khoát, kèm thông báo bảo agent hãy đề xuất hành động thay vì thực hiện
Hành động khi được duyệt	Các hành động rủi ro chạm cổng phê duyệt đóng khi lỗi
Hành động tự do	Phê duyệt trước mọi thứ không bị giải quyết thành từ chối cứng

Nút này chỉ vươn tới harness tích hợp. Adapter Claude Code chạy các công cụ riêng của nó bên ngoài cổng này.

Biết nơi rào chắn không vươn tới

Bảng Nơi quy tắc được thực thi ở cuối cùng trang đó là phiên bản trong ứng dụng của điều này: theo từng lớp hiệu ứng, nó cho biết mỗi trình chạy có bắt được nó tại cổng chính sách không, để nó cho sandbox, hay hoàn toàn không thể chặn nó.

Adapter Claude Code chỉ được đặt cổng một phần cho các lệnh gọi công cụ của chính nó. Claude Code được khởi chạy với --dangerously-skip-permissions, nên các lệnh gọi read, write và edit của nó không bao giờ đi qua cổng gác. Các lệnh bash của nó tới được cổng gác qua một hook phân loại dòng lệnh, và các lần push của nó đi qua cổng push như của mọi agent. Bề mặt công cụ MCP mà nó gọi ngược vào và lệnh shell mà Control Center khởi tạo để chạy nó cũng được đặt cổng.
Động từ đầu ra của chính một chế độ (submit_plan, propose_orchestration) được ghim và không bao giờ có thể bị từ chối — nếu không thì một chế độ sẽ không thể nào tạo ra sản phẩm bàn giao duy nhất của nó.
Việc sandbox có củng cố các quy tắc này hay không phụ thuộc vào máy chạy. Ở nơi cc_server tìm thấy một backend, nó bọc CLI Claude Code và công cụ bash của harness, nên một quy tắc bạn không viết vẫn có sàn của hệ điều hành bên dưới nó. Trên Windows thì không có sàn nào và trên Linux hay WSL2 không có bwrap và socat thì cũng không — ở đó, rào chắn cộng với bề mặt công cụ của chế độ là toàn bộ việc thực thi, chứ không phải lớp thứ hai của nó. Hãy kiểm tra xem bạn đang ở trường hợp nào bằng Cấu hình chính sách sandbox.