Tài liệu ChatGPT
Tiếng Việt
Liên hệ goolvyouyou@gmail.com

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

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

Phân phối các giá trị cấu hình mặc định và bắt buộc áp dụng yêu cầu trên các máy khách cục bộ được hỗ trợ

Cấu hình được quản lý kiểm soát hành vi của môi trường chạy cục bộ được hỗ trợ đối với các chức năng thuộc phạm vi quản lý trong ứng dụng ChatGPT dành cho máy tính, Codex CLI và tiện ích mở rộng IDE. Các yêu cầu được hỗ trợ có thể khác nhau tùy theo máy khách và phiên bản. Cấu hình được quản lý không cấp quyền truy cập không gian làm việc ChatGPT, phân bổ suất sử dụng hay thay thế cơ chế kiểm soát truy cập dựa trên vai trò (RBAC) của không gian làm việc. Hãy dùng Vai trò và quyền trong không gian làm việc để quản lý quyền truy cập tính năng của không gian làm việc và dùng trang này cho chính sách môi trường chạy cục bộ.

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 bắt buộc áp dụng 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ý kiểu cũ: các giá trị ban đầu trong managed_config.toml được áp dụng khi máy khách được hỗ trợ khởi động. Người dùng vẫn có thể thay đổi thiết lập trong khi chạy; máy 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.

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 của plugin trong config.toml của hệ thống hoặc mục config.toml của Cấu hình được quản lý. 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 máy chủ MCP 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 máy chủ MCP 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

Mỗi máy khách cục bộ được hỗ trợ kết hợp các yêu cầu theo thứ tự ưu tiên từ thấp đến cao:

  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 do doanh nghiệp quản lý được phân phối trong gói cấu hình đám mây.
  3. Các trường managed_config.toml cũ mà máy khách cục bộ diễn giải lại thành yêu cầu.
  4. Tùy chọn được quản lý trên 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.

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ở Cấu hình được quản lý để tạo và chỉ định các yêu cầu được quản lý trên đám mây. 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 nhắc 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" },
]

Hãy xác nhận rằng mọi phiên bản máy khách được quản lý đều hỗ trợ các khóa bạn chọn và thử nghiệm chính sách với một nhóm nhỏ trước khi chỉ định trên toàn tổ chức. Hãy dùng tài liệu tham khảo cấu hình để xem lược đồ hiện tại và giao diện quản trị để biết hành vi chỉ định 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

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.

Trước khi mở rộng phạm vi triển khai, hãy thử nghiệm một quy trình làm việc được phê duyệt và một quy trình cố ý không được phép với một người dùng đại diện. Xác minh các cài đặt có hiệu lực trong máy khách được hỗ trợ thay vì giả định rằng chỉ riêng vai trò hoặc nhóm trong không gian làm việc đã thực thi hạn chế 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 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 origin; đây là một bước kiểm tra chính sách riêng, không phải định tuyến lưu lượng trình duyệt qua proxy lệnh. Proxy không lọc tìm kiếm web, ứng dụng và trình kết nối, máy chủ MCP, lưu lượng ứng dụng gốc, yêu cầu dịch vụ Codex hay lưu lượng đám mây Codex. Hãy dùng các biện pháp kiểm soát tương ứng với từng bề mặt:

  • Dùng allowed_web_search_modes để hạn chế tìm kiếm web.
  • Dùng features.apps = false để tắt tích hợp ứng dụng và trình kết nối, đồng thời dùng features.plugins = false để tắt plugin ở nơi được hỗ trợ.
  • Dùng danh sách được phê duyệt mcp_servers được quản lý để hạn chế máy chủ MCP.
  • Dùng các yêu cầu tính năng như browser_use, in_app_browser và computer_use để hạn chế chức năng trình duyệt và sử dụng máy tính.
  • Cấu hình quyền truy cập mạng của Codex cloud trong phần cài đặt môi trường đám mây.

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.

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 origin khớp điều kiện được phân giải theo từng trường. Một quy tắc từ chối khớp điều kiện sẽ thắng; nếu không, chính sách origin mặc định cung cấp giá trị cho những trường mà các quy tắc khớp điều kiện không chỉ định. Cấu hình cục bộ có thể bổ sung hạn chế nhưng không thể nới lỏng một quy tắc từ chối được quản lý. Các quy tắc từ chối mạng và danh sách cho phép mạng được quản lý độc quyền vẫn được á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

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 máy chủ MCP 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. Máy chủ MCP đ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ả máy chủ MCP.

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 bằng gpt-5.6-sol trước ngày 14 tháng 10 năm 2026. GPT-5.5 sẽ ngừng được cung cấp trên ChatGPT, ChatGPT Work và Codex ở tất cả các gói vào ngày đó. OpenAI API không bị ảnh hưởng. Xem Khả năng sử dụng mô hình trong không gian làm việc.

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.4 hoặc gpt-5.4-mini cho người dùng đăng nhập bằng ChatGPT, hãy cập nhật trước ngày 31 tháng 8 năm 2026. Thay gpt-5.4 bằng gpt-5.6-terra và gpt-5.4-mini bằng gpt-5.6-luna. OpenAI API và Codex được xác thực bằng API key của riêng bạn không bị ảnh hưởng. Hãy xem khả năng sử dụng mô hình trong không gian làm việc.

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ộ.