## Why
`request_permissions` paths and grants need to be evaluated against the selected executor environment, including its path convention, home directory, workspace roots, and temporary directories.
## What changed
- Resolve relative and home-relative permission paths using the executor context, reject mismatched path conventions and lossy paths, and support legacy `read` and `write` path lists.
- Move grant intersection into core so requested and granted permissions use the originating environment's sandbox context. Preserve deny entries conservatively when a special path cannot be resolved.
- Keep the full originating environment with pending permission requests so delayed responses are normalized against the same context.
## Testing
- Cover POSIX, Windows, UNC, relative, and home-relative path resolution and invalid path contexts.
- Verify end-to-end app-server grants are limited to the requested workspace scope and unresolved temporary-directory denies are preserved.
GitOrigin-RevId: 730a2aacd391262e92a6314f3a5b6c262e3dca10
## Why
Git root discovery is optional metadata work, but filesystem probes can block. They should not exhaust Tokio's blocking pool, delay runtime shutdown, or prevent later turns from observing repository changes.
## What changed
- Add a shared `GitRootDiscovery` service that coalesces concurrent lookups for the same working directory and limits probes across directories.
- Run probes on detached threads, retain in-flight work across caller cancellation, and discard completed results instead of caching them.
- Use the service for turn and memory metadata enrichment, abort unused turn enrichment when its state is dropped, and limit memory metadata waits to one second.
## Testing
Add coverage for probe sharing, capacity limits, cancellation, fresh discovery, runtime shutdown, memory timeouts, and repositories restored after startup prewarming.
GitOrigin-RevId: bca46fc263e7a12a2f69146d8a0b3e7c7e0846cb
## What changed
- Add the under-development `mcp_oauth_refresh_coordination` feature and pin its selected refresh mode to each MCP connection.
- Treat the refresh mode as part of OAuth connection identity so runtime and MCP configuration refreshes reconnect when the mode changes.
- Keep legacy refresh behavior in builds where coordination is unavailable and emit a warning when coordinated mode is selected.
## Testing
- Cover connection replacement when the feature is toggled through both runtime and MCP configuration refresh paths.
GitOrigin-RevId: 89596150f0338e6ede0e712badecea4450831766
## What changed
- Add `approvalsReviewer` to the experimental `turn/settings/update` API.
- Apply reviewer changes to subsequently captured steps and new background approval requests while preserving pending approvals and future-thread defaults.
- Allow reviewer-only updates without `step_model_switching`, while continuing to enforce managed reviewer restrictions and model-required auto review.
- Use an explicit live reviewer update for MCP approvals while retaining refreshed thread defaults for clients that have not set one.
## Testing
- Cover switching between user and automatic review during a live turn, future-turn isolation, and managed-authority rejection.
GitOrigin-RevId: e1216b09c6a7972c2c9eaf4955d8d57d60604ca1
## Why
Guardian review evidence must remain available after a compacted thread is resumed or forked, while rolled-back or parent-local evidence must not grant authorization in a different context.
## What changed
- Store the bounded, model-invisible Guardian transcript alongside compacted rollout history and restore it from the newest surviving checkpoint during replay.
- Trim Guardian history at rollback boundaries, clearing it when the boundary has already been evicted.
- Preserve the checkpoint for user-initiated forks, but remove it when spawning a subagent so parent review evidence is not inherited.
- Keep the new rollout field optional for compatibility with existing compacted records and legacy readers.
## Testing
- Cover Guardian history across compaction, restart, paginated and pathless stores, user forks, rollback, bounded replay, serialization, and subagent forks.
GitOrigin-RevId: 6ab076d5e0c3aac4d6a41ebd50ba2b200c90213e
## Why
Realtime history should be recorded consistently for every Core host, including
when no app-server event listener is attached.
## What changed
- Move transcript segmentation, session boundaries, and backing-agent artifact
promotion into Core for paginated threads.
- Persist canonical realtime items through the thread store in event order and
emit dedicated history lifecycle events for hosts to present.
- Translate those Core events into the existing app-server realtime item
notifications without app-server persisting the items a second time.
## Testing
- Cover Core-only persistence across repeated sessions, ephemeral sessions,
accepted and rejected steering, typed input ordering, and artifact promotion.
- Verify app-server notifications correspond to the persisted timeline.
GitOrigin-RevId: 7cbef14129d77f6d6d7099b733be91f5279c55f5
## Why
Resumed threads need to continue per-turn and per-thread token totals without scanning arbitrarily far beyond the latest compaction checkpoint.
## What changed
- Add durable `TokenUsageRecord` rollout items with response, turn, thread, session, and root-turn attribution.
- Restore accumulated usage on resume and snapshot the latest record plus the compaction response ID in compaction checkpoints.
- Preserve root-turn lineage in persisted turn context, while ensuring forked child threads start with their own usage totals.
## Testing
- Cover usage accumulation across multiple responses and resumed turns.
- Cover local and remote compaction checkpoints, invalid remote compaction output, rollout reconstruction, and fork isolation.
GitOrigin-RevId: ef9e0c4a9102a08a2c382be4cdac68c84353c90a
## What changed
- Make `Session::spawn` return a `BoxFuture` while preserving lazy session
initialization.
- Prevent the startup wrapper from being inlined so callers do not expose its
concrete future.
- Await the returned future directly at session creation call sites.
GitOrigin-RevId: 5432745aae1c934b16202716a8d49a8553de2018
## What changed
- Add model metadata flags for enabling token budgeting and its history-notes extension.
- Apply those activation defaults once at thread startup when the user has not explicitly configured token budgeting, while respecting managed feature requirements.
- Continue resolving model-owned prompts for the active model so model switches can use their own token-budget guidance.
## Testing
- Update the token-budget integration test to verify that model metadata activates the feature without manual configuration.
GitOrigin-RevId: 73a32623eaeabb9243e240c43da7a5e7e93e9a19
## What changed
- Default `tools.update_plan.enabled` to `false`; users can explicitly enable it to expose `update_plan`.
- Remove bundled `update_plan` guidance from model, collaboration-mode, multi-agent, compaction, prewarm, and goal-continuation prompts when the tool is disabled.
- Preserve custom base instructions, model catalog instructions, collaboration policies, and user goal text even when they mention planning or `update_plan`.
## Testing
- Cover default and explicitly enabled tool registration, prompt consistency across request paths, and preservation of custom instructions.
GitOrigin-RevId: a53964e6e72f98e2557dd3090fdb7caccb956527
## Why
Compaction and host-injected context can rewrite the model-visible conversation
without changing what the user authorized. Treating those updates as authorization
changes prevents Guardian from reusing an otherwise valid review.
## What changed
- Track a host-owned user-message revision separately from the conversation history
generation.
- Advance the revision for genuine user messages and history resets, while preserving
it across compaction and internal context injection.
- Use message content-kind metadata to distinguish host context from user input,
conservatively treating unknown or incomplete metadata as user authorization.
## Testing
Added coverage that cached Guardian authorization survives compaction and internal
context, but is invalidated by user input and rollback.
GitOrigin-RevId: c7960fa182d1686042c23764d2abc58acbc4b882
## Why
Resuming a thread without an explicit `cwd` should restore that thread's latest
retained setting. Forked history can contain settings copied from another
thread, while compaction can move the latest setting outside the replay window.
## What changed
- Record the owning thread ID on new settings snapshots and only use snapshots
owned by the resumed thread when restoring `cwd`. Older snapshots without an
owner remain readable but do not override the startup `cwd`.
- Checkpoint the current settings after compaction and serialize checkpoints
with settings updates so the retained history contains an accepted, current
snapshot.
- Cover resume behavior across compaction, forks, reverts, legacy histories,
and concurrent settings updates.
GitOrigin-RevId: 1efc9cf55472d6b88c465c4efe44672a232dbf64
## What changed
- Add model message metadata for built-in tool descriptions.
- Use the active step model's catalog description for `send_user_message_async`, including after a mid-turn model change.
- Fall back to the built-in description when catalog metadata is absent, while preserving an explicitly empty description.
## Testing
- Cover catalog serialization, fallback and empty-value behavior, and model changes within a turn.
GitOrigin-RevId: 72b953214ab9708931065321debf12133f8d2d40
## What changed
- Store the most recently captured execution `StepContext` in the active turn state.
- Keep speculative model-fallback captures from replacing that context, and update it only when the fallback is selected for remote compaction.
- Preserve the retained context when a turn completes or is interrupted.
## Testing
- Add coverage for completed and interrupted turns, successful primary compaction, fallback compaction, and interruption while a fallback is running.
GitOrigin-RevId: c7dee36ec8e88ba2f4fb4a9c0322e5c86a0caf0e
## Why
Fetching plugin recommendations while building the first-turn context delays that
context when the recommendation catalog is not already cached.
## What changed
- Start fetching recommendations during session initialization, in parallel with
MCP and plugin setup, and reuse the in-flight request when building context.
- Centralize the feature checks that enable plugin recommendations.
- Prevent an invalidated recommendation request from repopulating the cache after
a newer request has completed.
## Testing
Added coverage for startup feature gating, reuse of the in-flight fetch, legacy
behavior when recommendations are unavailable, and cache invalidation races.
GitOrigin-RevId: 708774b9bfc472c9847973ae8b2774b66e7321e4
## What changed
- Share the root thread's current service tier across its agent tree.
- Apply that tier to each subagent request when the selected child model supports it, including remote compaction requests.
- Propagate root service-tier updates to existing and newly spawned subagents without rewriting child-owned settings.
- Remove per-spawn and role-level service-tier overrides so routing remains controlled by the root thread.
## Testing
- Cover supported and unsupported child models, full-history forks, live tier changes, remote compaction, new subagents, and reloaded subagents.
GitOrigin-RevId: 6c299e224e90b41a558788fb7aa4d5f336fa383a
## What changed
- Add `mcp_optional_startup_grace_ms` with a default of 1,000 ms to control how long tool catalog capture waits for optional MCP servers.
- Treat a value of `0` as disabling the shared grace, so optional servers use their configured `startup_timeout_sec` instead.
- Apply updated grace values during runtime and MCP configuration refreshes, and reset cached startup deadlines when the configured duration changes.
## Testing
- Cover custom, disabled, refreshed, and shared startup grace behavior in MCP connection and core integration tests.
GitOrigin-RevId: 936196215ed6e0a29c9ec72cfee17663978df8ef
## Why
Planning tools for a candidate model must not change the selected model or its
Responses Lite tool inventory. Otherwise, preparing a fallback can overwrite
metadata before the current model's request is sent.
## What changed
- Build tool registries and visible specs from an explicit `ModelInfo`.
- Store the finalized tool mode, code-mode names, namespace inventory, and
terminal and child-management capabilities on `ToolRouter`.
- Publish namespace inventory only after selecting the step's router, and use
that router's mode when dispatching and recording tool calls.
## Testing
Added coverage for candidate-model isolation, fallback compaction metadata,
code-mode worker selection, normalized tool names, and router capabilities.
GitOrigin-RevId: 56df2de8f42c7e93a4c4dcd117720e40a0cca3db
## Why
Model settings can change between steps in the same turn. Token-budget defaults,
context-window limits, and model-visible guidance need to stay aligned with the
model captured for each step.
## What changed
- Preserve the turn's original token-budget preferences and resolve model-owned
defaults when each `StepContext` is created.
- Use the step's model to determine context-window availability and token-budget
guidance, while keeping explicit user settings unchanged.
- Emit one-time replacement or removal notices when context-window guidance
changes, including compatibility with previously persisted world-state
snapshots.
- Add `ModelInfo::usable_context_window()` to distinguish reserved-headroom
capacity from the resolved context window and auto-compaction limit.
## Testing
- Cover mid-turn model switches with model defaults, explicit settings, config
reloads, missing context windows, and missing destination guidance.
- Cover unchanged, replaced, removed, blank, and legacy guidance transitions.
GitOrigin-RevId: 91100a9f3625bef8a79ecd158eb028051c309eee
## Why
Trusted Guardian reviewer sessions can emit events without an app-server listener, leaving their turns and tool usage absent from analytics.
## What changed
- Translate Guardian session lifecycle and canonical tool item events into analytics notifications while excluding messages, reasoning, and review content.
- Preserve Guardian lineage during prewarming even when inherited client metadata is not yet available, without emitting an incomplete thread initialization event.
- Limit direct session tracking to trusted Guardian children so resumed threads that have an app-server listener do not report duplicate events.
## Testing
- Cover completed, failed, and interrupted Guardian turns, tool counts and timing, lineage, content exclusion, prewarmed lineage, and resumed-thread deduplication.
GitOrigin-RevId: 70ace5f7ed30a7e3b6a9d6097c8b2a6a326dc4f7
## What changed
- Add the zero-based `window_number` to Responses turn metadata and include it in prewarm requests.
- Persist `forked_from_ordinal_exclusive` separately from the physical history base so fork lineage remains accurate after reverts and cold resumes.
- Report context-inheriting subagents through `parent_thread_id` without also emitting fork lineage.
- Reserve the new metadata keys while accepting and filtering previously valid configured values so Codex-owned values take precedence.
## Testing
- Cover window numbering across compaction, resume, and fork operations.
- Cover fork cutoff persistence across direct forks, legacy rollouts, reverts into inherited history, and cold resumes.
GitOrigin-RevId: 288f6cd632254814c1f166668b33828082d799a1
## What changed
- Add the `write_stdin_approval` feature flag, disabled by default, to require a fresh approval before sending non-empty input to an escalated unified-exec terminal.
- Route these reviews through hooks, Guardian, app-server, and the TUI as `writeStdin` approvals while keeping the parent command item unchanged.
- Preserve the terminal environment, launch directory, and escalation state across turns, and revalidate the process identity after approval before writing input.
## Testing
- Cover approval routing, policy decisions, process reuse, terminal identity preservation, app-server events, analytics, and TUI rendering.
GitOrigin-RevId: 4ba29eaae6208e934737ba078c96e589c7c2164d
## Why
Tool actions and approval retries can outlive the step that issued them. If approval handling reads newer turn settings, a delayed action can use the wrong approval policy or reviewer.
## What changed
- Capture the approval policy and reviewer in `GuardianReviewContext` from the issuing step.
- Use step settings for command, patch, permission, sandbox-retry, and remote-network approval decisions.
- Use the active task's published settings for background network approvals and long-lived Unix shell interception.
- Preserve explicit MCP reviewer overrides.
## Testing
Added regression coverage for permission requests, same-turn network policy changes, delayed commands after a new turn starts, sandbox retries, patch policy selection, and MCP reviewer overrides.
GitOrigin-RevId: b7e84a2e1e79a71502272b15b5ef5b0e5643f8b0
## What changed
Rename the `UserInstructions` type to `Instructions` across the extension API,
its core API re-export, and all consumers. This keeps loading behavior and the
`LoadedUserInstructions` provider interface unchanged.
GitOrigin-RevId: 1ac236b34c31718e7aa38ff5eae5e9b179aeedd8
## What changed
- Add the experimental `turn/start.cyberAccessProgram` option with `standard`,
`daybreakBlue`, and `daybreakRed` values.
- Forward the selection as `access_programs.cyber` on Responses, WebSocket,
and remote-compaction requests made with ChatGPT authentication, while
omitting it for API-key and custom-provider requests.
- Preserve the per-turn selection across recovery, compaction, and child-agent
turns without making it a persistent thread setting.
## Testing
- Cover app-server forwarding, authentication boundaries, WebSocket reuse,
turn recovery, compaction, and child-agent inheritance.
GitOrigin-RevId: d2eb468f365b2214c5099bc21741cf30f8bd2eb5
## What changed
- Add a feature-gated `TurnSettings` operation that can update the model,
reasoning effort, reasoning summary, and service tier for subsequent steps of
a named running turn without changing future thread settings.
- Report whether an update was applied, rejected, or lost its live target.
- Revalidate managed constraints and preserve the turn's admitted approval and
Guardian safety properties before publishing an updated settings snapshot.
## Testing
- Cover sparse updates, step capture and ordering, target replacement, managed
policy changes, model metadata safety, and separation from future settings.
GitOrigin-RevId: ecaaaa95b4fd4ec9d62265bef551582dddb36d78
## Why
Thread settings can change while a turn is running, and delegated review or
compaction steps can select a different model. Each request needs a consistent
set of settings resolved against the model that will execute it.
## What changed
- Capture immutable resolved settings for each model step, including model
metadata, reasoning options, service tier, approvals, and personality.
- Keep in-flight steps on their captured settings while applying thread updates
to subsequent work.
- Resolve inherited reasoning summaries and filter service tiers against the
selected model and feature configuration for review and compaction steps.
## Testing
Added coverage for settings updates during paused turns, model changes,
previous-model compaction, review-model defaults, and service-tier filtering.
GitOrigin-RevId: fca4b3b305379f1bf26a5cac75ee0dd1747ac1f6
## Why
Turn settings can change after an input request previews its overrides. Automatic idle work could therefore make a Plan-mode admission decision from stale settings or apply a sparse override built from an outdated collaboration mode.
## What changed
- Evaluate automatic turn admission against both the current and proposed configuration under the settings publication lock.
- Reject automatic work that would enter or leave Plan mode without committing settings or triggering runtime configuration effects.
- Keep model and reasoning-effort overrides sparse until they are merged with the configuration being committed.
- Continue allowing explicit user and recovery turns to make valid mode transitions.
## Testing
Add coverage for concurrent settings changes, sparse model and effort updates, commit-time constraint validation, atomic Plan-mode rejection, and subsequent explicit user submission.
GitOrigin-RevId: 234f06de116bdce7c3a3fb5cac3d15583304a253
## 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
## Why
Post-commit work can overlap with another settings write. Reading the session
again afterward could make a settings operation report or use the later state
instead of the state that it committed.
## What changed
- Return the committed configuration and `ThreadSettingsSnapshot` from session
settings updates.
- Use that commit result when creating a turn and emitting
`ThreadSettingsApplied`, while retaining current-state snapshots for
synthesized fork history.
- Route turn-start updates through the shared settings update path.
## Testing
Add coverage for standalone and turn-start updates that pause after committing,
restore different settings concurrently, and verify that each operation keeps
its original configuration and notification snapshot.
GitOrigin-RevId: cee5be9536d2840170893e6eb0c64cd039fb0a96
## What changed
- Add Windows sandbox mode, private-desktop behavior, and legacy Landlock selection to each `EnvironmentConfig`.
- Centralize sandbox context construction on `TurnEnvironment`, preserving environment-owned permissions, paths, and backend settings while applying additional permission grants.
- Use the environment-derived context for project instructions, capability discovery, file uploads, and filesystem-oriented tools.
## Testing
- Verify capability discovery uses the selected environment's permission profile and sandbox backends when they differ from the thread defaults.
GitOrigin-RevId: 7ae2fed90c8ada950f2e8431e571e9b2c793c291
## What changed
- Add a `ContextWindow` prompt slot for thread-scoped extension contributions.
- Include fragments in that slot in the token-budget context-window message.
- Keep the MCP `notes/thread_hint` bridge when the native history-notes extension is disabled, without falling back to it after a native request failure.
GitOrigin-RevId: befcb7cc8570b846094b2b542a112b186b39a30a
## What changed
- Add a `writeStdin` Guardian action carrying the approval, process, input, and working-directory details.
- Distinguish `command` and `writeStdin` execution approval requests while defaulting missing kinds to `command` for compatibility with older events.
- Render terminal-input review progress, denials, timeouts, and retry actions in the TUI, and record the action separately in analytics.
- Keep terminal-input reviews as child approvals so they do not change the parent command item's lifecycle or reconstructed history.
## Testing
- Cover Guardian serialization, app-server protocol conversion, command history reconstruction, analytics classification, and TUI review flows for terminal input.
GitOrigin-RevId: b083d5e2963bdd23b928644ec03c7eb68ebf2950
## Why
Internal Guardian reviews must remain independent of parent-session customization while still honoring managed execution and environment restrictions.
## What changed
- Apply the restricted Guardian session path to both internal and subagent review sources.
- Start internal reviews without inherited user instructions, extensions, MCP servers, or multi-agent behavior.
- Preserve managed execution policy and selected environment constraints while exposing only the allowed review tools. Honor shell feature restrictions across every selected environment and retain code mode when enabled.
## Testing
- Cover internal review isolation from parent state and managed instructions.
- Cover optional tool filtering, managed shell restrictions, code mode, and secondary environment profiles.
GitOrigin-RevId: edbf7d8a6fe3ee8213a1c75bc8ec331a1cf49006
## Why
Managed network requirements can remain present when `enabled = false`, but a
disabled configuration should not create or expose an active proxy runtime.
## What changed
- Start the managed network proxy only when its effective specification is
enabled.
- Clear an existing proxy when a permission-profile refresh disables managed
networking.
- Keep remote executor launches free of managed-network proxy settings when the
requirements explicitly disable the feature.
## Testing
Added session and unified-exec coverage for initial startup and refresh with
disabled managed networking.
GitOrigin-RevId: f76699802e079eb746d5b1ea6547d19a4bfb7715
## What changed
- Record the initiating agent path when inter-agent communication triggers a turn.
- Emit completed subagent activity to that agent's turn instead of always using the completed agent's parent thread.
- Keep parent-directed completion messages unchanged.
## Testing
Added a multi-agent v2 regression test where one sibling requests follow-up work from another and receives the resulting completion activity on the requesting turn.
GitOrigin-RevId: 949dd1116cccdd461c66a9b213a5bcd554cb3720
## Why
A Multi-Agent V2 child can finish after the parent turn that spawned it, so its
successful completion needs to remain associated with that parent turn in
notifications and history.
## What changed
- Add `completed` to `SubAgentActivityKind` and emit the corresponding started
and completed item events on the spawning parent turn when a child succeeds.
- Persist completed activity as a canonical turn item in both legacy and
paginated history, and expose it through app-server history and schemas.
- Render completed activity as terminal in the TUI without counting it as a
separate tool call or tool-runtime event.
## Testing
- Cover successful completion in legacy and paginated history, late updates to
completed parent turns, TUI rendering, analytics, and rollout tracing.
- Verify that terminal child errors do not emit completed activity.
GitOrigin-RevId: 6c71eb8b10e7327611c6af84f70e294e27d94d02
## What changed
- Add a `GuardianPolicy` contextual fragment that renders as a standalone
developer message with the `guardian.policy` content kind.
- Use the fragment when rebuilding Guardian context and verify that its content
kind remains attached after history compaction.
GitOrigin-RevId: f7028fb29a48ad2453437f3d3a4405fcab7a2fd7
## What changed
- Add a dedicated contextual fragment for developer instructions that emits the
`generic.developer_instructions` content kind.
- Use the fragment when adding child-specific developer instructions to a
full-history subagent fork, preserving their classification and ensuring they
reach the child exactly once without appearing in the parent request.
## Testing
- Extend full-history subagent coverage to verify the child-only instructions'
annotation, placement, and count.
GitOrigin-RevId: 82589d311535225fed76d500a19458fda72f40f2
## Why
Guardian reviews were reported with the generic `subagent` thread source, making them indistinguishable from other delegated threads in persisted metadata and analytics.
## What changed
- Add the `guardian_review` thread source to the core protocol and app-server schema.
- Assign it to Guardian reviewer sessions and propagate the configured source through turn metadata, rollouts, and analytics.
- Continue treating Guardian reviews like subagents for paginated history and trusted-provenance checks.
## Testing
- Cover protocol round trips, delegate source selection, emitted analytics, request metadata, and persisted rollout metadata.
GitOrigin-RevId: 07480c122715812874c9d3b48bb39fc5c86b2367
## What changed
- Preserve each contextual fragment's `ContentItemKind` when converting it to a response message.
- Classify user text, image, and audio content as `user.text`, `user.image`, and `user.audio` in their original order.
- Give additional context key-specific `additional_content.<key>` kinds and retain annotations on generated messages such as image resize notices and interrupted-turn markers.
## Testing
- Expand request-level coverage to verify content-kind annotations across mixed-modality turns, additional context, reminders, budgets, skills, model switching, subagents, and image resizing.
GitOrigin-RevId: 671e4545f39b335525c60d2a5df4608e8068cafc
## What changed
- Carry each contextual fragment's `ContentItemKind` through initial context assembly and world-state updates.
- Attach the classifications to merged response messages through `content_item_kinds`, preserving their order alongside the message content.
- Convert extension prompt fragments into annotated developer fragments and classify built-in developer and guardian instructions.
## Testing
- Add an integration test covering roles and content annotations in the first request.
- Update world-state and persisted-history tests to account for annotation metadata.
GitOrigin-RevId: 71c48dad5b17bffd47ba03263e3eb6d5e74fbf4b
## What changed
- Require each `PromptFragment` to include a producer-owned `ContentItemKind`.
- Re-export `ContentItemKind` from `codex_extension_api` and assign stable kinds to skills, memories, examples, and test contributors.
- Limit prompt slots to developer policy and developer capabilities, and combine contributed fragments into a single developer update.
## Testing
- Update extension registry tests to verify fragment ordering with the new content-kind metadata.
GitOrigin-RevId: ef8624a9b4ae9dce025bca9c0954d91dd8075e85
## Why
An active root turn needs to be stopped without marking it complete or aborted
before another runtime can recover the same turn ID.
## What changed
- Add `CodexThread::suspend_turn_and_shutdown` and `SuspendTurnOutcome`.
- Flush history, stop the active regular task, close the history writer, and
shut down the session without recording a terminal turn event.
- Reject suspension when no supported turn is active or the loaded agent
subtree still contains a live descendant.
## Testing
- Verify that suspension preserves unfinished history and allows the turn to be
recovered under its original ID after the descendant guard is cleared.
GitOrigin-RevId: 1f9b019d07c51474ec2d991d263bc15cdd4f89ad
## What changed
Propagate tool cancellation tokens into Guardian approval reviews so interrupting a tool also aborts its pending review. Apply the same cancellation behavior to server-initiated MCP approval elicitation.
## Testing
Add integration coverage for cancellation from direct tool calls, code-mode turns, background code-mode cells, and MCP elicitation.
GitOrigin-RevId: cbee4b422bbcbf6984e415ef6409cee705beebdc
## What changed
- Scope executor-provided stop-hook calls to the MCP server environment that registered the hook, and reject calls when that environment does not match.
- Forward turn metadata with executor stop-hook requests while retaining the hook call's `threadId` metadata.
## Testing
- Cover environment matching for MCP tool calls and verify executor stop hooks receive their environment ID and request metadata.
GitOrigin-RevId: b544ea3a6ca1f61389fb4597978ed7aac27d529a
## What changed
- Add `context_window_id` to turn metadata for sampling and compaction requests, using the UUID for the model-visible context window.
- Keep the ID stable for requests in the same context window and advance it after compaction, independently of the existing thread-generation `window_id`.
- Reserve `context_window_id` so client metadata cannot override it.
## Testing
- Cover HTTP and WebSocket metadata, remote compaction, token-budget context alignment, resume behavior, and post-compaction window changes.
GitOrigin-RevId: 55cceea377ad509c8dd96ad668f2b5703ea46a63
## What changed
- Skip project-scoped `AGENTS.md` discovery when the active project is untrusted, while preserving user-level instructions.
- Include the active project trust level in the instruction cache key so runtime trust changes reload the applicable instructions.
- Preserve updated project trust metadata during runtime configuration refreshes.
## Testing
Add coverage for initially untrusted projects and for switching between trusted and untrusted states at runtime.
GitOrigin-RevId: 284bf7693943f585013fb5fe4b6aa3309bc50cf3
## What changed
- Treat standalone `function_call_output` items without a `call_id` as external context, including items injected into new and forked threads, and mark the thread memory mode polluted when `memories.disable_on_external_context` is enabled.
- Include these outputs in guardian transcripts with their namespaced tool name and a placeholder for non-text content.
- Allow image generation to reuse images from standalone and otherwise unpaired function or custom-tool outputs.
## Testing
- Cover injected thread items, external-context detection, guardian transcript rendering, and recent-image selection.
GitOrigin-RevId: ca4e8c16a4b731e1256a5956908d00f785b4feb1
## What changed
- Add `additional_developer_instructions` to managed requirements and expose it through `configRequirements/read` as `additionalDeveloperInstructions`, independently of ordinary developer instructions.
- Include the managed instructions in model context, emit explicit replacement or removal messages when requirements change, and preserve the current value across compaction, resume, and agent forks without duplication.
- Reject managed instructions whose rendered context exceeds 10,000 estimated tokens.
## Testing
- Cover requirements layering and API serialization, context updates and removal, size validation, repeated model requests, compaction and resume, rollout migration, and agent forks.
GitOrigin-RevId: bc0b70fb7988944c2f68176dff55f5ed61eb46c8
iceweasel-oai