feat(hooks): add managed hooks#15937
Open
viyatb-oai wants to merge 9 commits intocodex/viyatb/hooks-trust-precedencefrom
Open
feat(hooks): add managed hooks#15937viyatb-oai wants to merge 9 commits intocodex/viyatb/hooks-trust-precedencefrom
viyatb-oai wants to merge 9 commits intocodex/viyatb/hooks-trust-precedencefrom
Conversation
viyatb-oai
changed the title
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
f29a621 to
a16d990
Compare
viyatb-oai
changed the base branch from
main
to
codex/viyatb/hooks-trust-precedence
Contributor
|
Thanks for this, looks very directionally correct and spec adherent -- will review again later when you think it's out of draft mode |
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
9401e5f to
f0f222a
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
a16d990 to
6c5ea83
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
f0f222a to
456697a
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
6c5ea83 to
b7976a4
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
456697a to
c564cda
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
b7976a4 to
4f8689d
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
c564cda to
647f61a
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
4f8689d to
36587f3
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
647f61a to
c22dec5
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
2 times, most recently
from
1a06341 to
85609af
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
15872f2 to
6b3ef89
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
85609af to
e00bbff
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
6b3ef89 to
d22f07a
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
e00bbff to
b7f9332
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hooks-trust-precedence
branch
from
d22f07a to
8110afa
Compare
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
2 times, most recently
from
50ae0cd to
513683c
Compare
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Codex <noreply@openai.com>
viyatb-oai
force-pushed
the
codex/viyatb/hook-safety-controls
branch
from
513683c to
5ab034b
Compare
Co-authored-by: Codex noreply@openai.com
…ai/codex into codex/viyatb/pr15937-p3
…ai/codex into codex/viyatb/pr15937-p3
Co-authored-by: Codex <noreply@openai.com>
…ai/codex into codex/viyatb/pr15937-p3
eternal-openai
added a commit
that referenced
this pull request
Apr 23, 2026
## Summary Support the existing hooks schema in inline TOML so hooks can be configured from both `config.toml` and enterprise-managed `requirements.toml` without requiring a separate `hooks.json` payload. This gives enterprise admins a way to ship managed hook policy through the existing requirements channel while still leaving script delivery to MDM or other device-management tooling, and it keeps `hooks.json` working unchanged for existing users. This also lays the groundwork for follow-on managed filtering work such as #15937, while continuing to respect project trust gating from #14718. It does **not** implement `allow_managed_hooks_only` itself. NOTE: yes, it's a bit unfortunate that the toml isn't formatted as closely as normal to our default styling. This is because we're trying to stay compatible with the spec for plugins/hooks that we'll need to support & the main usecase here is embedding into requirements.toml ## What changed - moved the shared hook serde model out of `codex-rs/hooks` into `codex-rs/config` so the same schema can power `hooks.json`, inline `config.toml` hooks, and managed `requirements.toml` hooks - added `hooks` support to both `ConfigToml` and `ConfigRequirementsToml`, including requirements-side `managed_dir` / `windows_managed_dir` - treated requirements-managed hooks as one constrained value via `Constrained`, so managed hook policy is merged atomically and cannot drift across requirement sources - updated hook discovery to load requirements-managed hooks first, then per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning when a single layer defines both representations - threaded managed hook metadata through discovered handlers and exposed requirements hooks in app-server responses, generated schemas, and `/debug-config` - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`, `codex-rs/core/src/config_loader/tests.rs`, and `codex-rs/core/tests/suite/hooks.rs` ## Testing - `cargo test -p codex-config` - `cargo test -p codex-hooks` - `cargo test -p codex-app-server config_api` ## Documentation Companion updates are needed in the developers website repo for: - the hooks guide - the config reference, sample, basic, and advanced pages - the enterprise managed configuration guide --------- Co-authored-by: Michael Bolin <mbolin@openai.com>
morozow
pushed a commit
to morozow/codex
that referenced
this pull request
Apr 23, 2026
## Summary Support the existing hooks schema in inline TOML so hooks can be configured from both `config.toml` and enterprise-managed `requirements.toml` without requiring a separate `hooks.json` payload. This gives enterprise admins a way to ship managed hook policy through the existing requirements channel while still leaving script delivery to MDM or other device-management tooling, and it keeps `hooks.json` working unchanged for existing users. This also lays the groundwork for follow-on managed filtering work such as openai#15937, while continuing to respect project trust gating from openai#14718. It does **not** implement `allow_managed_hooks_only` itself. NOTE: yes, it's a bit unfortunate that the toml isn't formatted as closely as normal to our default styling. This is because we're trying to stay compatible with the spec for plugins/hooks that we'll need to support & the main usecase here is embedding into requirements.toml ## What changed - moved the shared hook serde model out of `codex-rs/hooks` into `codex-rs/config` so the same schema can power `hooks.json`, inline `config.toml` hooks, and managed `requirements.toml` hooks - added `hooks` support to both `ConfigToml` and `ConfigRequirementsToml`, including requirements-side `managed_dir` / `windows_managed_dir` - treated requirements-managed hooks as one constrained value via `Constrained`, so managed hook policy is merged atomically and cannot drift across requirement sources - updated hook discovery to load requirements-managed hooks first, then per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning when a single layer defines both representations - threaded managed hook metadata through discovered handlers and exposed requirements hooks in app-server responses, generated schemas, and `/debug-config` - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`, `codex-rs/core/src/config_loader/tests.rs`, and `codex-rs/core/tests/suite/hooks.rs` ## Testing - `cargo test -p codex-config` - `cargo test -p codex-hooks` - `cargo test -p codex-app-server config_api` ## Documentation Companion updates are needed in the developers website repo for: - the hooks guide - the config reference, sample, basic, and advanced pages - the enterprise managed configuration guide --------- Co-authored-by: Michael Bolin <mbolin@openai.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a managed-policy control for lifecycle hooks and surfaces a startup warning when hooks are loaded.
Changes
allow_managed_hooks_only/allowManagedHooksOnlyto config requirements and app-server protocol surfaces.requirements.toml, MDM-managedrequirements_toml_base64, and cloud requirements; legacymanaged_config.tomlremains limited toapproval_policyandsandbox_mode.hooks.jsonfiles when the managed-only requirement is enabled.hooks.jsonfiles.docs/config.md.Why
Hooks are privileged by design and run outside the sandbox. This makes that behavior explicit at startup and gives admins a lockdown option that still allows managed hooks.