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

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

Thực thi các yêu cầu về môi trường chạy trên những ứng dụng cục bộ được hỗ trợ và phân phối các giá trị mặc định được quản lý

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 nằm trong phạm vi quản lý của ứ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 ứng dụng 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, chỉ định giấy phép sử dụng hoặc 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 xem Vai trò và quyền trong không gian làm việc để quản lý quyền truy cập chức năng của không gian làm việc và xem trang này để quản lý chính sách môi trường chạy cục bộ.

Quản trị viên doanh nghiệp có thể kiểm soát hành vi được hỗ trợ của ứng dụng cục bộ theo hai cách:

  • Yêu cầu: các ràng buộc do quản trị viên thực thi mà người dùng không thể ghi đè.
  • Giá trị mặc định được quản lý: các giá trị ban đầu được áp dụng khi một ứng dụng được hỗ trợ khởi chạy. Người dùng vẫn có thể thay đổi cài đặt trong một lượt chạy; ứng dụng sẽ áp dụng lại các giá trị mặc định được quản lý vào lần khởi động tiếp theo.

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 cài đặt nhạy cảm về bảo mật (chính sách phê duyệt, người xét duyệt phê duyệt, chính sách xét duyệt tự động, chế độ sandbox, hồ sơ quyền, chế độ tìm kiếm web, hook được quản lý, những máy chủ MCP mà người dùng có thể bật, cũng như những nguồn chợ plugin do người dùng cấu hình mà họ có thể thêm, cài đặt từ đó hoặc làm mới). Khi phân giải cấu hình (ví dụ từ config.toml, tệp hồ sơ hoặc các giá trị ghi đè cấu hình CLI), nếu một giá trị xung đột với quy tắc được thực thi, ứng dụng cục bộ sẽ chuyển về một giá trị tương thích 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, ứng dụng 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, ứng dụng 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 các 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ị bỏ qua sẽ không bị ràng buộc.

Đối với Codex 0.138.0 trở lên, nên dùng 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ấ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.

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

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

  1. requirements.toml 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 cung cấp trong gói cấu hình đám mây.
  3. Các trường managed_config.toml cũ mà ứng dụng 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ý trên macOS (MDM) được cung cấp qua com.openai.codex:requirements_toml_base64.

Các lớp có mức ưu tiên cao hơn sẽ ghi đè các giá trị vô hướng và danh sách thông thường của những lớp có mức ưu tiên thấp hơn. Các bảng được hợp nhất theo khóa, còn những yêu cầu như quy tắc, hook và hạn chế hệ thống tệp có cách tổng hợp riêng theo từng trường. Hãy dùng tài liệu tham khảo requirements.toml cho 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 ứng dụng cục bộ được hỗ trợ diễn giải lại những trường cũ approval_policy, approvals_reviewer và sandbox_mode thành các 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 trên một gói được hỗ trợ, các ứng dụng cục bộ được hỗ trợ có thể nhận những yêu cầu do quản trị viên thực thi được liên kết với không gian làm việc. Đây là một 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.

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 yêu cầu các ứng dụng được hỗ trợ sử dụng nơi lưu trú dữ liệu tại Hoa Kỳ, giới hạn các lựa chọn phê duyệt và sandbox, đồng thời nhắc xác nhận trước khi một điểm vào shell được hỗ trợ chạy:

enforce_residency = "us"
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 ứng dụng được quản lý đều hỗ trợ các khóa bạn chọn, đồng thời thử nghiệm chính sách với một nhóm nhỏ trước khi chỉ định cho toàn tổ chức. Hãy dùng tài liệu tham khảo cấu hình cho lược đồ hiện tại và giao diện quản trị cho 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. Ứng dụng cục bộ đánh giá những lớp đó cùng với các 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 độc lập với định dạng yêu cầu cục bộ.

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

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

Khi người dùng khởi động một ứng dụng cục bộ được hỗ trợ và đăng nhập bằng ChatGPT trên một gói được hỗ trợ, trước tiên ứng dụng 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ệ, ứng dụng sẽ tải 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ệ, quá trình 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, ứng dụng tổng hợp các yêu cầu đám mây với những lớp yêu cầu khác được mô tả ở trên. Một lần làm mới trong nền có thể cập nhật bộ nhớ đệm cho lần khởi động sau; thao tác 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.

requirements.toml mẫu

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"]

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

Ở nơi có Appshots, allow_appshots = false sẽ tắt tính 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 Appshots và các bước kiểm tra khả dụng thông thường của sản phẩm vẫn được áp dụng. Những ứng dụng máy chủ đọc yêu cầu có hiệu lực thông qua configRequirements/read sẽ nhận cùng hạn chế như allowAppshots; giá trị allowAppshots bị bỏ qua 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

Ở nơi hỗ trợ điều khiển thiết bị từ xa, allow_remote_control = false sẽ tắt tính 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 tính năng điều khiển thiết bị từ xa và các 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à cơ chế 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 ứng dụng được quản lý đều chạy một bản phát hành có hỗ trợ. Đừng triển khai hồ sơ tùy chỉnh được quản lý cho đến khi hoàn tất nâng cấp toàn bộ đội thiết bị.

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 những hồ sơ bị bỏ qua hoặc được đặt thành false, bao gồm cả các hồ sơ tích hợp sẵn được thêm trong những 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 quản lý theo nguyên tắc đặc quyền tối thiểu

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

Đừng triển khai hồ sơ tùy chỉnh được quản lý cho các ứng dụng chạy Codex 0.137.0 hoặc cũ hơn. Những ứng dụng đó nhận diện bảng hồ sơ nhưng không nhận diện 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 các hồ sơ do doanh nghiệp định nghĩa

Bỏ qua mọi hồ sơ tích hợp sẵn khi người dùng chỉ nên chọn 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 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 đám mây có mức ưu tiên cao hơn yêu cầu hệ thống, yêu cầu đá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 đá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 default_permissions một cách tường minh thành một hồ sơ được phép. Nếu bị bỏ qua, 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 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 sandbox 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 sandbox khác nhau trên những máy chủ khác nhau. Ví dụ, bạn có thể giữ một 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 dành riêng cho 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 khả năng tốt nhất. Môi trường ưu tiên tên miền đầy đủ khi có sẵn và dùng tên máy chủ cục bộ làm phương án dự phòng. Quá trình khớp 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ẽ được dù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 khớp tên máy chủ chỉ dùng để chọn chính sách; đừng coi đó 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 mạng sandbox 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 sandbox đang hoạt động vẫn tắt mạng.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

Chỉ dùng experimental_network.managed_allowed_domains_only = true khi bạn cũng định nghĩa allowed_domains do quản trị viên sở hữu và muốn danh sách cho phép đó có tính độc quyền. Nếu giá trị là true mà 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.

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ế liên quan đến DNS rebinding giống với hành vi mạng sandbox được mô tả trong Phê duyệt và bảo mật của tác nhân.

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

Bạn cũng có thể cố định cờ tính năng cho những 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 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ợ. Giá trị 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 và 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 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 ứng dụng, nền tảng và đợt triển khai.

Hạn chế sử dụng máy tính khi bị khóa

Để ngăn Computer Use hoạt động sau khi máy Mac được quản lý bị khóa, hãy thêm yêu cầu này:

[computer_use]
allow_locked_computer_use = false

Yêu cầu này không bật Computer Use. Nó chỉ ngăn sử dụng khi bị khóa trên macOS. Nếu bạn bỏ qua yêu cầu này, các yêu cầu sẽ không ràng buộc việc sử dụng khi bị khóa; 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 để yêu cầu 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 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 quyền đọ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à duy trì quá trình thực thi cục bộ trong sandbox chỉ đọc hoặc sandbox không gian làm việc để có thể thực thi chúng. Trên Windows nguyên bản, 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 dùng quy tắc sandbox này.

Thực thi hook được quản lý từ 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 những 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 cung cấp những script đó bằng giải pháp MDM hoặc quản lý thiết bị của bạn.
  • Các 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ừ yêu cầu

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

Không giống .rules, các 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à ứng dụng cục bộ có thể bật, hãy thêm danh sách được phê duyệt mcp_servers. Với máy chủ stdio, hãy khớp theo command; với máy chủ HTTP có thể truyền luồng, hãy khớp 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. Nó 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 khớp 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. Các quy tắc đối số và URL hỗ trợ khớp exact, prefix và toàn bộ giá trị regex. 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 dùng cùng các dạng danh tính trong plugins.<plugin>.mcp_servers.<server>.

Nếu mcp_servers có mặt nhưng rỗng, ứng dụng cục bộ sẽ tắt mọi máy chủ MCP.

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

Để tắt plugin trong các ứng dụng 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 chợ plugin

Để hạn chế các thao tác trên nguồn chợ do người dùng cấu hình, hãy đặt restrict_to_allowed_sources = true và định nghĩa 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 khớp với 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 khớp với máy chủ Git viết thường; hãy dùng ^ và $ để khớp 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 lược đồ đầy đủ và hành vi hợp nhất.

Những yêu cầu này từ chối các thao tác thêm chợ, cài đặt plugin và làm mới chợ Git đã cấu hình không khớp đối với các nguồn do người dùng cấu hình. Các chợ OpenAI do Codex quản lý vẫn khả dụng khi nguồn và tên dành riêng của chúng khớp. Các yêu cầu không lọc những chợ người dùng đã được cấu hình hoặc plugin của chúng trong thời gian chạy.

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

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

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

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 đảm bảo 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ộ 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 (lớp ở trên ghi đè lớp ở 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 đè --config key=value của CLI á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 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ộ.

Các yêu cầu được quản lý trên đám mây ảnh hưởng đến lớp yêu cầu (không phải giá trị mặc định được quản lý). Hãy xem phần Yêu cầu do quản trị viên thực thi ở trên để biết thứ tự ưu tiên.

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 tải trọng 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 tải trọng "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 được mô tả ở trên. Cùng bảng [features] phía yêu cầu hoạt động trong requirements_toml_base64; 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 theo các tải trọng MDM macOS tiêu chuẩn, vì vậy bạn có thể phân phối cài đặt bằng các công cụ như Jamf Pro, Fleet hoặc Kandji. Một quy trình triển khai gọn nhẹ như sau:

  1. Tạo tải trọng 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 dưới 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 ứng dụng cục bộ được hỗ trợ và xác nhận rằng bản tóm tắt cấu hình 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 tải trọng được quản lý; ứng dụng đọ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 tải trọng. 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.

managed_config.toml mẫu

# 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

Biện pháp bảo vệ được khuyến nghị

  • Ưu tiên workspace-write cùng cơ chế phê duyệt cho hầu hết người dùng; chỉ dành quyền truy cập đầy đủ cho các vùng chứa được kiểm soát.
  • Duy trì network_access = false trừ khi quá trình đánh giá bảo mật của bạn cho phép một trình thu thập hoặc các miền mà quy trình làm việc của bạn cần.
  • Dùng cấu hình được quản lý để cố định các cài đặt OTel (trình xuất, môi trường), nhưng duy trì 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 câu lệnh.
  • Định kỳ kiểm tra sự khác biệt 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ộ.