mirror of https://github.com/pchuan98/codex.git synced 2026-07-01 00:31:56 +08:00

Files

T

gt-oai 9352c6b235 feat: Constrain values for approval_policy (#7778 )

Constrain `approval_policy` through new `admin_policy` config.

This PR will:
1. Add a `admin_policy` section to config, with a single field (for now)
`allowed_approval_policies`. This list constrains the set of
user-settable `approval_policy`s.
2. Introduce a new `Constrained<T>` type, which combines a current value
and a validator function. The validator function ensures disallowed
values are not set.
3. Change the type of `approval_policy` on `Config` and
`SessionConfiguration` from `AskForApproval` to
`Constrained<AskForApproval>`. The validator function is set by the
values passed into `allowed_approval_policies`.
4. `GenericDisplayRow`: add a `disabled_reason: Option<String>`. When
set, it disables selection of the value and indicates as such in the
menu. This also makes it unselectable with arrow keys or numbers. This
is used in the `/approvals` menu.

Follow ups are:
1. Do the same thing to `sandbox_policy`.
2. Propagate the allowed set of values through app-server for the
extension (though already this should prevent app-server from setting
this values, it's just that we want to disable UI elements that are
unsettable).

Happy to split this PR up if you prefer, into the logical numbered areas
above. Especially if there are parts we want to gavel on separately
(e.g. admin_policy).

Disabled full access:
<img width="1680" height="380" alt="image"
src="https://github.com/user-attachments/assets/1fb61c8c-1fcb-4dc4-8355-2293edb52ba0"
/>

Disabled `--yolo` on startup:
<img width="749" height="76" alt="image"
src="https://github.com/user-attachments/assets/0a1211a0-6eb1-40d6-a1d7-439c41e94ddb"
/>

CODEX-4087

9352c6b235 · 2025-12-17 16:19:27 +00:00

History

src

feat: Constrain values for approval_policy (#7778 )

2025-12-17 16:19:27 +00:00

templates

Removed experimental "command risk assessment" feature (#7799 )

2025-12-10 09:48:11 -08:00

tests

feat: Constrain values for approval_policy (#7778 )

2025-12-17 16:19:27 +00:00

Cargo.toml

[codex] add otel tracing (#7844 )

2025-12-12 17:07:17 -08:00

gpt_5_1_prompt.md

chore(prompt) Remove truncation details (#7941 )

2025-12-12 20:21:53 +00:00

gpt_5_2_prompt.md

chore(prompt) Remove truncation details (#7941 )

2025-12-12 20:21:53 +00:00

gpt_5_codex_prompt.md

refactoring with_escalated_permissions to use SandboxPermissions instead (#7750 )

2025-12-10 17:18:48 +00:00

gpt-5.1-codex-max_prompt.md

refactoring with_escalated_permissions to use SandboxPermissions instead (#7750 )

2025-12-10 17:18:48 +00:00

prompt.md

chore(prompt) Update base prompt (#7943 )

2025-12-12 20:50:49 +00:00

README.md

docs: align sandbox defaults, dedupe sections and improve getting started guide (#5357 )

2025-10-19 16:41:10 -07:00

review_prompt.md

docs: Fix markdown list item spacing in codex-rs/core/review_prompt.md (#4144 )

2025-10-30 17:39:21 -07:00

README.md

codex-core

This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.

Dependencies

Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:

macOS

Expects /usr/bin/sandbox-exec to be present.

Linux

Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.

All Platforms

Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.