Phê duyệt tác nhân và bảo mật

Codex giúp bảo vệ mã nguồn và dữ liệu của bạn, đồng thời giảm nguy cơ bị sử dụng sai mục đích.

Theo mặc định, tác nhân chạy khi quyền truy cập mạng bị tắt. Khi chạy cục bộ, Codex sử dụng một môi trường cô lập do hệ điều hành thực thi để giới hạn những gì tác nhân có thể truy cập (thường chỉ trong không gian làm việc hiện tại), cùng với một chính sách phê duyệt kiểm soát thời điểm tác nhân phải dừng lại và hỏi bạn trước khi hành động.

Để tìm hiểu tổng quan về cách môi trường cô lập hoạt động trên ứng dụng ChatGPT dành cho máy tính, Codex CLI và tiện ích mở rộng IDE, hãy xem môi trường cô lập. Để xem thông tin tổng quan rộng hơn về bảo mật dành cho doanh nghiệp, hãy đọc sách trắng về bảo mật Codex.

Chuyển đổi từ chính sách phê duyệt untrusted đã ngừng hỗ trợ

Codex và ChatGPT Work không còn hỗ trợ approval_policy = "untrusted". Cài đặt đã ngừng hỗ trợ này có thể khiến cả hai ứng dụng không khởi động được. Hãy xóa cài đặt này khỏi cấu hình người dùng hoặc dự án, các tệp hồ sơ, tập lệnh khởi động và các giá trị mặc định được quản lý. Để sử dụng tương tác ở chế độ chỉ đọc:

sandbox_mode = "read-only"
approval_policy = "on-request"

Hoặc chạy codex --sandbox read-only --ask-for-approval on-request.

Với on-request, các lệnh được môi trường cô lập cho phép có thể chạy mà không cần phê duyệt, đọc các tệp có thể truy cập và sử dụng quyền truy cập mạng nếu được bật.

Để giữ quy tắc phê duyệt lệnh nghiêm ngặt hơn, hãy bỏ cài đặt tường minh cho approval_policy và thêm một mục dự án vào tệp cấu hình cấp người dùng ~/.codex/config.toml:

[projects."/path/to/project"]
trust_level = "untrusted"

Khi đó, các lệnh cần được phê duyệt trừ khi có quy tắc trong chính sách thực thi cho phép. Thao tác này cũng vô hiệu hóa cấu hình cục bộ của dự án. Việc đặt tường minh on-request sẽ ghi đè chính sách được suy ra từ dự án; allowed_approval_policies được quản lý phải bao gồm untrusted để cho phép chính sách đó.

Môi trường cô lập và cơ chế phê duyệt

Các biện pháp kiểm soát bảo mật của Codex gồm hai lớp phối hợp với nhau:

• Chế độ môi trường cô lập: Những gì Codex có thể thực hiện về mặt kỹ thuật (ví dụ: nơi Codex có thể ghi và liệu Codex có thể truy cập mạng hay không) khi thực thi các lệnh do mô hình tạo ra.
• Chính sách phê duyệt: Thời điểm Codex phải hỏi bạn trước khi thực thi một hành động (ví dụ: rời khỏi môi trường cô lập, sử dụng mạng hoặc chạy các lệnh nằm ngoài tập hợp đáng tin cậy).

Codex sử dụng các chế độ môi trường cô lập khác nhau tùy theo nơi bạn chạy Codex:

• Codex cloud: Chạy trong các vùng chứa biệt lập do OpenAI quản lý, ngăn truy cập vào hệ thống máy chủ của bạn hoặc dữ liệu không liên quan. Sử dụng mô hình thời gian chạy gồm hai giai đoạn: quá trình thiết lập chạy trước giai đoạn tác nhân và có thể truy cập mạng để cài đặt các phần phụ thuộc đã chỉ định; sau đó, giai đoạn tác nhân mặc định chạy ngoại tuyến, trừ khi bạn bật quyền truy cập Internet cho môi trường đó. Các bí mật được cấu hình cho môi trường đám mây chỉ khả dụng trong quá trình thiết lập và sẽ bị xóa trước khi giai đoạn tác nhân bắt đầu.
• Codex CLI / tiện ích mở rộng IDE: Các cơ chế cấp hệ điều hành thực thi chính sách môi trường cô lập. Thiết lập mặc định bao gồm không có quyền truy cập mạng và quyền ghi chỉ giới hạn trong không gian làm việc đang hoạt động. Bạn có thể cấu hình môi trường cô lập, chính sách phê duyệt và cài đặt mạng dựa trên mức độ chấp nhận rủi ro của mình.

Trong cấu hình đặt sẵn Auto (ví dụ: --sandbox workspace-write --ask-for-approval on-request), Codex có thể tự động đọc tệp, chỉnh sửa và chạy lệnh trong thư mục làm việc.

Codex yêu cầu phê duyệt để chỉnh sửa các tệp bên ngoài không gian làm việc hoặc chạy các lệnh cần quyền truy cập mạng. Nếu bạn muốn trò chuyện hoặc lập kế hoạch mà không thực hiện thay đổi, hãy chuyển sang chế độ read-only bằng lệnh /permissions.

Codex cũng có thể yêu cầu phê duyệt đối với các lệnh gọi công cụ của ứng dụng (trình kết nối) được khai báo là có tác dụng phụ, ngay cả khi hành động đó không phải là lệnh shell hoặc thay đổi tệp. Các lệnh gọi công cụ ứng dụng/MCP có tính phá hủy luôn cần được phê duyệt khi công cụ khai báo chú thích phá hủy (trừ khi công cụ khai báo chú thích đọc, vốn được ưu tiên hơn).

Giám sát an toàn và các tác vụ bị tạm dừng

GPT-6 Astra tích hợp tính năng giám sát an toàn trong Codex và ChatGPT Work. Quá trình giám sát chạy không đồng bộ và có thể tạm dừng một tác vụ nếu phát hiện hành vi có khả năng không an toàn của mô hình. Thông báo tạm dừng có thể xuất hiện sau hoạt động đã kích hoạt nó; tính năng giám sát không thay thế môi trường cô lập, quyền hạn hoặc việc xem xét kết quả.

Nếu một tác vụ bị tạm dừng, hãy đọc thông báo và xem xét các phát hiện khi chúng khả dụng. Chỉ tiếp tục sau khi kiểm tra rằng tác vụ có thể tiếp tục một cách an toàn. Nếu thông báo cho biết tác vụ đã kết thúc hoặc không cung cấp tùy chọn tiếp tục, bạn không thể tiếp tục tác vụ từ bề mặt đó.

Tính năng giám sát an toàn đánh giá hành vi của mô hình trong một tác vụ. Đánh giá phê duyệt tự động đánh giá từng hành động vốn đã cần được phê duyệt trước khi chạy. Một hành động được đánh giá phê duyệt tự động chấp thuận vẫn có thể thuộc một tác vụ mà sau đó bị tính năng giám sát tạm dừng.

Quyền truy cập mạng

Đối với Codex cloud, hãy xem quyền truy cập Internet của tác nhân để bật toàn bộ quyền truy cập Internet hoặc danh sách miền cho phép.

Đối với ứng dụng ChatGPT dành cho máy tính, Codex CLI hoặc tiện ích mở rộng IDE, chế độ môi trường cô lập workspace-write mặc định sẽ tắt quyền truy cập mạng, trừ khi bạn bật quyền này trong cấu hình:

[sandbox_workspace_write]
network_access = true

Cách ly mạng

Quyền truy cập mạng được kiểm soát thông qua các quy tắc đích áp dụng cho tập lệnh, chương trình và tiến trình con được lệnh khởi chạy. Khi quyền truy cập mạng của lệnh đã được bật, hãy bật tính năng network_proxy để giới hạn lưu lượng đó theo chính sách mạng mà bạn cấu hình. Việc thêm quy tắc miền không tự động bật proxy.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Đối với một phiên CLI dùng một lần, hãy sử dụng dạng viết tắt boolean khi bạn chỉ cần bật hoặc tắt tính năng, và sử dụng dạng bảng khi bạn cũng đặt các tùy chọn chính sách:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Tính năng này thay đổi cách thực thi quyền truy cập mạng đã bật; bản thân nó không cấp quyền truy cập mạng. Hãy sử dụng sandbox_workspace_write.network_access với cấu hình workspace-write để quyết định liệu các lệnh có được truy cập mạng hay không:

• Mạng tắt + network_proxy bật: mạng vẫn tắt và tính năng này không có tác dụng.
• Mạng bật + network_proxy tắt: mạng vẫn bật với quyền truy cập đi trực tiếp không hạn chế.
• Mạng bật + network_proxy bật: mạng vẫn bật và lưu lượng đi bị giới hạn theo chính sách mạng đã cấu hình.

Tính năng proxy cũng áp dụng cho hồ sơ quyền hạn. network.enabled = true của một hồ sơ cấp quyền truy cập mạng cho lệnh, còn features.network_proxy = true kích hoạt việc thực thi các quy tắc miền của hồ sơ đó:

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Nếu bạn bỏ qua tính năng proxy trong ví dụ này, các lệnh sẽ có quyền truy cập mạng trực tiếp và quy tắc cho phép api.openai.com sẽ không giới hạn đích của chúng.

Các yêu cầu experimental_network do quản trị viên quản lý tách biệt với nút bật/tắt tính năng của người dùng. Chúng có thể cấu hình và khởi động mạng trong môi trường cô lập mà không cần features.network_proxy, nhưng không bật quyền truy cập mạng khi môi trường cô lập đang hoạt động vẫn tắt quyền này. Hãy xem Cấu hình được quản lý để biết cấu trúc requirements.toml phía quản trị viên.

Chính sách mạng

Các quy tắc miền ưu tiên danh sách cho phép:

• Máy chủ khớp chính xác chỉ khớp với chính nó.
• *.example.com khớp với các miền con như api.example.com, nhưng không khớp với example.com.
• **.example.com khớp với cả miền gốc và các miền con.
• Quy tắc cho phép toàn cục * khớp với mọi máy chủ công khai không bị từ chối. Hãy coi * là quyền truy cập mạng rộng và ưu tiên các quy tắc có phạm vi cụ thể khi có thể.
• deny luôn được ưu tiên hơn allow, và * toàn cục chỉ hợp lệ với các quy tắc cho phép.

Đích cục bộ và riêng tư

Theo mặc định, allow_local_binding = false chặn các đích loopback, link-local và riêng tư:

• Ngoại lệ cụ thể: thêm một giá trị IP cục bộ chính xác hoặc quy tắc cho phép localhost khi một lệnh cần truy cập một đích cục bộ.
• Quyền truy cập rộng hơn: chỉ đặt allow_local_binding = true khi bạn chủ ý muốn có phạm vi truy cập cục bộ/riêng tư rộng hơn.
• Ký tự đại diện: các quy tắc ký tự đại diện không được tính là ngoại lệ cục bộ rõ ràng.
• Địa chỉ đã phân giải: tên máy chủ phân giải thành IP cục bộ/riêng tư vẫn bị chặn ngay cả khi khớp với danh sách cho phép.

Biện pháp bảo vệ chống DNS rebinding

Trước khi cho phép một tên máy chủ, Codex thực hiện kiểm tra phân loại DNS và IP theo khả năng tốt nhất:

• Các lượt tra cứu thất bại hoặc hết thời gian chờ sẽ bị chặn.
• Tên máy chủ phân giải thành địa chỉ không công khai sẽ bị chặn.
• Kiểm tra này làm giảm rủi ro DNS rebinding nhưng không loại bỏ hoàn toàn. Để ngăn chặn hoàn toàn việc rebinding, cần ghim các IP đã phân giải xuyên suốt lớp truyền tải.

Nếu DNS thù địch nằm trong phạm vi cần phòng vệ, hãy thực thi thêm các biện pháp kiểm soát lưu lượng đi ở lớp thấp hơn.

Cài đặt nguy hiểm

Hai cài đặt chủ ý mở rộng ranh giới tin cậy:

• dangerously_allow_non_loopback_proxy = true có thể để lộ các trình lắng nghe proxy ra ngoài loopback.
• dangerously_allow_all_unix_sockets = true bỏ qua danh sách cho phép socket Unix.

Chỉ sử dụng chúng trong các môi trường được kiểm soát chặt chẽ. Khi proxy socket Unix được bật, các trình lắng nghe vẫn chỉ giới hạn ở loopback ngay cả khi đã yêu cầu liên kết ngoài loopback, nhờ đó mạng trong môi trường cô lập không trở thành cầu nối từ xa đến các daemon cục bộ.

network_proxy mặc định bị tắt. Khi bạn bật tính năng này:

Lưu lượng nằm ngoài proxy mạng của lệnh

Proxy mạng lọc các tập lệnh, chương trình và tiến trình con chạy bên trong môi trường cô lập lệnh cục bộ. Proxy không lọc hoạt động tìm kiếm trên web, lệnh gọi công cụ ứng dụng hoặc trình kết nối, kết nối máy chủ MCP, hoạt động của trình duyệt hoặc Computer Use, tác vụ Codex cloud hay các yêu cầu mô hình và xác thực của ứng dụng khách. Các bề mặt này sử dụng kết nối dịch vụ, cài đặt tính năng, chính sách không gian làm việc hoặc biện pháp kiểm soát môi trường riêng.

Các công cụ trình duyệt kiểm tra riêng các quy tắc từ chối mạng được quản lý và danh sách cho phép độc quyền trước khi truy cập một nguồn. Chính sách nguồn của trình duyệt có thể giới hạn thêm quyền truy cập trang web, tải lên, tải xuống và công cụ dành cho nhà phát triển. Hãy xem các biện pháp kiểm soát trình duyệt được quản lý.

Đối với người dùng được quản lý, hãy kết hợp chính sách mạng của lệnh với các biện pháp kiểm soát như allowed_web_search_modes, các mcp_servers đã được phê duyệt và các yêu cầu về tính năng cho ứng dụng, plugin, trình duyệt hoặc Computer Use. Hãy xem Cấu hình được quản lý.

Bạn cũng có thể kiểm soát công cụ tìm kiếm trên web mà không cấp toàn bộ quyền truy cập mạng cho các lệnh được khởi chạy. Theo mặc định, Codex sử dụng bộ nhớ đệm tìm kiếm trên web để truy cập kết quả. Bộ nhớ đệm là chỉ mục kết quả web do OpenAI duy trì, vì vậy chế độ dùng bộ nhớ đệm trả về các kết quả đã được lập chỉ mục thay vì tìm nạp trực tiếp các trang. Điều này làm giảm nguy cơ bị chèn prompt từ nội dung trực tiếp tùy ý, nhưng bạn vẫn nên coi các kết quả web là không đáng tin cậy. Nếu bạn đang sử dụng --yolo hoặc một cài đặt môi trường cô lập có toàn quyền truy cập khác, tìm kiếm trên web mặc định sử dụng kết quả trực tiếp. Hãy sử dụng --search hoặc đặt web_search = "live" để cho phép duyệt web trực tiếp, hoặc đặt thành "disabled" để tắt công cụ:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Đặt web_search = "indexed" khi quyền truy cập web bên ngoài cần được kiểm soát thông qua chỉ mục tìm kiếm. Hãy thận trọng khi bật quyền truy cập mạng hoặc tìm kiếm trên web trong Codex. Việc chèn prompt có thể khiến tác nhân tìm nạp và làm theo các chỉ dẫn không đáng tin cậy.

Mặc định và khuyến nghị

• Khi khởi chạy, Codex phát hiện xem thư mục có được quản lý phiên bản hay không và đưa ra khuyến nghị:
  • Thư mục được quản lý phiên bản: Auto (ghi vào không gian làm việc + phê duyệt theo yêu cầu)
  • Thư mục không được quản lý phiên bản: read-only
• Tùy theo thiết lập, Codex cũng có thể khởi động ở chế độ read-only cho đến khi bạn tin cậy rõ ràng thư mục làm việc (ví dụ: qua lời nhắc hướng dẫn ban đầu hoặc /permissions).
• Không gian làm việc bao gồm thư mục hiện tại và các thư mục tạm thời như /tmp. Sử dụng lệnh /status để xem những thư mục nào thuộc không gian làm việc.
• Để chấp nhận các giá trị mặc định, hãy chạy codex.
• Bạn có thể đặt rõ ràng các giá trị sau:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Đường dẫn được bảo vệ trong các gốc có thể ghi

Trong chính sách môi trường cô lập workspace-write mặc định, các gốc có thể ghi vẫn bao gồm những đường dẫn được bảo vệ:

• <writable_root>/.git được bảo vệ ở chế độ chỉ đọc dù xuất hiện dưới dạng thư mục hay tệp.
• Nếu <writable_root>/.git là một tệp con trỏ (gitdir: ...), đường dẫn thư mục Git được phân giải cũng được bảo vệ ở chế độ chỉ đọc.
• <writable_root>/.agents được bảo vệ ở chế độ chỉ đọc khi tồn tại dưới dạng thư mục.
• <writable_root>/.codex được bảo vệ ở chế độ chỉ đọc khi tồn tại dưới dạng thư mục.
• Biện pháp bảo vệ có tính đệ quy, vì vậy mọi nội dung bên dưới các đường dẫn đó đều ở chế độ chỉ đọc.

Chạy mà không có lời nhắc phê duyệt

Bạn có thể tắt lời nhắc phê duyệt bằng --ask-for-approval never hoặc -a never (dạng viết tắt).

Tùy chọn này hoạt động với tất cả chế độ --sandbox, vì vậy bạn vẫn kiểm soát được mức độ tự chủ của Codex. Codex sẽ nỗ lực tối đa trong các giới hạn mà bạn đặt ra.

Nếu cần Codex đọc tệp, chỉnh sửa và chạy lệnh có quyền truy cập mạng mà không hiển thị lời nhắc phê duyệt, hãy sử dụng --sandbox danger-full-access (hoặc cờ --dangerously-bypass-approvals-and-sandbox). Hãy thận trọng trước khi làm vậy.

Để có phương án cân bằng, approval_policy = { granular = { ... } } cho phép bạn duy trì tương tác với một số danh mục lời nhắc phê duyệt cụ thể trong khi tự động từ chối các danh mục khác. Chính sách chi tiết bao gồm phê duyệt môi trường cô lập, lời nhắc quy tắc execpolicy, lời nhắc MCP, lời nhắc request_permissions và phê duyệt tập lệnh kỹ năng.

Đánh giá phê duyệt tự động

Theo mặc định, các yêu cầu phê duyệt được chuyển đến bạn:

approvals_reviewer = "user"

Đánh giá phê duyệt tự động áp dụng khi cơ chế phê duyệt mang tính tương tác, chẳng hạn như approval_policy = "on-request" hoặc một chính sách phê duyệt chi tiết. Đặt approvals_reviewer = "auto_review" để chuyển các yêu cầu phê duyệt đủ điều kiện qua một tác nhân đánh giá trước khi Codex chạy yêu cầu:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Để biết toàn bộ vòng đời của trình đánh giá, điều kiện kích hoạt, thứ tự ưu tiên cấu hình và hành vi khi xảy ra lỗi, hãy xem Đánh giá tự động.

Trình đánh giá chỉ đánh giá những hành động vốn đã cần phê duyệt, chẳng hạn như yêu cầu nâng quyền môi trường cô lập, yêu cầu mạng bị chặn, lời nhắc request_permissions hoặc lệnh gọi công cụ ứng dụng và MCP có tác dụng phụ. Các hành động vẫn nằm trong môi trường cô lập sẽ tiếp tục mà không cần thêm bước đánh giá.

Chính sách của trình đánh giá kiểm tra hành vi đánh cắp dữ liệu, dò tìm thông tin xác thực, làm suy yếu bảo mật lâu dài và các hành động phá hủy. Các hành động có rủi ro thấp và trung bình có thể tiếp tục khi chính sách cho phép. Chính sách từ chối các hành động có rủi ro nghiêm trọng. Các hành động có rủi ro cao cần có đủ sự cho phép của người dùng và không khớp với quy tắc từ chối nào. Các lỗi xây dựng prompt, phiên đánh giá và phân tích cú pháp đều bị chặn theo nguyên tắc an toàn. Trường hợp hết thời gian chờ được hiển thị riêng, nhưng hành động vẫn không được chạy.

Chính sách trình đánh giá mặc định nằm trong kho lưu trữ Codex mã nguồn mở. Doanh nghiệp có thể thay thế phần dành riêng cho đối tượng thuê bằng guardian_policy_config trong các yêu cầu được quản lý. Văn bản [auto_review].policy cục bộ cũng được hỗ trợ, nhưng các yêu cầu được quản lý được ưu tiên hơn. Để biết chi tiết thiết lập, hãy xem Cấu hình được quản lý.

Trong ứng dụng ChatGPT dành cho máy tính, các lượt đánh giá này xuất hiện dưới dạng mục đánh giá tự động với trạng thái như Đang đánh giá, Đã phê duyệt, Đã từ chối, Đã hủy hoặc Hết thời gian chờ. Chúng cũng có thể bao gồm mức độ rủi ro và đánh giá về sự cho phép của người dùng đối với yêu cầu được đánh giá.

Đánh giá tự động sử dụng thêm các lệnh gọi mô hình, vì vậy có thể làm tăng mức sử dụng Codex. Quản trị viên có thể giới hạn tính năng này bằng allowed_approvals_reviewers.

Các tổ hợp môi trường cô lập và phê duyệt thường dùng

Đối với các lượt chạy không tương tác, hãy sử dụng codex exec --sandbox workspace-write; Codex vẫn duy trì các lệnh gọi codex exec --full-auto cũ như một đường dẫn tương thích đã lỗi thời và hiển thị cảnh báo.

Cấu hình trong config.toml

Để tìm hiểu quy trình cấu hình rộng hơn, hãy xem Kiến thức cơ bản về cấu hình, Cấu hình nâng cao và Tài liệu tham khảo cấu hình.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Bạn cũng có thể lưu các cấu hình đặt sẵn dưới dạng tệp hồ sơ, sau đó chọn chúng bằng codex --profile profile-name:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Kiểm thử môi trường cô lập cục bộ

Để xem điều gì xảy ra khi một lệnh chạy trong môi trường cô lập Codex, hãy sử dụng các lệnh Codex CLI sau:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

Lệnh sandbox cũng có tên khác là codex debug, và các trình trợ giúp nền tảng có các bí danh (ví dụ: codex sandbox seatbelt và codex sandbox landlock).

Môi trường cô lập cấp hệ điều hành

Codex thực thi môi trường cô lập theo cách khác nhau tùy vào hệ điều hành của bạn:

• macOS sử dụng chính sách Seatbelt và chạy lệnh bằng sandbox-exec với một hồ sơ (-p) tương ứng với chế độ --sandbox mà bạn đã chọn. Khi quyền truy cập đọc bị giới hạn cho phép các giá trị mặc định của nền tảng, Codex thêm một chính sách nền tảng macOS được tuyển chọn (thay vì cho phép rộng rãi /System) để duy trì khả năng tương thích với các công cụ thông dụng.
• Linux mặc định sử dụng bwrap cùng với seccomp.
• Windows sử dụng cách triển khai môi trường cô lập Linux khi chạy trong Windows Subsystem for Linux 2 (WSL2). WSL1 được hỗ trợ đến hết Codex 0.114; kể từ 0.115, môi trường cô lập Linux đã chuyển sang bwrap, vì vậy WSL1 không còn được hỗ trợ. Khi chạy trực tiếp trên Windows, Codex sử dụng cách triển khai môi trường cô lập Windows.

Nếu bạn sử dụng tiện ích mở rộng Codex IDE trên Windows, tiện ích này hỗ trợ trực tiếp WSL2. Hãy đặt giá trị sau trong phần cài đặt VS Code để giữ tác nhân bên trong WSL2 bất cứ khi nào WSL2 khả dụng:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Điều này bảo đảm tiện ích mở rộng IDE kế thừa ngữ nghĩa môi trường cô lập Linux cho lệnh, cơ chế phê duyệt và quyền truy cập hệ thống tệp ngay cả khi hệ điều hành máy chủ là Windows. Tìm hiểu thêm trong hướng dẫn WSL.

Khi chạy trực tiếp trên Windows, hãy cấu hình chế độ môi trường cô lập gốc trong config.toml:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Xem hướng dẫn thiết lập Windows để biết chi tiết.

Khi chạy Linux trong một môi trường dùng vùng chứa như Docker, môi trường cô lập có thể không hoạt động nếu cấu hình máy chủ hoặc vùng chứa chặn namespace, bwrap setuid hoặc các thao tác seccomp mà Codex cần.

Trong trường hợp đó, hãy cấu hình vùng chứa Docker để cung cấp mức cách ly bạn cần, sau đó chạy codex với --sandbox danger-full-access (hoặc cờ --dangerously-bypass-approvals-and-sandbox) bên trong vùng chứa.

Chạy Codex trong Dev Containers

Nếu máy chủ của bạn không thể chạy trực tiếp môi trường cô lập Linux hoặc tổ chức của bạn đã chuẩn hóa quy trình phát triển trong vùng chứa, hãy chạy Codex bằng Dev Containers và để Docker cung cấp ranh giới cách ly bên ngoài. Cách này hoạt động với Visual Studio Code Dev Containers và các công cụ tương thích.

Hãy sử dụng ví dụ devcontainer an toàn của Codex làm cách triển khai tham khảo. Ví dụ này cài đặt Codex, các công cụ phát triển thông dụng, bubblewrap và các biện pháp kiểm soát lưu lượng đi dựa trên tường lửa.

Cách triển khai tham khảo bao gồm:

• ảnh nền Ubuntu 24.04 đã cài đặt Codex và các công cụ phát triển thông dụng;
• hồ sơ tường lửa dựa trên danh sách cho phép đối với quyền truy cập đi;
• cài đặt VS Code và khuyến nghị về tiện ích mở rộng để mở lại không gian làm việc trong vùng chứa;
• các ổ gắn kết lâu dài cho lịch sử lệnh và cấu hình Codex;
• bubblewrap, để Codex vẫn có thể sử dụng môi trường cô lập Linux khi vùng chứa cấp các quyền cần thiết.

Để dùng thử:

1. Cài đặt Visual Studio Code và tiện ích mở rộng Dev Containers.
2. Sao chép thiết lập .devcontainer mẫu của Codex vào kho lưu trữ của bạn hoặc bắt đầu trực tiếp từ kho lưu trữ Codex.
3. Trong VS Code, chạy Dev Containers: Open Folder in Container... và chọn .devcontainer/devcontainer.secure.json.
4. Sau khi vùng chứa khởi động, hãy mở terminal và chạy codex.

Bạn cũng có thể khởi động vùng chứa từ CLI:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

Ví dụ này có ba phần chính:

• .devcontainer/devcontainer.secure.json kiểm soát cài đặt, quyền hạn, ổ gắn kết, biến môi trường và tiện ích mở rộng VS Code của vùng chứa.
• .devcontainer/Dockerfile.secure định nghĩa ảnh dựa trên Ubuntu và các công cụ được cài đặt.
• .devcontainer/init-firewall.sh áp dụng chính sách mạng đi.

Tường lửa tham khảo được chủ ý thiết kế làm điểm khởi đầu. Nếu bạn dựa vào danh sách miền cho phép để cách ly, hãy triển khai các biện pháp bảo vệ chống DNS rebinding và làm mới DNS phù hợp với môi trường của mình, chẳng hạn như làm mới có xét đến TTL hoặc tường lửa nhận biết DNS.

Bên trong vùng chứa, hãy chọn một trong các chế độ sau:

• Giữ môi trường cô lập Linux của Codex ở trạng thái bật nếu hồ sơ Dev Container cấp các quyền cần thiết để bwrap tạo môi trường cô lập bên trong.
• Nếu vùng chứa là ranh giới bảo mật mà bạn chủ định sử dụng, hãy chạy Codex với --sandbox danger-full-access bên trong vùng chứa để Codex không cố tạo thêm một lớp môi trường cô lập thứ hai.

Quản lý phiên bản

Codex hoạt động hiệu quả nhất với quy trình quản lý phiên bản:

• Làm việc trên một nhánh tính năng và giữ git status sạch trước khi giao việc. Điều này giúp các bản vá của Codex dễ được tách biệt và hoàn tác hơn.
• Ưu tiên quy trình dựa trên bản vá (ví dụ: git diff/git apply) thay vì chỉnh sửa trực tiếp các tệp được theo dõi. Hãy commit thường xuyên để bạn có thể hoàn tác theo từng bước nhỏ.
• Xử lý các đề xuất của Codex như mọi PR khác: chạy quy trình xác minh có mục tiêu, xem xét diff và ghi lại các quyết định trong thông điệp commit để phục vụ kiểm tra.

Giám sát và dữ liệu đo từ xa

Codex hỗ trợ tính năng giám sát có chủ ý bật thông qua OpenTelemetry (OTel), giúp các nhóm kiểm tra việc sử dụng, điều tra sự cố và đáp ứng yêu cầu tuân thủ mà không làm suy yếu các thiết lập bảo mật cục bộ mặc định. Dữ liệu đo từ xa mặc định bị tắt; hãy bật rõ ràng trong cấu hình của bạn.

Tổng quan

• Codex mặc định tắt tính năng xuất OTel để giữ các lượt chạy cục bộ khép kín.
• Khi được bật, Codex phát ra các sự kiện nhật ký có cấu trúc bao gồm cuộc trò chuyện, yêu cầu API, hoạt động luồng SSE/WebSocket, prompt của người dùng (mặc định được biên tập ẩn), quyết định phê duyệt công cụ và kết quả công cụ.
• Codex gắn thẻ các sự kiện được xuất bằng service.name (nguồn khởi tạo), phiên bản CLI và nhãn môi trường để phân tách lưu lượng dev/staging/prod.

Bật OTel (chủ ý bật)

Thêm một khối [otel] vào cấu hình Codex của bạn (thường là ~/.codex/config.toml), chọn một trình xuất và quyết định có ghi nhật ký văn bản prompt hay không.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" duy trì thiết bị đo hoạt động nhưng không gửi dữ liệu đến đâu.
• Để gửi sự kiện đến trình thu thập riêng của bạn, hãy chọn một trong các tùy chọn sau:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex xử lý sự kiện theo lô và đẩy chúng đi khi tắt. Codex chỉ xuất dữ liệu đo từ xa do mô-đun OTel của mình tạo ra.

Danh mục sự kiện

Các loại sự kiện tiêu biểu bao gồm:

• codex.conversation_starts (mô hình, cài đặt suy luận, chính sách môi trường cô lập/phê duyệt)
• codex.api_request (lần thử, trạng thái/thành công, thời lượng và chi tiết lỗi)
• codex.sse_event (loại sự kiện luồng, thành công/thất bại, thời lượng, cùng số lượng token trên response.completed)
• codex.websocket_request và codex.websocket_event (thời lượng yêu cầu cùng loại/trạng thái thành công/lỗi của từng thông điệp)
• codex.user_prompt (độ dài; nội dung được biên tập ẩn trừ khi bạn bật rõ ràng)
• codex.tool_decision (đã phê duyệt/đã từ chối, nguồn: cấu hình hoặc người dùng)
• codex.tool_result (thời lượng, trạng thái thành công, đoạn trích đầu ra)

Các chỉ số OTel liên quan (cặp bộ đếm và biểu đồ tần suất thời lượng) bao gồm codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event và codex.tool.call (cùng các thiết bị đo .duration_ms tương ứng).

Để xem danh mục sự kiện đầy đủ và tài liệu tham khảo cấu hình, hãy đọc tài liệu cấu hình Codex trên GitHub.

Hướng dẫn bảo mật và quyền riêng tư

• Giữ log_user_prompt = false trừ khi chính sách cho phép rõ ràng việc lưu trữ nội dung prompt. Prompt có thể chứa mã nguồn và dữ liệu nhạy cảm.
• Chỉ chuyển dữ liệu đo từ xa đến các trình thu thập do bạn kiểm soát; áp dụng giới hạn lưu giữ và biện pháp kiểm soát quyền truy cập phù hợp với yêu cầu tuân thủ của bạn.
• Coi các đối số và đầu ra của công cụ là dữ liệu nhạy cảm. Ưu tiên biên tập ẩn tại trình thu thập hoặc SIEM khi có thể.
• Xem xét các cài đặt lưu giữ dữ liệu cục bộ (ví dụ: history.persistence / history.max_bytes) nếu bạn không muốn Codex lưu bản ghi phiên trong CODEX_HOME. Hãy xem Cấu hình nâng cao và Tài liệu tham khảo cấu hình.
• Nếu bạn chạy CLI khi quyền truy cập mạng bị tắt, tính năng xuất OTel không thể truy cập trình thu thập của bạn. Để xuất dữ liệu, hãy cho phép truy cập mạng ở chế độ workspace-write đối với điểm cuối OTel, hoặc xuất từ Codex cloud khi miền của trình thu thập nằm trong danh sách đã được phê duyệt.
• Định kỳ xem xét các sự kiện để phát hiện thay đổi về cơ chế phê duyệt/môi trường cô lập và những lượt thực thi công cụ ngoài dự kiến.

OTel là tùy chọn và được thiết kế để bổ trợ, không thay thế các biện pháp bảo vệ bằng môi trường cô lập và cơ chế phê duyệt được mô tả ở trên.

Cấu hình được quản lý

Quản trị viên doanh nghiệp có thể cấu hình các cài đặt bảo mật Codex cho không gian làm việc của họ trong Cấu hình được quản lý. Hãy xem trang đó để biết chi tiết về cách thiết lập và chính sách.