v11.0.0

What's Changed

Breaking Changes

• The generated Codex CLI [permissions.rulesync] profile now always emits an extends baseline, defaulting to ":workspace" when codexcli.base_permission_profile is unspecified. Previously, extends = ":workspace" was emitted only when a workspace-wide write rule (., ./, **, ./**) was present, so regenerating with an existing permissions.json can broaden the profile's grants — rulesync warns when regeneration replaces or newly introduces the extends value on an existing profile. Set codexcli.base_permission_profile to ":read-only" to keep a read-only baseline. by @dyoshikawa in #2267
• Codex CLI generation now pins approval_policy = "on-request" and approvals_reviewer = "auto_review" as defaults when neither the codexcli override nor the existing .codex/config.toml sets them. Existing user-set values are never overwritten. by @dyoshikawa in #2267
• On import, a Codex profile's extends = ":workspace" is no longer synthesized into an edit: { ".": "allow" } rule; it now round-trips into codexcli.base_permission_profile instead. Other tools generated from the same imported permissions.json no longer receive the synthesized workspace-wide edit allow. by @dyoshikawa in #2267

Features

• Add codexcli.base_permission_profile permissions override (":read-only" | ":workspace"), emitted as the managed profile's extends baseline in .codex/config.toml. ":danger-full-access" is rejected because Codex's extends refuses it at config load time. by @dyoshikawa in #2267

Deprecations

• codexcli.sandbox_mode and codexcli.sandbox_workspace_write are deprecated: Codex prioritizes the legacy sandbox settings over permission profiles when both are present, so authoring them disables the generated rulesync permissions profile. They still emit (with a warning) so existing configs round-trip; use codexcli.base_permission_profile and the shared permission block instead. by @dyoshikawa in #2267

Contributors

• @dyoshikawa

Full Changelog: v10.1.0...v11.0.0