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

Cấu hình được quản lý cho phép quản trị viên doanh nghiệp đặt các yêu cầu và giá trị mặc định được hỗ trợ cho ChatGPT Work và Codex. Các yêu cầu giới hạn những gì người dùng và tác vụ có thể thực hiện. Các giá trị mặc định cung cấp giá trị ban đầu. Mức độ hỗ trợ tùy thuộc vào sản phẩm, phiên bản ứng dụng khách và môi trường thực thi.

Đối với Work có quyền truy cập cục bộ và dots, chính sách Global được hỗ trợ chi phối bộ điều phối đám mây dùng chung khi chính sách được quản lý được bật; các yêu cầu thực thi cục bộ có hiệu lực chi phối máy tính đã kết nối. Các container đám mây của Work giữ nguyên các chính sách Work Cloud hiện có, và các biện pháp kiểm soát thiết bị được hỗ trợ vẫn áp dụng cho việc thực thi cục bộ. Codex giữ nguyên hành vi cấu hình hiện có. Cấu hình được quản lý không cấp suất sử dụng trong không gian làm việc hay quyền truy cập tính năng. Sử dụng Vai trò và quyền trong không gian làm việc để quản lý các quyền đó.

Quản trị viên Enterprise có thể kiểm soát hành vi của các máy khách cục bộ được hỗ trợ bằng:

• Yêu cầu: các ràng buộc do quản trị viên áp đặt mà người dùng không thể ghi đè.

• Giá trị cấu hình mặc định: các thiết lập config.toml do hệ thống hoặc đám mây quản lý mà người dùng có thể ghi đè.

• Giá trị mặc định được quản lý theo cơ chế cũ: các giá trị ban đầu trong managed_config.toml được áp dụng khi ứng dụng khách được hỗ trợ khởi động. Người dùng vẫn có thể thay đổi thiết lập trong một phiên chạy. Ứng dụng khách áp dụng lại các giá trị mặc định này vào lần khởi động tiếp theo.

Xem Agent Security để biết cấu hình cơ sở Global, các thiết lập ghi đè theo môi trường và danh sách trường của bộ điều phối và bộ thực thi.

Agent Security và quyền truy cập máy tính cục bộ với Work Cloud

Sử dụng Agent Security trong Bảng điều khiển quản trị để quản lý chính sách và cấu hình. Tính năng này thay thế Chính sách & Cấu hình. Agent Security sẽ được cung cấp cho mọi người, độc lập với quyền truy cập máy tính cục bộ với Work Cloud. Các chính sách, cách gán và thứ tự hiện có được giữ nguyên. Hãy rà soát các chính sách hiện có trong Agent Security. Quyền truy cập máy tính cục bộ với Work Cloud là một tùy chọn cần được bật riêng. Xem Agent Security để biết hướng dẫn chuyển đổi.

Trước khi chuyển quy trình tự động hóa chính sách sang Agent Security:

1. Xác định các tích hợp bị ảnh hưởng. Lập danh sách các cấu hình Terraform và tập lệnh cập nhật chính sách, đồng thời ghi lại những chính sách mà chúng quản lý.

2. Sử dụng API chính sách để quản lý các thiết lập Global. Để quản lý các thiết lập Local hoặc Codex Cloud, hãy sử dụng giao diện Agent Security. Các quy trình API Global hiện có vẫn khả dụng sau khi chuyển đổi. Kiểm thử các tập lệnh và tích hợp Terraform, đồng thời xác nhận rằng cách gán và thứ tự chính sách không thay đổi.

3. Thực hiện các thay đổi cần thiết và kiểm thử quy trình tự động hóa. Xác minh rằng bản cập nhật dự kiến được áp dụng đúng chính sách Agent Security và các biện pháp kiểm soát sau cập nhật được thực thi.

Việc chuyển đổi chính sách không cấp quyền truy cập máy tính cục bộ cho Work hoặc dots. Bạn nên rà soát hoặc tạo chính sách trước khi triển khai, nhưng quy trình xác nhận không yêu cầu tạo chính sách để bật quyền truy cập. Trước khi bật Cho phép truy cập máy tính cục bộ, hãy rà soát cấu hình cơ sở đã chuyển đổi hoặc tạo cấu hình cơ sở trên đám mây nếu các chính sách hiện chỉ được phân phối qua MDM. Nếu enforce_residency được bật trong bất kỳ chính sách đám mây nào, Cho phép truy cập máy tính cục bộ sẽ bị vô hiệu hóa cho cả Work và dots. Biện pháp bảo vệ này không cấu hình nơi lưu trú dữ liệu của không gian làm việc và tự nó cũng không vô hiệu hóa Work Cloud hoặc dots.

Các thiết lập ghi đè theo môi trường cho phép điều chỉnh các thiết lập được hỗ trợ trong một chính sách. Trong một chính sách nhất định, thứ tự ưu tiên từ cao xuống thấp là thiết lập ghi đè theo môi trường dành riêng cho hệ điều hành → thiết lập ghi đè theo môi trường cho mọi hệ điều hành → Global. Chính sách có mức ưu tiên cao hơn vẫn được ưu tiên hơn chính sách có mức ưu tiên thấp hơn, ngay cả khi chính sách có mức ưu tiên thấp hơn cụ thể hơn. Một số yêu cầu có quy tắc hợp nhất riêng cho từng trường. Hãy xác nhận những trình chỉnh sửa thiết lập ghi đè và trường nào khả dụng cho không gian làm việc của bạn.

Khi chính sách được quản lý và hook từ xa được bật, Work Cloud có quyền truy cập cục bộ và dots sử dụng các hook MCP từ xa do quản trị viên quản lý trên bộ điều phối đám mây. Cấu hình các trình xử lý mcp_tool trong requirements.toml ở phạm vi Global. Work Cloud không có quyền truy cập cục bộ và tài khoản cá nhân không sử dụng các hook doanh nghiệp này. Các trình xử lý lệnh/shell, prompt và tác nhân; hook từ cấu hình cục bộ, plugin hoặc thư mục cục bộ; hook có phạm vi theo môi trường; và hook MCP SessionEnd không được hỗ trợ khi điều phối trên đám mây, ngay cả khi công cụ thực thi cục bộ. Khi cả điều phối và thực thi đều diễn ra cục bộ, các hook hiện có được hỗ trợ vẫn hoạt động trong các luồng Work và Codex chỉ chạy cục bộ. Quản trị viên vẫn có thể cấu hình các hook được quản lý có hỗ trợ trong Agent Security cho những quy trình đó. Trước khi dựa vào các hook này, hãy kiểm thử khả năng kết nối callback, các sự kiện cần thiết và hành vi khi xảy ra lỗi. Một phản hồi từ chối tường minh được hỗ trợ có thể chặn một hành động, nhưng lỗi callback PreToolUse, hết thời gian chờ hoặc phản hồi sai định dạng có thể khiến hook thất bại mà không chặn công cụ. Các hook MCP không cung cấp nhật ký kiểm toán Compliance API đầy đủ. Xem Tài liệu tham khảo cấu hình.

Cấu hình kho plugin và các giá trị mặc định

Khai báo các kho plugin cục bộ hoặc Git và giá trị mặc định cho plugin trong config.toml của hệ thống hoặc trong các giá trị cấu hình mặc định được hỗ trợ trong Agent Security. Các thiết lập này là giá trị mặc định, không phải chính sách bắt buộc.

Xem Tài liệu tham khảo cấu hình để biết các khóa cấu hình, Thứ tự ưu tiên cấu hình để biết cách ghi đè và thiết lập plugin cho kho mã để cấu hình ở cấp dự án. Nhập và đồng bộ GitHub cho không gian làm việc là chức năng riêng biệt.

Yêu cầu do quản trị viên thực thi (requirements.toml)

Các yêu cầu ràng buộc những thiết lập nhạy cảm về bảo mật (chính sách phê duyệt, người xét duyệt yêu cầu phê duyệt, chính sách xét duyệt tự động, chế độ môi trường cô lập, hồ sơ quyền, chế độ tìm kiếm web, hook được quản lý, các MCP servers mà người dùng có thể bật và các nguồn kho plugin mà họ có thể dùng). Khi xác định cấu hình có hiệu lực (ví dụ từ config.toml, các tệp hồ sơ hoặc tùy chọn ghi đè cấu hình của CLI), nếu một giá trị xung đột với quy tắc bắt buộc, máy khách cục bộ sẽ dùng giá trị tương thích thay thế và thông báo cho người dùng. Nếu bạn cấu hình danh sách cho phép mcp_servers, máy khách chỉ bật MCP server khi cả tên và danh tính của máy chủ đều khớp với một mục đã được phê duyệt; nếu không, máy khách sẽ tắt máy chủ đó.

Các yêu cầu cũng có thể ràng buộc cờ tính năng thông qua bảng [features] trong requirements.toml. Lưu ý rằng tính năng không phải lúc nào cũng nhạy cảm về bảo mật, nhưng doanh nghiệp có thể cố định giá trị nếu muốn. Các khóa bị lược bỏ sẽ không bị ràng buộc.

Đối với Codex 0.138.0 trở lên, nên ưu tiên hồ sơ quyền với allowed_permission_profiles và default_permissions được quản lý. Chỉ dùng allowed_sandbox_modes cho các bản triển khai cũ vẫn còn cấu hình sandbox_mode.

Để xem danh sách khóa chính xác, hãy tham khảo phần requirements.toml trong Tài liệu tham khảo cấu hình.

Chuyển đổi khỏi 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". Hãy xóa thiết lập này khỏi các giá trị mặc định được quản lý, managed_config.toml cũ và mọi cấu hình người dùng, dự án, hồ sơ hoặc khởi động có đặt thiết lập này.

Để sử dụng tương tác ở chế độ chỉ đọc, hãy chọn approval_policy = "on-request" cùng với môi trường cô lập chỉ đọc hoặc hồ sơ quyền mà các yêu cầu được quản lý của bạn cho phép. 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.

Để duy trì việc phê duyệt lệnh nghiêm ngặt hơn, đừng đặt tường minh approval_policy, hãy đặt trust_level = "untrusted" trong mục của dự án ở tệp cấu hình cấp người dùng ~/.codex/config.toml và giữ untrusted trong allowed_approval_policies. Việ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 đó. Xem Chuyển đổi từ chính sách phê duyệt untrusted đã ngừng hỗ trợ để biết ví dụ và những đánh đổi về bảo mật.

Vị trí và thứ tự ưu tiên

Đối với việc thực thi cục bộ, các yêu cầu được áp dụng theo thứ tự ưu tiên từ thấp đến cao như sau. Thứ tự này cũng áp dụng cho các bước cục bộ khi sử dụng quyền truy cập máy tính cục bộ với Work Cloud:

1. requirements.toml của hệ thống (/etc/codex/requirements.toml trên các hệ thống Unix, bao gồm Linux và macOS, hoặc %ProgramData%\OpenAI\Codex\requirements.toml trên Windows).
2. Các yêu cầu của Agent Security được phân phối trong gói cấu hình đám mây.
3. Các trường managed_config.toml theo cơ chế cũ mà ứng dụng khách cục bộ diễn giải lại thành yêu cầu.
4. Các tùy chọn được quản lý của macOS (MDM) được phân phối qua com.openai.codex:requirements_toml_base64.

Các lớp có mức ưu tiên cao hơn ghi đè những giá trị vô hướng và danh sách thông thường của các lớp có mức ưu tiên thấp hơn. Các bảng được hợp nhất theo khóa, trong khi những yêu cầu như quy tắc, hook và hạn chế hệ thống tệp có cách kết hợp riêng theo từng trường. Hãy dùng tài liệu tham khảo requirements.toml để xem lược đồ hiện tại, thay vì giả định rằng mọi trường đều được hợp nhất theo cùng một cách.

Để tương thích ngược, các máy khách cục bộ được hỗ trợ diễn giải lại những trường approval_policy, approvals_reviewer và sandbox_mode cũ thành yêu cầu. Quá trình chuyển đổi này bổ sung các lựa chọn tương thích khi cần; hãy dùng requirements.toml cho danh sách cho phép tường minh.

Thứ tự ưu tiên cho quyền truy cập máy tính cục bộ với Work Cloud

Đối với Work có quyền truy cập cục bộ và dots, hãy phân biệt chính sách Global của bộ điều phối với chính sách thực thi. Các yêu cầu cục bộ có hiệu lực chi phối máy tính đã kết nối. Các container đám mây của Work và máy tính đám mây của dots sử dụng cấu hình và yêu cầu thực thi riêng, thay vì gói môi trường được quản lý mà các bộ thực thi khác sử dụng.

Đối với việc thực thi cục bộ, các yêu cầu MDM và yêu cầu dành cho thiết bị được quản lý theo cơ chế cũ có mức ưu tiên cao hơn Agent Security. Tệp yêu cầu cấp hệ thống của thiết bị có mức ưu tiên thấp hơn Agent Security. Trong mỗi chính sách, hãy xử lý các thiết lập ghi đè theo môi trường dành riêng cho hệ điều hành trước, sau đó đến các thiết lập ghi đè theo môi trường cho mọi hệ điều hành, rồi đến Global. Khi so sánh giữa các chính sách, mức ưu tiên của chính sách được ưu tiên hơn mức độ cụ thể.

Các yêu cầu đặt ra ràng buộc, còn các giá trị cấu hình mặc định cung cấp giá trị ban đầu. Đối với Work có quyền truy cập cục bộ và dots, chính sách Global được hỗ trợ áp dụng thông qua bộ điều phối đám mây dùng chung khi chính sách được quản lý được bật. Các yêu cầu cục bộ có hiệu lực trong requirements.toml chi phối việc thực thi trên máy tính đã kết nối. Các container đám mây của Work và máy tính đám mây của dots sử dụng cấu hình và yêu cầu thực thi riêng, thay vì gói môi trường được quản lý mà các loại bộ thực thi khác sử dụng. Các hạn chế thực thi cục bộ không tự động áp dụng cho những máy tính đám mây này. Hãy rà soát các quyền sử dụng chức năng trên đám mây và kiểm thử riêng việc thực thi cục bộ và trên đám mây.

Giữ các thiết lập điều khiển bộ điều phối, bao gồm phê duyệt và tìm kiếm trên web, trong Global. Sử dụng các thiết lập chuyên biệt Chính sách phê duyệt được phép và Chế độ tìm kiếm trên web được phép khi có, và TOML cho các trường được hỗ trợ khác. Xem Tài liệu tham khảo cấu hình để biết danh sách trường và phạm vi thực thi.

Thứ tự ưu tiên của chính sách mạng và các giới hạn khi chạy

Trong một chính sách nhất định, thứ tự từ cao xuống thấp là ghi đè theo môi trường dành riêng cho hệ điều hành → ghi đè theo môi trường cho mọi hệ điều hành → Global. Chính sách có mức ưu tiên cao hơn vẫn được ưu tiên hơn chính sách có mức ưu tiên thấp hơn, ngay cả khi chính sách có mức ưu tiên thấp hơn cụ thể hơn. Một số yêu cầu có quy tắc hợp nhất riêng cho từng trường. Sau đó, môi trường thực thi sẽ áp dụng các yêu cầu đã được xác định. Hãy xem xét các trường hợp mạng theo từng trường dưới đây tách biệt với mức ưu tiên của chính sách.

Các ví dụ này so sánh thiết lập theo môi trường và thiết lập Global trong cùng một chính sách, khi mạng được quản lý đã được cấu hình và không có chính sách nào có mức ưu tiên cao hơn thay đổi các giá trị. Chúng mô tả cách hợp nhất và hành vi khi chạy của từng trường.

Thiết lập quyền truy cập miền khác nhau theo môi trường

Đối với cùng một quy tắc miền trong một chính sách, thiết lập ghi đè theo môi trường của quản trị viên có thể cho phép một miền bị từ chối trong Global hoặc từ chối một miền được cho phép trong Global. Nếu không có thiết lập ghi đè theo môi trường, quy tắc Global sẽ được kế thừa. Các quy tắc Deny hoặc biện pháp kiểm soát truy cập khác đang có hiệu lực vẫn có thể chặn yêu cầu.

Cách kết hợp các quy tắc miền

Các kết quả này so sánh cùng một khóa miền trong một chính sách, khi không có chính sách nào có mức ưu tiên cao hơn thay đổi kết quả. Giá trị có mức ưu tiên cao hơn sẽ thay thế giá trị của cùng khóa đó. Các khóa được kế thừa khác vẫn được giữ lại. Một quy tắc Allow không bỏ qua một quy tắc Deny khác cũng khớp, chẳng hạn như quy tắc ký tự đại diện được kế thừa. Một bảng ánh xạ môi trường trống không xóa các quy tắc được kế thừa.

Ví dụ: Từ chối packages.example.com trong Global và cho phép miền này trong Development. Development có thể cho phép miền này theo các điều kiện nêu trên. Production kế thừa quy tắc Deny của Global trừ khi có ghi đè.

Xác nhận rằng trình thực thi đã triển khai hỗ trợ các quy tắc hợp nhất này. Vẫn cần xác minh phạm vi hỗ trợ của các trình thực thi được quản lý thông thường.

Giới hạn của Orchestrator. Môi trường thực thi trên đám mây không hỗ trợ các cổng lắng nghe HTTP/SOCKS được quản lý và các bộ lắng nghe proxy trên địa chỉ không phải loopback; khả năng hỗ trợ quy tắc socket phụ thuộc vào luồng thực thi. Thiết lập thực thi cục bộ trong bảng dưới đây không phải là cấu hình Orchestrator được hỗ trợ.

Các giới hạn mạng khác khi chạy

Tất cả tên trường bên dưới đều nằm trong experimental_network thuộc requirements.toml. Các mũi tên biểu thị giá trị Global, theo sau là giá trị theo môi trường trong cùng một chính sách. Các trường hợp thực thi cục bộ này không khẳng định rằng Orchestrator hỗ trợ những thiết lập tương tự.

Việc kích hoạt proxy, chế độ chỉ cho phép các miền được chỉ định, hành vi của proxy thượng nguồn và các quy tắc socket Unix có hành vi riêng tùy theo trình thực thi. Không khái quát hóa cách kết hợp các khóa miền sang những thiết lập này. Xác minh các giá trị có hiệu lực và kiểm thử môi trường thực thi đã triển khai. Để biết về kết nối cục bộ/riêng tư của Codex Cloud, xem Cấu hình yêu cầu truy cập mạng.

Xác minh hành vi trước khi triển khai rộng rãi

Kiểm thử các đích truy cập thực tế, bộ lắng nghe cục bộ, hành vi của proxy và đường dẫn socket mà quy trình làm việc của bạn sử dụng. Kiểm tra một thao tác dự kiến sẽ thành công và một thao tác dự kiến sẽ bị chặn trong mỗi môi trường chịu ảnh hưởng. Kiểm tra xem phiên bản môi trường thực thi đã triển khai có hỗ trợ từng thiết lập bạn sử dụng hay không.

Yêu cầu được quản lý trên đám mây

Khi người dùng đăng nhập bằng ChatGPT với gói được hỗ trợ, các ứng dụng khách cục bộ được hỗ trợ có thể nhận các yêu cầu do quản trị viên áp đặt cho không gian làm việc. Đây là kênh phân phối chính sách tương thích với requirements.toml. Kênh này không cấp quyền truy cập không gian làm việc hay thay thế RBAC của không gian làm việc. Các yêu cầu xác thực phải được quản lý cục bộ.

Mở Agent Security trong Bảng điều khiển quản trị để rà soát và quản lý các yêu cầu trên đám mây. Sử dụng cấu hình cơ sở toàn cục đã được di chuyển cho các chính sách hiện có. Ví dụ, chính sách này giới hạn các lựa chọn phê duyệt và môi trường cô lập, đồng thời yêu cầu xác nhận trước khi một điểm vào shell được hỗ trợ chạy:

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Kiểm tra xem mọi phiên bản ứng dụng khách được quản lý có hỗ trợ các khóa bạn chọn hay không. Gán chính sách cho người dùng hoặc nhóm dự định áp dụng và xác minh rằng chính sách có hiệu lực trên các ứng dụng khách được hỗ trợ của họ. Sử dụng tài liệu tham khảo cấu hình để biết lược đồ hiện tại và giao diện quản trị để biết hành vi gán chính sách hiện tại.

Dịch vụ chọn các lớp yêu cầu do doanh nghiệp quản lý áp dụng cho danh tính đã đăng nhập. Máy khách cục bộ đánh giá các lớp đó cùng những nguồn yêu cầu khác được mô tả trong Vị trí và thứ tự ưu tiên. Hãy dùng giao diện quản trị hiện tại để tạo và chỉ định ở phía không gian làm việc. Đừng dựa vào một thuật toán đối sánh nhóm đã sao chép; dịch vụ quản trị sở hữu hành vi đó và có thể thay đổi hành vi này độc lập với định dạng yêu cầu cục bộ.

Để xem các khóa được hỗ trợ và ví dụ, hãy tham khảo Ví dụ về requirements.toml và tài liệu tham khảo requirements.toml.

Cách máy khách cục bộ áp dụng các yêu cầu được quản lý trên đám mây

Hành vi tải và lưu bộ nhớ đệm bên dưới mô tả các ứng dụng khách cục bộ được hỗ trợ. Nội dung này không xác định thời điểm một chính sách đám mây đã thay đổi có hiệu lực trong tác vụ đang chạy sử dụng quyền truy cập máy tính cục bộ với Work Cloud. Xác minh chính sách có hiệu lực trước khi dựa vào một hạn chế đã thay đổi.

Khi người dùng khởi động một máy khách cục bộ được hỗ trợ và đăng nhập bằng ChatGPT trong một gói được hỗ trợ, trước tiên máy khách sẽ kiểm tra một mục bộ nhớ đệm hợp lệ khớp với danh tính. Nếu không có mục hợp lệ, máy khách sẽ truy xuất gói áp dụng với cơ chế thử lại và ghi một mục bộ nhớ đệm đã ký khi thành công. Nếu yêu cầu thất bại hoặc hết thời gian chờ và không có bộ nhớ đệm hợp lệ, thao tác tải gói cấu hình đám mây sẽ trả về lỗi thay vì âm thầm khởi động mà không có lớp yêu cầu được quản lý trên đám mây.

Sau khi phân giải bộ nhớ đệm, máy khách kết hợp các yêu cầu trên đám mây với những lớp yêu cầu khác được mô tả ở trên. Quá trình làm mới trong nền có thể cập nhật bộ nhớ đệm cho lần khởi động sau; quá trình này không thay thế các yêu cầu đã được tải vào tiến trình hiện tại.

Xác nhận trải nghiệm của quản trị viên và nhân viên

Chỉ định một người chịu trách nhiệm cho từng chính sách được quản lý, ghi lại những người dùng hoặc nhóm nào sẽ nhận chính sách đó, đồng thời lập tài liệu về lý do nghiệp vụ cho mọi hạn chế liên quan đến hệ thống tệp, mạng, phê duyệt hoặc hồ sơ quyền.

Kiểm thử một quy trình làm việc được phép và một quy trình làm việc bị chặn với người dùng có các quyền dự định áp dụng. Kiểm tra các thiết lập có hiệu lực trong ứng dụng khách được hỗ trợ. Chỉ riêng vai trò hoặc nhóm trong không gian làm việc không thực thi được hạn chế trong môi trường thực thi cục bộ.

Quản lý xác thực cục bộ

Đặt allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store và chatgpt_base_url trong tệp cấu hình hệ thống cục bộ requirements.toml hoặc các yêu cầu macOS MDM. Codex bỏ qua bốn trường này trong các yêu cầu được quản lý trên đám mây. Các yêu cầu xác thực cục bộ được áp dụng trước khi thông tin xác thực được tải và trước khi Codex truy xuất chính sách đám mây.

Để yêu cầu đăng nhập bằng ChatGPT vào một không gian làm việc đã được phê duyệt và lưu thông tin xác thực trong kho thông tin xác thực của hệ điều hành, hãy dùng:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods chấp nhận chatgpt, api hoặc cả hai. Nếu bị bỏ qua, thiết lập này không hạn chế phương thức đăng nhập. Nếu được đặt, danh sách phải chứa ít nhất một phương thức. api cho phép xác thực qua API, bao gồm cả Amazon Bedrock. Giới hạn về không gian làm việc cũng áp dụng cho token truy cập Codex.

forced_login_method và forced_chatgpt_workspace_id do người dùng cấu hình phải tuân thủ các yêu cầu. Khi người dùng chọn một không gian làm việc, không gian đó cũng phải có trong danh sách không gian làm việc được phép do quản trị viên quản lý. Nếu không có không gian làm việc nào khớp, việc đăng nhập bằng ChatGPT sẽ không khả dụng. Xác thực qua API vẫn khả dụng khi được cho phép. Nếu không có phương thức đăng nhập nào khả dụng, Codex sẽ từ chối khởi động.

Xem tài liệu tham chiếu về yêu cầu để biết các chế độ lưu trữ thông tin xác thực và cấu hình URL dịch vụ.

Ví dụ về requirements.toml

Ví dụ này chặn --ask-for-approval never và --sandbox danger-full-access (bao gồm --yolo):

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Ở đây, untrusted giữ nguyên cơ chế phê duyệt nghiêm ngặt hơn được suy ra từ trust_level = "untrusted"; điều này không có nghĩa là approval_policy = "untrusted" trở thành một thiết lập tường minh được hỗ trợ.

Tắt Appshots

Để tắt Appshots cho người dùng được quản lý, hãy đặt yêu cầu cấp cao nhất allow_appshots:

allow_appshots = false

Ở những nơi có Appshots, allow_appshots = false sẽ tắt chúng. Nếu bạn bỏ qua khóa này, các yêu cầu sẽ không ràng buộc Appshots và những bước kiểm tra khả dụng thông thường của sản phẩm vẫn được áp dụng. Các máy khách app-server đọc yêu cầu có hiệu lực qua configRequirements/read sẽ nhận cùng hạn chế như allowAppshots; giá trị allowAppshots bị lược bỏ hoặc là null sẽ không tắt Appshots.

Tắt điều khiển thiết bị từ xa

Để tắt điều khiển thiết bị từ xa cho người dùng được quản lý, hãy đặt yêu cầu cấp cao nhất allow_remote_control:

allow_remote_control = false

Ở những nơi hỗ trợ điều khiển thiết bị từ xa, allow_remote_control = false sẽ tắt chức năng này. Nếu bạn bỏ qua khóa, các yêu cầu sẽ không ràng buộc chức năng điều khiển thiết bị từ xa và những bước kiểm tra khả dụng thông thường của sản phẩm vẫn được áp dụng. Yêu cầu này không tắt kết nối SSH từ xa.

Kiểm soát các hồ sơ quyền khả dụng

Dùng allowed_permission_profiles để kiểm soát những hồ sơ quyền tích hợp sẵn và tùy chỉnh mà người dùng có thể chọn. Đây là thành phần tương ứng với allowed_sandbox_modes dành cho hồ sơ quyền; hãy dùng danh sách cho phép phù hợp với cách người dùng của bạn chọn quyền.

Danh sách cho phép hồ sơ quyền yêu cầu Codex 0.138.0 trở lên. Codex 0.137.0 và các phiên bản cũ hơn bỏ qua allowed_permission_profiles và default_permissions được quản lý.

Chỉ dùng các ví dụ về hồ sơ quyền bên dưới sau khi mọi máy khách được quản lý đều chạy một bản phát hành hỗ trợ. Không triển khai hồ sơ tùy chỉnh được quản lý cho đến khi quá trình nâng cấp toàn bộ đội máy hoàn tất.

Khi có mặt, bảng này là danh sách đầy đủ các hồ sơ được phép. Bảng cho phép những hồ sơ được đặt thành true và từ chối các hồ sơ bị lược bỏ hoặc được đặt thành false, bao gồm cả những hồ sơ tích hợp sẵn được bổ sung trong các phiên bản Codex tương lai.

Cho phép các hồ sơ tiêu chuẩn

Chính sách này cho phép quyền chỉ đọc và quyền truy cập không gian làm việc, nhưng không cho phép quyền truy cập đầy đủ:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Thêm giá trị mặc định đặc quyền tối thiểu được quản lý

Quản trị viên có thể định nghĩa một hồ sơ tùy chỉnh trong cùng nguồn yêu cầu. Hãy dùng tên hồ sơ riêng của tổ chức để không xung đột với tên trong cấu hình đã tải của người dùng. Tên tùy chỉnh không được bắt đầu bằng : hoặc dùng tên dành riêng filesystem.

Không triển khai hồ sơ tùy chỉnh được quản lý cho các máy khách chạy Codex 0.137.0 hoặc cũ hơn. Những máy khách đó nhận diện được bảng hồ sơ nhưng không nhận diện được giá trị mặc định được quản lý chọn hồ sơ đó.

Ví dụ:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Chỉ cho phép hồ sơ do doanh nghiệp định nghĩa

Bỏ qua tất cả hồ sơ tích hợp sẵn khi người dùng chỉ được chọn các hồ sơ do quản trị viên định nghĩa:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

Hồ sơ tùy chỉnh có thể mở rộng :workspace mặc dù người dùng không thể trực tiếp chọn hồ sơ tích hợp sẵn :workspace.

Tắt một hồ sơ được nguồn khác cho phép

Các danh sách cho phép quyền được kết hợp theo tên hồ sơ. Vì yêu cầu trên đám mây có mức ưu tiên cao hơn yêu cầu hệ thống, yêu cầu trên đám mây có thể dùng false để tắt một hồ sơ được tệp hệ thống cho phép.

Yêu cầu trên đám mây:

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

Yêu cầu hệ thống:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

Đặt tường minh default_permissions thành một hồ sơ được phép. Nếu bị lược bỏ, môi trường chạy cục bộ chỉ mặc định dùng :workspace khi cả :workspace và :read-only đều được cho phép tường minh. Khi không có allowed_permission_profiles, các yêu cầu được quản lý không hạn chế tên hồ sơ mà người dùng có thể chọn. Mỗi mục phải nêu tên một hồ sơ tích hợp sẵn hoặc một hồ sơ tùy chỉnh được định nghĩa trong nguồn cấu hình hoặc yêu cầu đã tải. Hãy định nghĩa hồ sơ tùy chỉnh trong các yêu cầu được quản lý để kiểm soát tập trung hành vi của chúng.

Ghi đè yêu cầu môi trường cô lập theo máy chủ

Dùng [[remote_sandbox_config]] khi một chính sách được quản lý cần áp dụng các yêu cầu môi trường cô lập khác nhau trên những máy chủ khác nhau. Ví dụ, bạn có thể giữ giá trị mặc định nghiêm ngặt hơn cho máy tính xách tay, đồng thời cho phép ghi vào không gian làm việc trên các máy phát triển hoặc trình chạy CI khớp điều kiện. Hiện tại, các mục riêng theo máy chủ chỉ ghi đè allowed_sandbox_modes:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Môi trường chạy cục bộ so sánh từng mục hostname_patterns với tên máy chủ được phân giải theo cơ chế nỗ lực tối đa. Môi trường này ưu tiên tên miền đầy đủ khi có và quay về tên máy chủ cục bộ nếu không có. Việc đối sánh không phân biệt chữ hoa chữ thường; * khớp với chuỗi ký tự bất kỳ và ? khớp với một ký tự.

Mục [[remote_sandbox_config]] khớp đầu tiên sẽ thắng trong cùng một nguồn yêu cầu. Nếu không có mục nào khớp, môi trường chạy cục bộ giữ nguyên allowed_sandbox_modes cấp cao nhất. Việc đối sánh tên máy chủ chỉ dùng để lựa chọn chính sách; đừng coi đây là bằng chứng thiết bị đã được xác thực.

Bạn cũng có thể ràng buộc chế độ tìm kiếm web:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] chỉ cho phép "disabled". Ví dụ, allowed_web_search_modes = ["cached"] ngăn tìm kiếm web trực tiếp ngay cả trong các phiên danger-full-access.

Cấu hình yêu cầu truy cập mạng

Dùng [experimental_network] trong requirements.toml khi quản trị viên cần định nghĩa tập trung các yêu cầu truy cập mạng. Những yêu cầu này tách biệt với nút chuyển features.network_proxy của người dùng: chúng có thể cấu hình kết nối mạng môi trường cô lập mà không cần cờ tính năng đó, nhưng không cấp quyền truy cập mạng cho lệnh khi môi trường cô lập đang hoạt động vẫn tắt kết nối mạng. Đặt experimental_network.enabled = true để kích hoạt proxy được quản lý; chỉ riêng các quy tắc miền sẽ không làm proxy hoạt động.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Chỉ dùng experimental_network.managed_allowed_domains_only = true khi bạn cũng định nghĩa các mục "allow" do quản trị viên sở hữu trong [experimental_network.domains] và muốn những quy tắc đó mang tính độc quyền. Nếu giá trị là true nhưng không có quy tắc cho phép được quản lý, các quy tắc cho phép miền do người dùng thêm sẽ không còn hiệu lực. Không kết hợp ánh xạ domains chuẩn với các danh sách cũ allowed_domains hoặc denied_domains.

*.example.com chỉ khớp với miền con. **.example.com khớp với miền gốc và các miền con của miền đó. Một quy tắc từ chối khớp điều kiện sẽ thắng quy tắc cho phép.

Cú pháp miền, quy tắc đích cục bộ/riêng tư, hành vi ưu tiên từ chối hơn cho phép và các hạn chế về DNS rebinding giống với hành vi mạng môi trường cô lập được mô tả trong Phê duyệt và bảo mật tác nhân.

Proxy định tuyến các lệnh cục bộ chạy bên trong môi trường cô lập. Các công cụ trình duyệt cũng kiểm tra các quy tắc từ chối mạng được quản lý và danh sách chỉ cho phép trước khi truy cập một nguồn. Đây là bước kiểm tra chính sách riêng biệt, không phải định tuyến lưu lượng trình duyệt qua proxy dành cho lệnh. Proxy này không lọc tìm kiếm trên web, ứng dụng và trình kết nối, MCP server, lưu lượng ứng dụng gốc, yêu cầu dịch vụ Codex hoặc lưu lượng riêng của các chức năng khác. Sử dụng các thiết lập kiểm soát cho từng thành phần:

• Sử dụng allowed_web_search_modes để hạn chế tìm kiếm trên web.
• Sử dụng features.apps = false để tắt các tích hợp ứng dụng và trình kết nối, và features.plugins = false để tắt plugin ở những nơi được hỗ trợ.
• Sử dụng danh sách phê duyệt mcp_servers được quản lý để hạn chế MCP server.
• Sử dụng các yêu cầu về tính năng như browser_use, in_app_browser và computer_use để hạn chế khả năng sử dụng trình duyệt và máy tính.
• Đối với các lệnh Codex Cloud được quản lý có hỗ trợ, hãy cấu hình riêng các yêu cầu Agent Security và thiết lập internet của môi trường Cloud.

Danh sách cho phép miền lệnh không thay thế những biện pháp kiểm soát riêng theo khả năng này.

Trên các luồng thực thi Codex Cloud được quản lý có hỗ trợ, các yêu cầu Agent Security giới hạn hoạt động mạng của lệnh. Thiết lập internet của môi trường Codex Cloud được áp dụng riêng. Một miền được cho phép trong Agent Security không ghi đè hạn chế trong thiết lập internet của môi trường Cloud. Bản thân các biện pháp kiểm soát mạng dành cho lệnh này không vô hiệu hóa tìm kiếm trên web được lưu trữ trên dịch vụ, ứng dụng hoặc MCP. ChatGPT Work Cloud có các quyền chức năng riêng và không kế thừa những yêu cầu Agent Security này.

Danh sách cho phép dành cho lệnh được quản lý áp dụng cho các lệnh sử dụng proxy được quản lý. Khi chính sách cho phép nâng quyền để vượt toàn bộ giới hạn môi trường cô lập và việc này được phê duyệt, quá trình thực thi đó có thể bỏ qua proxy dành cho lệnh. Việc cấp quyền mạng trong phạm vi hẹp khác với nâng quyền để vượt toàn bộ giới hạn môi trường cô lập. Cấu hình các yêu cầu phê duyệt và môi trường cô lập bắt buộc để thiết lập ranh giới mong muốn, đồng thời kiểm thử cả lệnh thông thường lẫn lệnh được nâng quyền.

Không có đích truy cập được phép nào có hiệu lực: Khi Quản lý mạng và Chỉ cho phép các miền do quản trị viên thêm được Bật, các lệnh được quản lý thông thường cần có các đích truy cập được phép có hiệu lực. Nếu không có mục Allow nào được cấu hình hoặc kế thừa, các lệnh đó sẽ không có đích truy cập được phép. Chính sách chỉ có quy tắc từ chối không ngầm cho phép truy cập phần còn lại của internet. Thêm các mục Allow cần thiết và kiểm tra các quy tắc được kế thừa trước khi lưu. Hạn chế này áp dụng cho proxy dành cho lệnh được quản lý, không áp dụng cho mọi công cụ hoặc việc nâng quyền để vượt toàn bộ giới hạn môi trường cô lập đã được phê duyệt.

Kết nối cục bộ/riêng tư của Codex Cloud: Giá trị Tắt được đặt rõ ràng cho kết nối cục bộ/riêng tư có thể ngăn Codex Cloud truy cập proxy thượng nguồn, ngay cả khi miền đích được cho phép. Kiểm tra giá trị allow_local_binding cuối cùng và xác định chính sách hoặc cài đặt nào cung cấp giá trị đó. Trên luồng proxy Cloud được hỗ trợ, giá trị này chỉ mặc định là true khi không có yêu cầu áp dụng, cấu hình mạng được chọn hoặc cài đặt tính năng proxy nào cung cấp giá trị. Giá trị false được kế thừa vẫn được tính là một cài đặt rõ ràng. Khi được hỗ trợ, hãy đặt giá trị ghi đè Cloud có mức ưu tiên cao hơn để thay đổi giá trị này cho Codex Cloud mà không thay đổi giá trị Global được Local sử dụng. Thao tác này không thêm mục Allow cho miền. Xác minh khả năng hỗ trợ của trình thực thi trước khi dựa vào giá trị ghi đè. Không áp dụng giá trị mặc định Cloud này cho Local.

Các yêu cầu môi trường để trống sẽ kế thừa Global. Đặt Quản lý mạng thành Tắt không tương đương với việc tắt quyền truy cập Internet của môi trường Cloud. Xem Cấu hình mạng trong giao diện.

Kiểm soát trình duyệt và Computer Use

Dùng các bảng [browser_use] và [computer_use] trong requirements.toml để hạn chế các máy khách dành cho máy tính được hỗ trợ. Hãy xác thực chính sách trên các phiên bản máy khách và hệ điều hành trong bản triển khai của bạn. Một quy tắc cho phép đã cấu hình không cài đặt plugin, cấp quyền hệ điều hành hay phê duyệt một hành động vẫn cần được xét duyệt.

Đối với quyền truy cập trình duyệt, hãy cấu hình chính sách origin. Một origin bao gồm scheme, máy chủ và cổng không bắt buộc, chẳng hạn như https://example.com hoặc https://*.example.com:8443. Không đưa đường dẫn, truy vấn hoặc fragment vào. Khác với quy tắc miền mạng lệnh, quy tắc origin của trình duyệt phân biệt HTTP với HTTPS và đối sánh cả cổng.

Ví dụ này giới hạn quyền truy cập trình duyệt vào một trang web được phê duyệt, đồng thời ngăn tải tệp lên và quyền truy cập đầy đủ vào Chrome DevTools Protocol (CDP) tại đó:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Các quy tắc nguồn gốc khớp được phân giải theo từng trường. Quy tắc từ chối khớp sẽ được ưu tiên. Nếu không, chính sách nguồn gốc mặc định sẽ cung cấp các trường mà những quy tắc khớp không chỉ định. Cấu hình cục bộ có thể thêm hạn chế nhưng không thể nới lỏng lệnh từ chối do quản trị viên quản lý. Các quy tắc từ chối mạng và danh sách chỉ cho phép truy cập mạng do quản trị viên quản lý vẫn áp dụng.

Đặt browser_use.disable_auto_review = true để tắt tính năng tự động xét duyệt yêu cầu phê duyệt cho các hành động trong trình duyệt, hoặc đặt auto_review = "deny" trong một chính sách origin để hạn chế tính năng này cho origin đó. Cài đặt này kiểm soát việc xử lý phê duyệt; nó không tắt hoạt động giám sát an toàn của mô hình.

Đối với ứng dụng gốc, hãy đặt một chính sách truy cập mặc định và xác định các ứng dụng được phép. Ví dụ, chính sách macOS này cho phép Calculator và ngăn lưu các phê duyệt:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Chính sách Windows có thể xác định ứng dụng đóng gói bằng computer_use.windows.aumids hoặc tệp thực thi bằng computer_use.windows.exes. Quy tắc tệp thực thi yêu cầu publisher_name, product_name và access; binary_name là tùy chọn. Hãy dùng danh tính đã xác minh của ứng dụng thay vì chỉ dùng tên hiển thị.

Hãy xem tài liệu tham khảo cấu hình để biết đầy đủ các trường và các hạn chế của Locked Use cho thiết bị macOS được quản lý.

Cố định cờ tính năng

Bạn cũng có thể cố định cờ tính năng cho người dùng nhận requirements.toml được quản lý:

[features]
personality = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Dùng các khóa tính năng chuẩn từ bảng [features] của config.toml cho các tính năng của môi trường chạy. Môi trường chạy cục bộ chuẩn hóa những tính năng được nhận diện để đáp ứng các giá trị cố định này và từ chối các thao tác ghi xung đột vào config.toml hoặc cài đặt tính năng trong tệp hồ sơ.

• in_app_browser = false tắt ngăn trình duyệt tích hợp sẵn.
• in_app_updates = false tắt trình cập nhật riêng của ứng dụng ChatGPT dành cho máy tính khi khởi động lại, ở nơi được hỗ trợ. Cài đặt này không ảnh hưởng đến việc triển khai gói bên ngoài hay kéo dài thời gian hỗ trợ cho các phiên bản ứng dụng cũ. Để biết hướng dẫn thiết lập và triển khai, hãy xem Quản lý bản cập nhật ứng dụng.
• browser_use = false tắt Computer Use trong trình duyệt và khả năng sử dụng Browser Agent.
• browser_use_full_cdp_access = false tắt quyền truy cập CDP đầy đủ trong môi trường chạy cục bộ, bao gồm chế độ Browser Developer, đồng thời ngăn ứng dụng ChatGPT dành cho máy tính bật cài đặt tương ứng.
• browser_use_external = false tắt Browser Use bên ngoài.
• computer_use = false tắt Computer Use, Record & Replay cùng các quy trình cài đặt hoặc thiết lập liên quan.

Nếu bạn bỏ qua các khóa này, chính sách sẽ cho phép các tính năng, tùy thuộc vào khả năng khả dụng thông thường của máy khách, nền tảng và đợt triển khai.

Hạn chế sử dụng máy tính ở chế độ khóa

Để ngăn người dùng bật Locked Use trên máy Mac được quản lý, hãy thêm yêu cầu này:

[computer_use]
allow_locked_computer_use = false

Yêu cầu này loại bỏ các nút điều khiển dùng để bật Locked Use. Yêu cầu này không tắt Locked Use nếu tính năng đã được bật. Nếu bạn bỏ qua yêu cầu này, khả năng khả dụng thông thường của sản phẩm và cài đặt cục bộ của người dùng vẫn được áp dụng.

Cấu hình chính sách xét duyệt tự động

Dùng allowed_approvals_reviewers để bắt buộc hoặc cho phép xét duyệt tự động. Đặt thành ["auto_review"] để bắt buộc xét duyệt tự động, hoặc bao gồm "user" khi người dùng có thể chọn phê duyệt thủ công.

Đặt guardian_policy_config để thay thế phần dành riêng cho tenant trong chính sách xét duyệt tự động. Môi trường chạy cục bộ vẫn sử dụng mẫu người xét duyệt tích hợp sẵn và hợp đồng đầu ra. guardian_policy_config được quản lý có mức ưu tiên cao hơn [auto_review].policy cục bộ.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Thực thi yêu cầu từ chối đọc

Quản trị viên có thể từ chối thao tác đọc đối với đường dẫn chính xác hoặc mẫu glob bằng [permissions.filesystem]. Người dùng không thể làm suy yếu những yêu cầu này bằng cấu hình cục bộ.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Khi có yêu cầu từ chối đọc, môi trường chạy cục bộ sẽ từ chối quyền truy cập đầy đủ và giữ hoạt động thực thi cục bộ trong môi trường cô lập chỉ đọc hoặc môi trường cô lập không gian làm việc để có thể thực thi các yêu cầu đó. Trên Windows gốc, deny_read được quản lý áp dụng cho các công cụ tệp trực tiếp; thao tác đọc của tiến trình con shell không sử dụng quy tắc môi trường cô lập này.

Thực thi hook được quản lý từ các yêu cầu

Khi chính sách được quản lý và hook từ xa được bật, Work Cloud có quyền truy cập cục bộ và dots sử dụng các hook MCP từ xa do quản trị viên quản lý trên bộ điều phối đám mây. Cấu hình trình xử lý mcp_tool trong requirements.toml của Global. Work Cloud không có quyền truy cập cục bộ và tài khoản cá nhân không sử dụng các hook doanh nghiệp này. Trình xử lý lệnh/shell, lời nhắc và tác nhân; hook từ cấu hình cục bộ, plugin hoặc thư mục cục bộ; hook có phạm vi môi trường; và hook MCP SessionEnd không được hỗ trợ khi điều phối trên đám mây, ngay cả khi công cụ thực thi cục bộ. Khi cả điều phối và thực thi đều diễn ra cục bộ, các hook hiện được hỗ trợ vẫn hoạt động trong các luồng Work và Codex chỉ chạy cục bộ. Quản trị viên vẫn có thể cấu hình các hook được quản lý có hỗ trợ trong Agent Security cho những quy trình này.

Trước khi dựa vào các hook này, hãy kiểm tra khả năng kết nối gọi lại, các sự kiện cần thiết và hành vi khi xảy ra lỗi. Một lệnh từ chối rõ ràng được hỗ trợ có thể chặn hành động, nhưng lỗi gọi lại PreToolUse, hết thời gian chờ hoặc phản hồi sai định dạng có thể khiến hook thất bại mà không chặn công cụ. Hook MCP không cung cấp nhật ký kiểm toán Compliance API đầy đủ. Các ví dụ về tập lệnh và thư mục sau đây vẫn giữ phạm vi áp dụng cho Codex.

Quản trị viên cũng có thể định nghĩa hook vòng đời được quản lý ngay trong requirements.toml. Dùng [hooks] cho chính cấu hình hook và trỏ managed_dir đến thư mục nơi công cụ MDM hoặc quản lý điểm cuối của bạn cài đặt các script được tham chiếu.

Để thực thi hook được quản lý ngay cả với người dùng đã tắt hook cục bộ, hãy cố định [features].hooks = true cùng với [hooks]. Để bỏ qua hook của người dùng, dự án, phiên và plugin nhưng vẫn cho phép hook được quản lý, hãy đặt allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Lưu ý:

• Môi trường chạy cục bộ thực thi cấu hình hook từ requirements.toml, nhưng không phân phối các script trong managed_dir.
• Hãy phân phối các script đó bằng giải pháp MDM hoặc quản lý thiết bị của bạn.
• Lệnh hook được quản lý nên tham chiếu đường dẫn script tuyệt đối trong thư mục được quản lý đã cấu hình.
• allow_managed_hooks_only = true bỏ qua hook từ các nguồn người dùng, dự án, phiên và plugin, nhưng vẫn tải hook từ requirements.toml và các lớp cấu hình được quản lý khác.

Thực thi quy tắc lệnh từ các yêu cầu

Quản trị viên cũng có thể thực thi các quy tắc lệnh mang tính hạn chế từ requirements.toml bằng bảng [rules]. Những quy tắc này được hợp nhất với các tệp .rules thông thường và quyết định nghiêm ngặt nhất vẫn thắng.

Khác với .rules, quy tắc yêu cầu phải chỉ định decision và quyết định đó phải là "prompt" hoặc "forbidden" (không phải "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Để hạn chế những MCP servers mà máy khách cục bộ có thể bật, hãy thêm danh sách được phê duyệt mcp_servers. Đối với máy chủ stdio, hãy đối sánh theo command; đối với máy chủ HTTP có thể truyền luồng, hãy đối sánh theo url:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

Dạng chuỗi của identity.command chỉ khớp với command đã cấu hình. Dạng này không kiểm tra args, cwd, env hoặc env_vars.

Để ràng buộc một lệnh gọi stdio hoàn chỉnh, hãy đối sánh tệp thực thi và từng đối số vị trí:

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

Tệp thực thi, số lượng đối số và thứ tự đối số phải khớp. Quy tắc đối số và URL hỗ trợ đối sánh exact, prefix và regex theo toàn bộ giá trị. Quy tắc lệnh có cấu trúc vẫn không kiểm tra cwd, env hoặc env_vars. MCP server đi kèm plugin sử dụng cùng các dạng danh tính trong plugins.<plugin>.mcp_servers.<server>.

Nếu có mcp_servers nhưng danh sách trống, máy khách cục bộ sẽ tắt tất cả MCP servers.

Kiểm soát khả năng sử dụng plugin

Để tắt plugin trong các máy khách cục bộ được hỗ trợ, hãy đặt features.plugins thành false trong requirements.toml:

features.plugins = false

Cài đặt này cũng áp dụng khi người dùng đăng nhập vào Codex bằng API key. Hãy xem tài liệu tham khảo features.plugins để biết cấu hình được hỗ trợ.

Hạn chế nguồn marketplace plugin

Để hạn chế các nguồn kho plugin, hãy đặt restrict_to_allowed_sources = true và xác định một hoặc nhiều quy tắc nguồn:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

Quy tắc Git đối sánh URL kho lưu trữ đã chuẩn hóa và, khi có, một ref chính xác. Mẫu máy chủ là biểu thức chính quy được đối sánh với máy chủ Git viết thường; hãy dùng ^ và $ để đối sánh toàn bộ máy chủ. Quy tắc cục bộ yêu cầu một đường dẫn tuyệt đối, đã chuẩn hóa. Hãy xem tài liệu tham khảo requirements.toml để biết đầy đủ lược đồ và hành vi hợp nhất.

Các yêu cầu này từ chối thao tác thêm kho plugin, cài đặt plugin và làm mới kho plugin Git đã cấu hình nếu không khớp quy tắc nguồn. Chúng cũng lọc các kho plugin đã cấu hình và các plugin của những kho đó trong thời gian chạy.

Các kho plugin Git do OpenAI tuyển chọn, bao gồm danh mục API key, cũng phải khớp với danh sách nguồn được phép. Để cho phép các kho này, hãy thêm nguồn Git sau mà không đặt ràng buộc ref:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Để loại trừ các danh mục được tuyển chọn, hãy bỏ nguồn đó và bảo đảm không có quy tắc máy chủ nào rộng hơn cho phép nguồn đó. Các plugin đi kèm và plugin của không gian làm việc được cài đặt từ xa không thuộc phạm vi của chính sách nguồn Git được tuyển chọn này.

Những hạn chế nguồn này chỉ áp dụng ở nơi máy khách cục bộ hỗ trợ thao tác với marketplace plugin: ChatGPT và Codex trong ứng dụng dành cho máy tính, cùng Codex CLI. Chúng không kiểm soát việc sử dụng plugin trong ChatGPT trên web hoặc thiết bị di động và không thêm plugin vào tiện ích mở rộng IDE.

Giá trị mặc định được quản lý (managed_config.toml)

Giá trị mặc định được quản lý thiết lập cấu hình mà một máy khách cục bộ được hỗ trợ dùng khi khởi động. Khi khởi động, chúng ghi đè config.toml cục bộ của người dùng và mọi giá trị ghi đè CLI --config. Người dùng vẫn có thể thay đổi những cài đặt đó trong lượt chạy hiện tại và các giá trị mặc định sẽ được áp dụng lại vào lần khởi động tiếp theo của máy khách.

Nếu một giá trị mặc định được quản lý, hồ sơ MDM macOS hoặc cấu hình đã lưu cố định gpt-5.5 cho người dùng Codex đăng nhập bằng ChatGPT, hãy thay thế bằng một mô hình khả dụng trước ngày 14 tháng 10 năm 2026. Chọn gpt-6-sol sau khi quản trị viên đã bật mô hình này cho những người dùng bị ảnh hưởng. GPT-5.5 sẽ ngừng hoạt động trên ChatGPT, ChatGPT Work và Codex đối với mọi gói vào ngày đó. OpenAI API không bị ảnh hưởng. Xem khả năng cung cấp mô hình trong không gian làm việc.

Đối với các cấu hình vẫn cố định gpt-5.4 hoặc gpt-5.4-mini, hãy làm theo hướng dẫn di chuyển GPT-5.4.

Hãy bảo đảm các giá trị mặc định được quản lý đáp ứng yêu cầu của bạn; môi trường chạy cục bộ sẽ từ chối các giá trị không được phép.

Thứ tự ưu tiên và phân lớp

Môi trường chạy cục bộ tập hợp cấu hình có hiệu lực theo thứ tự sau (phía trên ghi đè phía dưới):

• Tùy chọn được quản lý (MDM macOS; mức ưu tiên cao nhất)
• managed_config.toml (tệp hệ thống/được quản lý)
• config.toml (cấu hình cơ sở của người dùng)

Các giá trị ghi đè CLI --config key=value áp dụng cho cấu hình cơ sở, nhưng các lớp được quản lý sẽ ghi đè chúng. Điều này có nghĩa là mỗi lượt chạy đều bắt đầu từ các giá trị mặc định được quản lý, ngay cả khi bạn cung cấp cờ cục bộ.

config.toml trên đám mây sử dụng thứ tự ưu tiên cấu hình thông thường, không phải thứ tự cũ ở trên. requirements.toml trên đám mây sử dụng thứ tự ưu tiên yêu cầu.

Vị trí

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/không phải Unix: ~/.codex/managed_config.toml

Nếu thiếu tệp, môi trường chạy cục bộ sẽ bỏ qua lớp được quản lý.

Tùy chọn được quản lý trên macOS (MDM)

Trên macOS, quản trị viên có thể đẩy một hồ sơ thiết bị cung cấp các payload TOML được mã hóa base64 tại:

• Miền tùy chọn: com.openai.codex
• Khóa:
  • config_toml_base64 (giá trị mặc định được quản lý)
  • requirements_toml_base64 (yêu cầu)

Môi trường chạy cục bộ phân tích các payload "tùy chọn được quản lý" này dưới dạng TOML. Đối với giá trị mặc định được quản lý (config_toml_base64), tùy chọn được quản lý có mức ưu tiên cao nhất. Đối với yêu cầu (requirements_toml_base64), thứ tự ưu tiên tuân theo thứ tự yêu cầu được quản lý trên đám mây mô tả ở trên. Cùng bảng [features] phía yêu cầu hoạt động trong requirements_toml_base64; tại đây cũng hãy dùng các khóa tính năng chuẩn.

Quy trình thiết lập MDM

Môi trường chạy cục bộ tuân thủ các payload MDM tiêu chuẩn của macOS, vì vậy bạn có thể phân phối cài đặt bằng những công cụ như Jamf Pro, Fleet hoặc Kandji. Một bản triển khai gọn nhẹ sẽ có dạng:

1. Tạo payload TOML được quản lý và mã hóa bằng base64 (không ngắt dòng).
2. Đưa chuỗi vào hồ sơ MDM của bạn trong miền com.openai.codex tại config_toml_base64 (giá trị mặc định được quản lý) hoặc requirements_toml_base64 (yêu cầu).
3. Đẩy hồ sơ, sau đó yêu cầu người dùng khởi động lại máy khách cục bộ được hỗ trợ và xác nhận bản tóm tắt cấu hình lúc khởi động phản ánh các giá trị được quản lý.
4. Khi thu hồi hoặc thay đổi chính sách, hãy cập nhật payload được quản lý; máy khách đọc tùy chọn đã làm mới vào lần khởi chạy tiếp theo.

Tránh nhúng bí mật hoặc giá trị động thay đổi thường xuyên vào payload. Hãy quản lý TOML được quản lý như mọi cài đặt MDM khác theo quy trình kiểm soát thay đổi.

Ví dụ về managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = "otlp-http"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Các biện pháp bảo vệ nên dùng

• Ưu tiên workspace-write kèm phê duyệt cho hầu hết người dùng; chỉ dành quyền truy cập đầy đủ cho các container được kiểm soát.
• Giữ network_access = false trừ khi quá trình xét duyệt bảo mật của bạn cho phép một bộ thu thập hoặc các miền mà quy trình làm việc yêu cầu.
• Dùng cấu hình được quản lý để cố định cài đặt OTel (trình xuất, môi trường), nhưng giữ log_user_prompt = false trừ khi chính sách của bạn cho phép rõ ràng việc lưu nội dung prompt.
• Định kỳ kiểm tra chênh lệch giữa config.toml cục bộ và chính sách được quản lý để phát hiện sai lệch; các lớp được quản lý phải thắng cờ và tệp cục bộ.