## Why
An inherited turn can suppress a fork's configured developer instructions, leaving the first side-chat request without its developer policy.
## What changed
- Move shared side-conversation instructions and the history boundary into `codex-context-fragments`.
- Inject the developer policy before the user-role boundary when creating a TUI side-chat fork, while retaining the configured instructions.
- Distinguish attached and temporary policies, applying the worktree restriction only to temporary side chats.
- Add guidance to set up recurring monitors in the main chat or a new chat because temporary side chats cannot run scheduled updates.
## Testing
Add a TUI integration test that checks the first side-chat model request contains the policy and boundary. Add a core request-history snapshot covering an attached side chat that preserves inherited context, policy, and its prior answer after resuming from disk.
GitOrigin-RevId: 889cb317dc3327457cd9ef0879ec9f77dbfaeeba
## What changed
Add `codex.additional_context` to count submitted entries, including unchanged entries, and `codex.additional_context.value_bytes` to measure UTF-8 value sizes before and after the existing truncation limit. Sizes exclude message wrappers and include the truncation marker after truncation.
Tag metrics with context kind, truncation status, and an explicitly supplied name when present; never use opaque source keys as tags. Record metrics through the current turn's telemetry.
## Testing
Add integration coverage for message and tool-output formats, repeated submissions, truncation boundaries, empty and multibyte values, optional name tags, and turn-specific model attribution.
GitOrigin-RevId: 463f257af27be58c372970fac853b85fde495dd5
## What changed
When `features.untrusted_as_tool_output` is enabled, emit untrusted additional context as `function_call_output` items in the `agent` namespace before user input. Use the explicit context name when supplied; otherwise derive a bounded name from the source key, falling back to `untrusted_content`.
Deduplicate these outputs by name and truncated value so name changes are emitted while changes confined to truncated content are ignored. Application context remains in developer messages, and disabling the feature preserves the existing message format.
## Testing
Extend core and app-server tests and add request-history snapshots covering both formats, turn start and steering, derived names, truncation, and deduplication.
GitOrigin-RevId: cd5e2f4b3121714acb7f4baf5607f3c27d408cae
## What changed
Replace duplicated content-kind strings with constants shared by fragment producers and consumers, including authorization checks, forked-history filtering, and memory instructions. Share the compaction summary kind between core and Guardian's transcript filter.
## Testing
Add a regression test verifying that Guardian excludes compaction summaries while retaining surrounding user messages, including a user message with identical text.
GitOrigin-RevId: 36dbdf0f82c61b52d2571ac1c392fb151c98151b
## Why
Message roles and content classifications do not identify who supplied each context part. Source attribution needs to survive prompt assembly and history truncation, including messages that combine text from different producers.
## What changed
- Add per-part `ContentItemMetadata` for user input, developer instructions, `AGENTS.md`, skills, harness context, command hooks, and tool context with optional callable namespaces.
- Carry attribution alongside content and classifications through contextual fragments, extension prompts, hook output, and agent messages. Keep tool-provided context-window hints separate from harness text.
- Preserve the source of retained text slices during compaction and attribute generated truncation notices to the harness. Default missing historical attribution to unknown.
- Attribute host MCP calls using cached tool namespaces only when catalog revisions remain stable, without starting servers or refreshing catalogs for attribution.
- Send the new metadata to Responses Lite and strip it from requests to endpoints that do not support it.
## Testing
Extend compaction tests to cover mixed sources, missing or extra metadata entries, and discarded media. Update Responses Lite request assertions to verify endpoint-specific attribution handling.
GitOrigin-RevId: b0ebc929b7c60f3ec49d1affbf897312d63edcc8
## What changed
- Remove `ContentItemMetadata`, provenance and namespace types, and the `content_item_metadata` protocol field while retaining `content_item_kinds` classifications.
- Simplify context fragments, extension contributions, and hook output to carry content without source attribution. Return MCP tool results directly without an attribution wrapper.
- Render context-window hints together in a single text fragment.
## Testing
Update Responses and Responses Lite request assertions to expect content-kind classifications without per-content attribution, and adapt context, hook, and extension tests to the simplified types.
GitOrigin-RevId: 201894cd4c93c6d4b4c41c845e7a9af1dd3c95ca
## What changed
- Add `ContentItemMetadata` to distinguish user input, developer instructions, `AGENTS.md`, skills, harness context, and tool-supplied context independently of message role and content classification.
- Keep attribution attached to content through prompt assembly, history processing, and hook-output spilling. Distinguish command hooks from MCP hooks and retain tool namespaces when known.
- Treat missing historical attribution as unknown and send per-content metadata only to Responses Lite.
## Testing
Update request and history assertions to cover attribution persistence and Responses Lite metadata handling.
GitOrigin-RevId: 24e56005f5bdb98bf82f2b3943f29c4c81f3d587
## Why
The 900-byte recap prompt limit leaves little room for completed progress, unresolved caveats, and recent corrections. Recaps need this context to distinguish completed work from pending requests.
## What changed
- Introduce a shared `RecapPrompt` with a 32 KiB ceiling for instructions and history, using an 8,192-token estimate. Instruct summaries to retain the broader goal, completed outcomes, and unresolved availability or validation caveats.
- Select up to eight answered exchanges plus a pending request, preserving adjacent steering and progress messages. Drop older whole exchanges before excerpting both ends of oversized messages, while retaining the newest answer and pending correction.
- Require a `summary` and nullable `next_action`, bounded to 700 and 200 characters respectively. Reject malformed or oversized responses and display an optional, separately styled `Next:` line.
## Testing
Add coverage for UTF-8 prompt bounds, exchange selection, pending corrections, excerpt boundaries, strict response parsing, and next-action rendering. Extend the recap generation integration test to verify bounded history and the structured response schema.
GitOrigin-RevId: 6c6a84bc602a168418c1952feb1d286ec0cb9e28
## What changed
- Introduce an async-question editor component with per-question drafts, navigation, replay deduplication, and submit or queue handling using the shared composer.
- Add bounded `AnsweredQuestion` framing that truncates question text at a UTF-8 boundary and flattens line breaks before prepending it to an answer.
- Add `prompt_stack_back` and `skip_question` keybinding actions and the `tui.question_esc_back` setting. Normalize `Ctrl+]` and `Ctrl+5` for key matching and conflict detection, and let default question shortcuts yield to explicit bindings.
- Flush buffered typing in both the main composer and the covering view so background input cannot keep the draw loop waiting.
The async-question component is not yet connected to the TUI event flow.
## Testing
Add regression coverage for bounded Unicode question framing, question-shortcut conflicts, and paste-buffer flushing in background and covering editors.
GitOrigin-RevId: 4098043cf588ddafc05c27505645495edd690cb9
## Why
Rebuilding a truncated message from its content fields can drop passthrough
metadata and leave positional content classifications out of sync with the
items that remain.
## What changed
- Convert message content and its classifications into `AnnotatedContent`
before applying the token budget, then write both back together.
- Preserve other message and envelope metadata during truncation.
- Assign the `unknown` classification to content from legacy messages that do
not provide classifications.
## Testing
Expanded truncation coverage to verify that retained text and image items keep
their matching classifications and that unrelated passthrough metadata is
preserved.
GitOrigin-RevId: f84e2ebc3e97392e45f321dec3c171713864bdcd
## What changed
- Require each `ContextualUserFragment` to provide a stable `<feature>.<name>`
`ContentItemKind`.
- Add `AnnotatedContent` and `RenderedFragment` so rendered text, its role, and
its classification can travel together to API boundaries.
- Derive extension-owned world-state classifications from the extension ID and
keep the skills catalog classification with its fragment implementation.
## Testing
- Verify that an extension-owned world-state section renders with an
`<extension-id>.instructions` content kind.
GitOrigin-RevId: e46b74a0bb41e0b6112667c9d36bc9e7f2714451
## What changed
Replace the type-erased `FragmentRegistration` trait and proxy objects with a
static list of `matches_text` function pointers. Remove the registration types
and their re-exports while preserving the existing contextual fragment matchers.
GitOrigin-RevId: 4e5a296b278984c6e783a67f48fa4bb37646946b
## Why
`codex-core` currently owns the generic contextual-fragment trait and
several reusable fragment implementations. That makes it harder for
other crates to share the same host-owned model-input abstraction
without depending on all of `codex-core`.
This change extracts the reusable fragment machinery into a small
`codex-context-fragments` crate so future extension and skills work can
depend on the fragment abstraction directly.
## What Changed
- Added the `codex-context-fragments` crate with:
- `ContextualUserFragment`
- `FragmentRegistration` / `FragmentRegistrationProxy`
- additional-context fragment types
- Moved `SkillInstructions` into `codex-core-skills`, since
skill-specific rendering belongs with skills rather than generic core
context machinery.
- Kept `codex-core` re-exporting the fragment types it still uses
internally, so existing call sites keep the same shape.
- Updated Cargo and Bazel workspace metadata for the new crate.
## Verification
- `cargo metadata --locked --format-version 1 --no-deps`
- `just bazel-lock-update`
- `just bazel-lock-check`
Felipe Coury