## What changed
Add optional `request_permissions` and `auto_review_suffix` fields to catalog approval messages. Use them to customize the permission tool heading and introduce automatic review guidance while preserving the bundled instruction bodies and existing policy gates. Accept `request_permissions_tool` as a deserialization alias.
Limit headings to 500 UTF-8 bytes on a single line and fall back to bundled text for missing or invalid values. Complete catalog approval messages retain precedence.
## Testing
Add coverage for heading validation, serialization aliases, policy gates, fallback behavior, and complete-message precedence. Integration tests verify that model switches append the selected model's headings without rewriting history or repeating unchanged instructions.
GitOrigin-RevId: 3311591a464cc086783fe25271a352dd5a229790
## What changed
Add optional `approvals.granular` catalog fields for the policy introduction and prompted and rejected category lists. Preserve template strings verbatim in `GranularApprovalMessages`, leaving validation and rendering to consumers.
Document the 500-byte template limit, required `{{ policy }}` and `{{ categories }}` markers, and fallback rules.
## Testing
Extend serialization tests to cover null, empty, and populated granular templates, and verify their preservation through model responses and base instruction overrides.
GitOrigin-RevId: ce32e41a9b37e2e7c45ac9b079708a640c99326c
## What changed
Add optional `writable_root` and `writable_roots` templates to model-catalog permission messages. Select the template by the number of displayed roots and substitute exactly one `{{ roots }}` placeholder with the existing formatted path list.
Fall back to the bundled sentence for missing, empty, invalid, or oversized templates. Preserve path contents, permission-path limits, and denied-read instructions. Update the permission wording when the selected model changes.
## Testing
Add coverage for template validation and size limits, singular/plural selection after path truncation, path preservation, sparse serialization, and model switches that append changed permissions once while preserving request history.
GitOrigin-RevId: 4dcfb7ff70b91db3dba3dda684b355b920e07974
## What changed
Add `approved_prefixes` to catalog permission messages, with `{{ approved_prefixes }}` substitution for the approved command list. An empty template suppresses the section; missing or null values retain the bundled template.
For `on-request` approvals, append an explicitly supplied prefix template even when the catalog also supplies approval instructions. Use the template for bundled `on-request` and granular approval instructions as well.
## Testing
Extend the remote model catalog integration test to cover custom prefix rendering alongside catalog approval instructions and suppression with an empty template.
GitOrigin-RevId: 82dd6f83caa56cab0a2f6343bf912efe2cb97d64
## Why
Clients starting delegated work need to attribute descendant turns to the original turn and retain that attribution through completion and history reads.
## What changed
- Accept optional `parentTurnId` and `rootTurnId` in `turn/start`, and expose `rootTurnId` on returned turns and lifecycle notifications.
- Default new turns to their own root when none is supplied. Preserve the active turn's root when steering, ignoring incoming lineage fields.
- Carry root IDs through completion, interruption, recovery, and fork boundaries, and persist them for paginated history reads. Leave unknown roots null in older history.
- Update protocol schemas and generated TypeScript and Python bindings.
## Testing
Extend coverage for default and explicit roots, steering without changing lineage, interrupted and recovered turns, history reads after restart in both history modes, nested fork pagination, and compatibility with older database writers.
GitOrigin-RevId: f1a570a12bd11742929fd2e8b017e5d35aa07dcb
## Why
Callers need to await acceptance or rejection of thread settings without consuming the thread event stream. Acceptance must precede event delivery because the caller may hold a lock needed by the event consumer.
## What changed
- Add `CodexThread::update_thread_settings` and re-export `ThreadSettingsOverrides` from `core-api`.
- Add an optional reply channel to `Op::ThreadSettings`. Return validation failures as `InvalidRequest` through that channel, retaining error events for callers without a reply channel.
- Reply to successful updates before emitting `ThreadSettingsApplied`, while holding the settings persistence lock through notification.
## Testing
Extend settings constraint coverage to direct replies, including rejection without an error event and successful notification. Verify that acceptance and continuation invalidation precede blocked event delivery, while checkpointing waits for notification.
GitOrigin-RevId: e09b0d3cc4b6750709c173371632f19619e5c250
## Why
Model requirements must be evaluated against the permissions that will apply
after a settings update. Validating against the current profile can reject a
valid model-and-permission update or allow a later permission-only update to
invalidate the selected model.
## What changed
- Group model, reasoning, service-tier, personality, and approval inputs into
`StepSettings`, with a single apply-and-validate path.
- Apply permission and environment changes before validating step settings, so
auto-review requirements use the proposed effective permissions.
- Revalidate existing step settings when permission or environment changes alter
their constraints, and commit the update only when the complete candidate is
valid.
## Testing
Added unit and integration coverage for atomic model/permission updates,
permission-only revalidation, environment-derived constraints, and both
standalone and turn-start settings operations.
GitOrigin-RevId: f50dfbd300484a09acc51ee4607278f300ca1cd9