Phê duyệt tác vụ của agent và bảo mật

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

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

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

Sandbox và cơ chế phê duyệt

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

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

Codex sử dụng các chế độ sandbox khác nhau tùy theo nơi bạn chạy Codex:

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

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

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

Codex cũng có thể yêu cầu phê duyệt đối với các lệnh gọi công cụ của ứng dụng (connector) có khai báo tác dụng phụ, ngay cả khi hành động đó không phải là lệnh shell hay thay đổi tệp. Các lệnh gọi công cụ ứng dụng/MCP mang tính phá hủy luôn cần được phê duyệt khi công cụ khai báo chú thích phá hủy, ngay cả khi công cụ cũng khai báo các gợi ý khác (ví dụ: gợi ý chỉ đọc).

Quyền truy cập mạng

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

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

[sandbox_workspace_write]
network_access = true

Cách ly mạng

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

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

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

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

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

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

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

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

Chính sách mạng

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

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

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

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

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

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

Trước khi cho phép một tên máy chủ, Codex thực hiện bước kiểm tra phân loại DNS và IP trên cơ sở nỗ lực tối đa:

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

Nếu DNS độc hại nằm trong phạm vi rủi ro, hãy thực thi thêm biện pháp kiểm soát lưu lượng đi ra ở lớp thấp hơn.

Cài đặt nguy hiểm

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

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

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

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

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

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

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

Giá trị mặc định và khuyến nghị

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

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

Trong chính sách sandbox workspace-write mặc định, các thư mục gốc có thể ghi vẫn chứa những đường dẫn được bảo vệ:

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

Chạy mà không hiển thị lời nhắc phê duyệt

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

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

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

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

Tự động xem xét yêu cầu phê duyệt

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

approvals_reviewer = "user"

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

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

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

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

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

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

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

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

Các tổ hợp sandbox và phê duyệt thường dùng

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

Với --ask-for-approval untrusted, Codex chỉ tự động chạy các thao tác đọc được xác định là an toàn. Những lệnh có thể thay đổi trạng thái hoặc kích hoạt đường dẫn thực thi bên ngoài (ví dụ: thao tác Git phá hủy hoặc cờ đầu ra/ghi đè cấu hình của Git) cần được phê duyệt.

Cấu hình trong config.toml

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

# Always ask for approval mode
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

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

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

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

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

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

Kiểm thử sandbox cục bộ

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

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

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

Sandbox cấp hệ điều hành

Codex thực thi sandbox theo cách khác nhau tùy thuộc vào hệ điều hành:

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

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

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

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

Khi chạy nguyên bản trên Windows, hãy cấu hình chế độ sandbox nguyên bản trong config.toml:

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

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

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

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

Chạy Codex trong Dev Containers

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

Sử dụng ví dụ devcontainer bảo mật của Codex làm bản triển khai tham khảo. Ví dụ này cài đặt Codex, các công cụ phát triển phổ biến, bubblewrap và các biện pháp kiểm soát lưu lượng đi ra dựa trên tường lửa.

Bản triển khai tham khảo bao gồm:

• ảnh cơ sở Ubuntu 24.04 đã cài đặt Codex và các công cụ phát triển phổ biến;
• hồ sơ tường lửa dựa trên danh sách cho phép dành cho lưu lượng đi ra;
• cài đặt VS Code và đề xuất tiện ích mở rộng để mở lại workspace trong container;
• các mount lưu trữ lâu dài cho lịch sử lệnh và cấu hình Codex;
• bubblewrap, nhờ đó Codex vẫn có thể sử dụng sandbox Linux khi container cấp các khả năng cần thiết.

Để dùng thử:

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

Bạn cũng có thể khởi động container từ CLI:

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

Ví dụ gồm ba thành phần chính:

• .devcontainer/devcontainer.secure.json kiểm soát cài đặt, khả năng, mount, biến môi trường và tiện ích mở rộng VS Code của container.
• .devcontainer/Dockerfile.secure xác định ảnh dựa trên Ubuntu và các công cụ được cài đặt.
• .devcontainer/init-firewall.sh áp dụng chính sách mạng đi ra.

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

Bên trong container, hãy chọn một trong các chế độ sau:

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

Kiểm soát phiên bản

Codex hoạt động hiệu quả nhất với quy trình kiểm soát phiên bản:

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

Giám sát và phép đo từ xa

Codex hỗ trợ giám sát theo cơ chế chủ động tham gia qua OpenTelemetry (OTel), giúp các nhóm kiểm toán việc sử dụng, điều tra sự cố và đáp ứng yêu cầu tuân thủ mà không làm suy yếu các giá trị bảo mật cục bộ mặc định. Phép đo từ xa mặc định bị tắt; hãy bật tường minh trong cấu hình.

Tổng quan

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

Bật OTel (chủ động tham gia)

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

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

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

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

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

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

Danh mục sự kiện

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

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

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

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

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

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

OTel là tính năng tùy chọn, được thiết kế để bổ trợ chứ không thay thế các biện pháp bảo vệ bằng sandbox và phê duyệt nêu trên.

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

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