mirror of https://github.com/openai/codex.git synced 2026-05-22 20:14:17 +00:00

Files

viyatb-oai fe7c069fe6 feat(permissions): resolve permission profile inheritance (#22270 )

## Stack

This is the foundation PR for the permission-profile inheritance stack.

- This PR adds config-level `extends` resolution and merge semantics.
- Follow-up: #23705 applies resolved profiles at runtime and updates the
active-profile protocol surfaces.

## Why

Permission profiles are starting to carry enough policy that
copy-pasting near-identical definitions becomes hard to review and easy
to drift. Before the runtime can consume inherited profiles, the config
layer needs one explicit resolver that can merge parent chains and
reject unsafe or invalid inheritance shapes.

## What changed

- Add `extends` to permission-profile TOML and resolve parent chains in
inheritance order.
- Merge inherited profile TOML with the existing config merge behavior
while preserving the permission-specific normalization needed for
network domain keys.
- Keep parent descriptions out of resolved child profiles and record
inherited profile names separately for downstream consumers.
- Reject undefined parents, unsupported built-in parents, and
inheritance cycles with targeted errors.
- Cover resolver behavior with TOML fixture tests and refresh the
generated config schema.

## Validation

- `cargo test -p codex-config`
- `cargo test -p codex-core permissions_profiles_`

2026-05-20 20:12:07 +00:00

src

feat(permissions): resolve permission profile inheritance (#22270 )

2026-05-20 20:12:07 +00:00

BUILD.bazel

fix(core) Preserve base_instructions in SessionMeta (#9427 )

2026-01-19 21:59:36 -08:00

Cargo.toml

Enable --deny-warnings for cargo shear (#21616 )

2026-05-08 20:29:00 +00:00

README.md

fix: separate codex mcp into codex mcp-server and codex app-server (#4471 )

2025-09-30 07:06:18 +00:00

README.md

codex-protocol

This crate defines the "types" for the protocol used by Codex CLI, which includes both "internal types" for communication between codex-core and codex-tui, as well as "external types" used with codex app-server.

This crate should have minimal dependencies.

Ideally, we should avoid "material business logic" in this crate, as we can always introduce Ext-style traits to add functionality to types in other crates.