Chế Độ Sandbox & Phê Duyệt Của Codex: Hướng Dẫn Đầy Đủ (2026)
Codex tách an toàn thành hai lớp độc lập: sandbox mode (agent được LÀM gì) và approval policy (khi nào nó phải HỎI trước khi làm). Mặc định của Codex là workspace-write + on-request. Đừng bao giờ ghép danger-full-access với never (hay --yolo) ngoài một môi trường dùng-rồi-bỏ. Bài này có bảng ba chế độ sandbox, ba approval policy, cách bật qua CLI/config.toml, lớp Permission Profiles mới hơn, và một bảng quyết định để chọn đúng cặp trong dưới một phút.
- Cơ chế sandbox/approval của Codex (và lớp Permission Profiles mới) đổi khá nhanh, tài liệu chính thức hiện tách trên nhiều đường dẫn khác nhau tại learn.chatgpt.com; các chi tiết dưới đây đã đối chiếu tài liệu chính thức tại thời điểm viết (08/2026) - kiểm tra docs live trước khi phụ thuộc.
Sandbox mode vs. approval policy - hai câu hỏi khác nhau
Codex hỏi mình hai câu hoàn toàn tách biệt trước khi làm bất cứ việc gì: "Nó được PHÉP làm gì?" (sandbox mode) và "Nó phải HỎI mình khi nào?" (approval policy). Theo tài liệu chính thức learn.chatgpt.com/codex/sandboxing, hai lớp này vận hành độc lập với nhau - đặt sandbox rộng không có nghĩa Codex ngừng hỏi bạn, và đặt approval chặt không có nghĩa Codex tự động bị giới hạn về việc nó có thể chạm vào đâu.
Mới làm quen Codex? Xem Codex là gì trước khi đọc tiếp phần cấu hình này. Và một dòng để tránh nhầm: đây là hệ thống phân quyền riêng của Codex - không liên quan gì tới việc cài AgentKit lên trên nó.
Ba chế độ sandbox
Sandbox quyết định Codex được đụng vào đâu trên máy bạn khi KHÔNG chờ bạn xác nhận. Theo tài liệu sandboxing chính thức (truy cập 08/2026), có ba mức:
| Sandbox mode | Codex được làm gì | Mức rủi ro |
|---|---|---|
read-only | Chỉ đọc file, không được ghi/sửa gì trên máy, không chạy lệnh có tác dụng phụ. | Thấp |
workspace-write (mặc định) | Đọc/ghi trong thư mục workspace hiện tại (và vài thư mục tạm hệ thống); ra ngoài phạm vi đó vẫn cần xin quyền riêng. | Trung bình |
danger-full-access | Không còn ranh giới filesystem - đọc/ghi bất cứ đâu tiến trình Codex có quyền hệ điều hành cho phép. | Cao |
workspace-write là mặc định Codex tự chọn khi bạn không chỉ định gì - đây cũng là mức mình dùng cho phần lớn công việc code hàng ngày, vì nó đủ rộng để làm việc thật mà không mở toang cả máy.
Ví dụ nhanh: mở Codex trong repo đang code, không đổi gì, mặc định nó nhận workspace-write - tự do sửa file trong repo. Nhưng nếu nó cố ghi ra ngoài phạm vi đó (ví dụ đụng vào ~/.ssh/ hay một thư mục hệ thống khác), đó là hành động ngoài sandbox - sẽ bị chặn thẳng hoặc kích hoạt bước hỏi riêng, tùy approval policy đang đặt cùng lúc.
Ba approval policy
Approval policy quyết định Codex phải DỪNG lại hỏi bạn khi nào, tách biệt hoàn toàn với việc nó được phép làm gì. Theo tài liệu approvals & security (truy cập 08/2026), có ba mức:
| Approval policy | Khi nào Codex hỏi |
|---|---|
untrusted | Hỏi trước hầu hết lệnh, kể cả lệnh có vẻ vô hại - mức thận trọng nhất. |
on-request (mặc định cho thư mục có version control) | Codex tự quyết định lệnh nào an toàn để chạy thẳng, chỉ hỏi khi nó đánh giá lệnh có rủi ro hoặc ra ngoài sandbox hiện tại. |
never | Không hỏi gì cả - chạy thẳng theo sandbox mode đang đặt, kể cả lệnh rủi ro. |
Điểm hay bị bỏ sót: tài liệu chính thức ghi on-request là mặc định "cho các thư mục đã có version control" - không phải mặc định vô điều kiện cho mọi thư mục. Gần như toàn bộ bài hướng dẫn khác mình xem qua (kể cả bản tiếng Việt) bỏ qua điều kiện này. Nếu bạn chạy Codex ngoài một thư mục có git, đừng mặc định là on-request đang bật - kiểm tra lại config thật.
Cách chuyển chế độ - /permissions, CLI flags, config.toml
Ba cách phổ biến để đặt sandbox mode + approval policy:
- Trong phiên (CLI): gõ
/permissionsđể mở picker, chọn trực tiếp. - IDE/desktop: có control chọn permission ngay trong composer.
- Cờ dòng lệnh khi khởi động:
--sandboxvà--ask-for-approval. - Cấu hình cố định: khóa
sandbox_modevàapproval_policytrong~/.codex/config.toml.
Ví dụ thực tế cho pipeline CI (không có người ngồi trả lời prompt):
codex --sandbox read-only --ask-for-approval neverCặp này an toàn cho non-interactive vì Codex không bao giờ dừng lại chờ input (never), trong khi read-only giữ nó không thể ghi đè gì ngoài ý muốn. Cấu hình này gắn liền với cách bạn set up AGENTS.md cho Codex - xem thêm hướng dẫn AGENTS.md cho Codex để ghép cả hai vào cùng quy trình.
Permission Profiles - lớp cấu hình mới hơn
Ngoài cặp sandbox_mode/approval_policy cổ điển ở trên, Codex còn có một lớp cấu hình mới hơn: Permission Profiles, xác nhận qua fetch trực tiếp learn.chatgpt.com/docs/permissions (truy cập 08/2026). Cơ chế:
- Khóa
default_permissionstrỏ tới một profile có sẵn hoặc tự định nghĩa. - Ba profile dựng sẵn:
:read-only,:workspace,:danger-full-access- gần tương ứng ba sandbox mode ở trên nhưng đặt tên khác. - Có thể tự viết profile riêng bằng bảng
[permissions.<tên>], khai path nào được đọc, được ghi, và path nào bị deny tường minh. - Quyền mạng tách riêng:
network.enabled(bật/tắt mạng) khác vớifeatures.network_proxy(chạy qua proxy có kiểm soát).
Thành thật: đây gần như không ai nhắc tới trong cả SERP tiếng Anh lẫn tiếng Việt mình xem qua khi viết bài này - chỉ một bài duy nhất đề cập, và đề cập riêng lẻ, không đặt cạnh cặp sandbox_mode/approval_policy để so sánh. Và một điều tài liệu chính thức không nói rõ: thứ tự ưu tiên nếu bạn khai cả default_permissions lẫn sandbox_mode/approval_policy cùng lúc. Một vài nguồn không chính thức đoán rằng sandbox_mode sẽ ghi đè, nhưng mình không tìm thấy trang tài liệu chính thức nào xác nhận trực tiếp điều đó - nên đừng coi đó là sự thật. Cách an toàn thực tế: chọn một hệ thống, dùng nhất quán - hoặc toàn bộ legacy (sandbox_mode/approval_policy) hoặc toàn bộ Permission Profiles, đừng trộn.
Ví dụ khái niệm để hình dung giá trị thật của lớp này (không phải cú pháp chính thức đã xác nhận từng field): bạn muốn một profile cho phép đọc toàn bộ repo, nhưng chỉ được ghi vào thư mục logs/, đồng thời deny tường minh vài path nhạy cảm như file .env hay .ssh/ dù chúng nằm trong phạm vi đọc rộng hơn. Đây là mức kiểm soát theo từng path mà cặp sandbox_mode/approval_policy cổ điển (vốn chỉ có ba mức rộng) không làm được. Cú pháp field chính xác nên xác nhận lại trong docs live trước khi áp dụng, vì đây là phần tài liệu vừa được thêm gần đây.
Bảng quyết định - chọn chế độ nào cho việc gì
Đây là bảng mình tự dùng để quyết định trong dưới một phút, thay vì nghĩ lại từ đầu mỗi lần mở Codex:
| Tình huống | sandbox_mode | approval_policy | Vì sao |
|---|---|---|---|
| Chỉ đọc code, lên plan | read-only | on-request | Không có gì để ghi, an toàn tuyệt đối kể cả khi Codex đánh giá sai rủi ro. |
| Code hàng ngày trong repo local (mặc định của Codex) | workspace-write | on-request | Đủ quyền làm việc thật, Codex vẫn hỏi khi thấy lệnh rủi ro hoặc vượt sandbox. |
| Task lặp lại, tin tưởng cao, vẫn local | workspace-write | untrusted | Ngược trực giác một chút: dùng untrusted (hỏi nhiều hơn) cho task lặp để bạn confirm nhanh từng bước, thay vì never bỏ qua hoàn toàn. |
| CI/CD, không có người trả lời prompt | read-only (hoặc workspace-write đã scope hẹp) | never | Không ai ngồi đó để bấm approve - buộc phải never; bù lại bằng sandbox hẹp nhất có thể. |
| Cần quyền full-system thật sự | danger-full-access | on-request | Vẫn giữ một lớp hỏi lại trước khi Codex chạm việc nguy hiểm ngoài workspace. |
| Chỉ trong sandbox dùng-rồi-bỏ (container/VM tạm) | danger-full-access | never/--yolo | Cặp rủi ro nhất chỉ chấp nhận được khi cả máy là đồ bỏ đi sau phiên làm việc. |
Quy tắc một dòng để nhớ: không bao giờ ghép danger-full-access với never/--yolo ngoài một môi trường dùng-rồi-bỏ. Đó là cặp duy nhất trong bảng trên đánh đổi cả hai lớp an toàn cùng lúc.
Bài học an toàn production - một "cái tát" có thật
Bảng ở trên nghe hợp lý trên giấy, nhưng lý do nó tồn tại không phải lý thuyết. Bài cách dùng /goal hiệu quả trên site này đã kể lại "Cái tát #1": goal được ghi rất rõ - chỉ deploy staging - nhưng sau vài lần auto-compact, agent trôi khỏi ngữ cảnh, quên mất ranh giới, và deploy thẳng lên production, dù đã có một hook nhắc lại task sau mỗi lần compact.
Đây chính xác là lỗi mà bảng quyết định ở trên ngăn được: ranh giới an toàn phải nằm ở sandbox_mode/approval_policy thật (một giới hạn kỹ thuật Codex buộc phải tuân theo), không nằm ở một dòng nhắc trong prompt hay goal (thứ agent có thể quên sau vài lần nén ngữ cảnh). Nếu môi trường production của bạn nằm trong phạm vi Codex có thể chạm tới, đừng đặt approval_policy = never cho phạm vi đó - dù bạn có "chắc chắn" đã dặn nó rồi.
Nói cách khác: bảng quyết định ở phần trước không phải một bài tập lý thuyết để dán lên tường. Nó là câu trả lời kỹ thuật cho đúng câu hỏi mà "Cái tát #1" đặt ra - làm sao ngăn một agent kiên trì, đã trôi ngữ cảnh, chạm vào thứ nó không nên chạm. Prompt nhắc thì có thể quên; giới hạn ở sandbox_mode/approval_policy thì không.
AgentKit chạy bên trong bất kỳ chế độ nào bạn chọn
Nói thẳng ranh giới: AgentKit không đụng vào, không bypass sandbox hay approval policy của Codex. Kit chỉ là một lớp skill/workflow chạy bên trong bất kỳ chế độ nào đang active - nếu bạn đặt read-only + untrusted, AgentKit cũng bị giới hạn y hệt Codex thuần, không có đặc quyền riêng. Cài cho Codex: ak kit init engineer --target codex, rồi gọi $ak:cook trong phiên Codex mới - xem chi tiết ở cách dùng AgentKit với Codex.
Muốn bộ workflow/skill dựng sẵn chạy an toàn trong sandbox bạn tự chọn? AgentKit Engineer Kit thêm ak:cook, ak:code-review, ak:ship cho Codex - không đổi gì về quyền hạn Codex đang có, bạn vẫn kiểm soát sandbox/approval như thường.
Câu hỏi thường gặp (FAQ)
Chế độ sandbox mặc định của Codex là gì?
workspace-write - Codex được đọc/ghi trong thư mục workspace hiện tại, không tự do truy cập toàn hệ thống. Đi kèm approval mặc định là on-request cho thư mục có version control.
on-request có luôn hỏi trước mọi lệnh không?
Không. on-request để Codex tự quyết định lệnh nào an toàn để chạy thẳng, chỉ hỏi khi nó đánh giá lệnh rủi ro hoặc vượt phạm vi sandbox hiện tại - khác với untrusted vốn hỏi trước hầu hết lệnh.
Khác gì giữa danger-full-access và --yolo?
danger-full-access là một giá trị của sandbox_mode (bỏ ranh giới filesystem). --yolo (cờ bypass cả sandbox lẫn approval cùng lúc) đi xa hơn - nó gộp sandbox rộng nhất với approval never vào một lệnh, nên rủi ro cao hơn hẳn một mình danger-full-access. Xác nhận lại tên cờ chính xác trên máy bạn trước khi dùng, vì đây là bề mặt hay đổi.
Có dùng Permission Profiles và sandbox_mode cùng lúc được không?
Về mặt kỹ thuật có thể khai cả hai, nhưng tài liệu chính thức không nói rõ thứ tự ưu tiên khi chúng xung đột. Đừng coi bất kỳ đồn đoán nào về thứ tự ưu tiên là sự thật - cách an toàn là chọn một hệ thống (legacy hoặc Permission Profiles) và dùng nhất quán.
Nên dùng chế độ nào cho CI/CD?
read-only (hoặc workspace-write đã scope hẹp) kèm approval never - vì không có người ngồi trả lời prompt trong pipeline nên buộc phải never, bù lại bằng sandbox hẹp nhất có thể.
/permissions có đổi vĩnh viễn config.toml không?
Đây là chi tiết cần kiểm tra live trước khi phụ thuộc - hành vi có thể khác nhau giữa đổi tạm cho phiên hiện tại và ghi lại vào config.toml. Cách chắc chắn nhất là mở lại config.toml sau khi đổi qua picker để tự xác nhận nó có được lưu hay không.
Kết luận
An toàn của Codex gói gọn trong hai lớp độc lập: sandbox mode (được làm gì) và approval policy (khi nào phải hỏi). Mặc định workspace-write + on-request hợp cho phần lớn việc code hàng ngày; đừng bao giờ ghép danger-full-access với never/--yolo ngoài môi trường dùng-rồi-bỏ. Dùng bảng quyết định ở trên thay vì đoán, và nhớ bài học từ Cái tát #1: ranh giới an toàn phải nằm ở cấu hình, không nằm ở lời dặn trong prompt.