19 Commits

• Preserve image detail in app-server inputs (#20693)

  ## Summary
  
  - Add optional image detail to user image inputs across core, app-server
  v2, thread history/event mapping, and the generated app-server
  schemas/types.
  - Preserve requested detail when serializing Responses image inputs:
  omitted detail stays on the existing `high` default, while explicit
  `original` keeps local images on the original-resolution path.
  - Support `high`/`original` consistently for tool image outputs,
  including MCP `codex/imageDetail`, code-mode image helpers, and
  `view_image`.

  Curtis 'Fjord' Hawthorne · 2026-05-15 15:04:04 -07:00
  8543e39885
• [codex] Use compaction_trigger item for remote compaction v2 (#22809)

  ## Why
  
  Remote compaction v2 was still using `context_compaction` as both the
  request trigger and the compacted output shape. The Responses API now
  has the landed contract for this flow: Codex sends a dedicated `{
  "type": "compaction_trigger" }` input item, and the backend returns the
  standard `compaction` output item with encrypted content.
  
  This aligns the v2 path with that wire contract while preserving the
  existing local compacted-history post-processing behavior.
  
  ## What changed
  
  - Add `ResponseItem::CompactionTrigger` and regenerate the app-server
  protocol schema fixtures.
  - Send `compaction_trigger` from `remote_compaction_v2` instead of a
  payload-less `context_compaction`.
  - Collect exactly one backend `compaction` output item, then reuse the
  existing compacted-history rebuilding path.
  - Treat the trigger item as a transient request marker rather than model
  output or persisted rollout/memory content.
  
  ## Verification
  
  - `cargo test -p codex-protocol compaction_trigger`
  - `cargo test -p codex-core remote_compact_v2`
  - `cargo test -p codex-core compact_remote_v2`
  - `cargo test -p codex-core
  responses_websocket_sends_response_processed_after_remote_compaction_v2`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol schema_fixtures`

  jif-oai · 2026-05-15 11:40:35 +02:00
  0322ac3df8
• feat: add remote compaction v2 Responses client path (#20773)

  ## Why
  
  This adds the `remote_compaction_v2` client path so remote compaction
  can run through the normal Responses stream and install a
  `context_compaction` item that trigger a compaction.
  
  The goal is to migrate some of the compaction logic on the client side
  
  We keeps the v2 transport behind a feature flag while letting follow-up
  requests reuse the compacted context instead of falling back to the
  legacy compaction item shape.
  
  ## What changed
  
  - add `ResponseItem::ContextCompaction` and refresh the generated
  app-server / schema / TypeScript fixtures that expose response items on
  the wire
  - add `core/src/compact_remote_v2.rs` to send compaction through the
  standard streamed Responses client, require exactly one
  `context_compaction` output item, and install that item into compacted
  history
  - route manual compact and auto-compaction through the v2 path when
  `remote_compaction_v2` is enabled, while keeping the existing remote
  compaction path as the fallback
  - preserve the new item type across history retention, follow-up request
  construction, telemetry, rollout persistence, and rollout-trace
  normalization
  - add targeted coverage for the feature flag, `context_compaction`
  serialization, rollout-trace normalization, and remote-compaction
  follow-up behavior
  
  ## Verification
  
  - added protocol tests for `context_compaction`
  serialization/deserialization in `protocol/src/models.rs`
  - added rollout-trace coverage for `context_compaction` normalization in
  `rollout-trace/src/reducer/conversation_tests.rs`
  - added remote compaction integration coverage for v2 follow-up reuse
  and mixed compaction output streams in
  `core/tests/suite/compact_remote.rs`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-04 14:15:01 +02:00
  d927f61208
• Remove ghost snapshots (#19481)

  ## Summary
  - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
  and generated SDK/schema artifacts.
  - Keep legacy config loading compatible, but make undo a no-op that
  reports the feature is unavailable.
  - Clean up core history, compaction, telemetry, rollout, and tests to
  stop carrying ghost snapshot items.
  
  ## Testing
  - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
  compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
  - Regenerated config and app-server schemas plus Python SDK artifacts
  and verified they match the checked-in outputs.

  pakrym-oai · 2026-04-27 18:48:57 -07:00
  4e05f3053c
• permissions: remove cwd special path (#19841)

  ## Why
  
  The experimental `PermissionProfile` API had both `:cwd` and
  `:project_roots` special filesystem paths, which made the permission
  root ambiguous. This PR removes the unstable `current_working_directory`
  special path before the permissions API is stabilized, so callers use
  `:project_roots` for symbolic project-root access.
  
  ## What changed
  
  - Removes `FileSystemSpecialPath::CurrentWorkingDirectory` from protocol
  and app-server protocol models, plus regenerated app-server
  JSON/TypeScript schemas.
  - Replaces internal `:cwd` permission entries with `:project_roots`
  entries.
  - Keeps the existing cwd-update behavior for legacy-shaped
  workspace-write profiles, while removing the deleted
  `CurrentWorkingDirectory` case from that compatibility path.
  - Keeps `PermissionProfile::workspace_write()` as the reusable symbolic
  workspace-write helper, with docs noting that `:project_roots` entries
  resolve at enforcement time.
  - Updates app-server docs/examples and approval UI labeling to stop
  advertising `:cwd` as a permission token.
  
  ## Compatibility
  
  Persisted rollout items may contain the old
  `{"kind":"current_working_directory"}` tag from earlier experimental
  `permissionProfile` snapshots. This PR keeps that tag as a
  deserialize-only alias for `ProjectRoots { subpath: None }`, while
  continuing to serialize only the new `project_roots` tag.
  
  ## Follow-up
  
  This PR intentionally does not introduce an explicit project-root set on
  `SessionConfiguration` or runtime sandbox resolution. Today, the
  resolver still uses the active cwd as the single implicit project root.
  A follow-up should model project roots separately from tool cwd so
  `:project_roots` entries can resolve against the configured project
  roots, and resolve to no entries when there are no project roots.
  
  ## Verification
  
  - `cargo test -p codex-protocol permissions:: --lib`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-sandboxing -p codex-exec-server --lib`
  - `cargo test -p codex-core session_configuration_apply_ --lib`
  - `cargo test -p codex-app-server
  command_exec_permission_profile_project_roots_use_command_cwd --test
  all`
  - `cargo test -p codex-tui
  thread_read_session_state_does_not_reuse_primary_permission_profile
  --lib`
  - `cargo test -p codex-tui
  preset_matching_accepts_workspace_write_with_extra_roots --lib`
  - `cargo test -p codex-config --lib`

  Michael Bolin · 2026-04-27 13:41:27 -07:00
  4b55979755
• Delete unused ResponseItem::Message.end_turn (#19605)

  This field is unused. Delete it.

  Andrey Mishchenko · 2026-04-26 17:18:09 -07:00
  35bc6e3d01
• Update image outputs to default to high detail (#18386)

  Do not assume the default `detail`.

  pakrym-oai · 2026-04-18 11:01:12 -07:00
  53b1570367
• Add notify to code-mode (#14842)

  Allows model to send an out-of-band notification.
  
  The notification is injected as another tool call output for the same
  call_id.

  pakrym-oai · 2026-03-18 09:37:13 -07:00
  606d85055f
• generate an internal json schema for RolloutLine (#14434)

  ### Why
  i'm working on something that parses and analyzes codex rollout logs,
  and i'd like to have a schema for generating a parser/validator.
  
  `codex app-server generate-internal-json-schema` writes an
  `RolloutLine.json` file
  
  while doing this, i noticed we have a writer <> reader mismatch issue on
  `FunctionCallOutputPayload` and reasoning item ID -- added some schemars
  annotations to fix those
  
  ### Test
  
  ```
  $ just codex app-server generate-internal-json-schema --out ./foo
  ```
  
  generates an `RolloutLine.json` file, which i validated against jsonl
  files on disk
  
  `just codex app-server --help` doesn't expose the
  `generate-internal-json-schema` option by default, but you can do `just
  codex app-server generate-internal-json-schema --help` if you know the
  command
  
  everything else still works
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Keyan Zhang · 2026-03-17 11:19:42 -07:00
  904dbd414f
• feat: search_tool migrate to bring you own tool of Responses API (#14274)

  ## Why
  
  to support a new bring your own search tool in Responses
  API(https://developers.openai.com/api/docs/guides/tools-tool-search#client-executed-tool-search)
  we migrating our bm25 search tool to use official way to execute search
  on client and communicate additional tools to the model.
  
  ## What
  - replace the legacy `search_tool_bm25` flow with client-executed
  `tool_search`
  - add protocol, SSE, history, and normalization support for
  `tool_search_call` and `tool_search_output`
  - return namespaced Codex Apps search results and wire namespaced
  follow-up tool calls back into MCP dispatch

  Anton Panasenko · 2026-03-11 17:51:51 -07:00
  77b0c75267
• feat(app-server-protocol): address naming conflicts in json schema exporter (#13819)

  This fixes a schema export bug where two different `WebSearchAction`
  types were getting merged under the same name in the app-server v2 JSON
  schema bundle.
  
  The problem was that v2 thread items use the app-server API's
  `WebSearchAction` with camelCase variants like `openPage`, while
  `ThreadResumeParams.history` and
  `RawResponseItemCompletedNotification.item` pull in the upstream
  `ResponseItem` graph, which uses the Responses API snake_case shape like
  `open_page`. During bundle generation we were flattening nested
  definitions into the v2 namespace by plain name, so the later definition
  could silently overwrite the earlier one.
  
  That meant clients generating code from the bundled schema could end up
  with the wrong `WebSearchAction` definition for v2 thread history. In
  practice this shows up on web search items reconstructed from rollout
  files with persisted extended history.
  
  This change does two things:
  - Gives the upstream Responses API schema a distinct JSON schema name:
  `ResponsesApiWebSearchAction`
  - Makes namespace-level schema definition collisions fail loudly instead
  of silently overwriting

  Owen Lin · 2026-03-07 01:33:46 +00:00
  90469d0a23
• image-gen-core (#13290)

  Core tool-calling for image-gen, handles requesting and receiving logic
  for images using response API

  Won Park · 2026-03-03 23:11:28 -08:00
  fa2306b303
• Add under-development original-resolution view_image support (#13050)

  ## Summary
  
  Add original-resolution support for `view_image` behind the
  under-development `view_image_original_resolution` feature flag.
  
  When the flag is enabled and the target model is `gpt-5.3-codex` or
  newer, `view_image` now preserves original PNG/JPEG/WebP bytes and sends
  `detail: "original"` to the Responses API instead of using the legacy
  resize/compress path.
  
  ## What changed
  
  - Added `view_image_original_resolution` as an under-development feature
  flag.
  - Added `ImageDetail` to the protocol models and support for serializing
  `detail: "original"` on tool-returned images.
  - Added `PromptImageMode::Original` to `codex-utils-image`.
    - Preserves original PNG/JPEG/WebP bytes.
    - Keeps legacy behavior for the resize path.
  - Updated `view_image` to:
  - use the shared `local_image_content_items_with_label_number(...)`
  helper in both code paths
    - select original-resolution mode only when:
      - the feature flag is enabled, and
      - the model slug parses as `gpt-5.3-codex` or newer
  - Kept local user image attachments on the existing resize path; this
  change is specific to `view_image`.
  - Updated history/image accounting so only `detail: "original"` images
  use the docs-based GPT-5 image cost calculation; legacy images still use
  the old fixed estimate.
  - Added JS REPL guidance, gated on the same feature flag, to prefer JPEG
  at 85% quality unless lossless is required, while still allowing other
  formats when explicitly requested.
  - Updated tests and helper code that construct
  `FunctionCallOutputContentItem::InputImage` to carry the new `detail`
  field.
  
  ## Behavior
  
  ### Feature off
  - `view_image` keeps the existing resize/re-encode behavior.
  - History estimation keeps the existing fixed-cost heuristic.
  
  ### Feature on + `gpt-5.3-codex+`
  - `view_image` sends original-resolution images with `detail:
  "original"`.
  - PNG/JPEG/WebP source bytes are preserved when possible.
  - History estimation uses the GPT-5 docs-based image-cost calculation
  for those `detail: "original"` images.
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/13050
  - ⏳ `2` https://github.com/openai/codex/pull/13331
  - ⏳ `3` https://github.com/openai/codex/pull/13049

  Curtis 'Fjord' Hawthorne · 2026-03-03 15:56:54 -08:00
  b92146d48b
• Support multimodal custom tool outputs (#12948)

  ## Summary
  
  This changes `custom_tool_call_output` to use the same output payload
  shape as `function_call_output`, so freeform tools can return either
  plain text or structured content items.
  
  The main goal is to let `js_repl` return image content from nested
  `view_image` calls in its own `custom_tool_call_output`, instead of
  relying on a separate injected message.
  
  ## What changed
  
  - Changed `custom_tool_call_output.output` from `string` to
  `FunctionCallOutputPayload`
  - Updated freeform tool plumbing to preserve structured output bodies
  - Updated `js_repl` to aggregate nested tool content items and attach
  them to the outer `js_repl` result
  - Removed the old `js_repl` special case that injected `view_image`
  results as a separate pending user image message
  - Updated normalization/history/truncation paths to handle multimodal
  `custom_tool_call_output`
  - Regenerated app-server protocol schema artifacts
  
  ## Behavior
  
  Direct `view_image` calls still return a `function_call_output` with
  image content.
  
  When `view_image` is called inside `js_repl`, the outer `js_repl`
  `custom_tool_call_output` now carries:
  - an `input_text` item if the JS produced text output
  - one or more `input_image` items from nested tool results
  
  So the nested image result now stays inside the `js_repl` tool output
  instead of being injected as a separate message.
  
  ## Compatibility
  
  This is intended to be backward-compatible for resumed conversations.
  
  Older histories that stored `custom_tool_call_output.output` as a plain
  string still deserialize correctly, and older histories that used the
  previous injected-image-message flow also continue to resume.
  
  Added regression coverage for resuming a pre-change rollout containing:
  - string-valued `custom_tool_call_output`
  - legacy injected image message history
  
  
  #### [git stack](https://github.com/magus/git-stack-cli)
  - 👉 `1` https://github.com/openai/codex/pull/12948

  Curtis 'Fjord' Hawthorne · 2026-02-26 18:17:46 -08:00
  7e980d7db6
• fix(tui): conditionally restore status indicator using message phase (#10947)

  TLDR: use new message phase field emitted by preamble-supported models
  to determine whether an AgentMessage is mid-turn commentary. if so,
  restore the status indicator afterwards to indicate the turn has not
  completed.
  
  ### Problem
  `commit_tick` hides the status indicator while streaming assistant text.
  For preamble-capable models, that text can be commentary mid-turn, so
  hiding was correct during streaming but restore timing mattered:
  - restoring too aggressively caused jitter/flashing
  - not restoring caused indicator to stay hidden before subsequent work
  (tool calls, web search, etc.)
  
  ### Fix
  - Add optional `phase` to `AgentMessageItem` and propagate it from
  `ResponseItem::Message`
  - Keep indicator hidden during streamed commit ticks, restore only when:
    - assistant item completes as `phase=commentary`, and
    - stream queues are idle + task is still running.
  - Treat `phase=None` as final-answer behavior (no restore) to keep
  existing behavior for non-preamble models
  
  ### Tests
  Add/update tests for:
  - no idle-tick restore without commentary completion
  - commentary completion restoring status before tool begin
  - snapshot coverage for preamble/status behavior
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  sayan-oai · 2026-02-07 02:39:52 +00:00
  5d2702f6b8
• feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567)

  Took over the work that @aaronl-openai started here:
  https://github.com/openai/codex/pull/10397
  
  Now that app-server clients are able to set up custom tools (called
  `dynamic_tools` in app-server), we should expose a way for clients to
  pass in not just text, but also image outputs. This is something the
  Responses API already supports for function call outputs, where you can
  pass in either a string or an array of content outputs (text, image,
  file):
  https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image
  
  So let's just plumb it through in Codex (with the caveat that we only
  support text and image for now). This is implemented end-to-end across
  app-server v2 protocol types and core tool handling.
  
  ## Breaking API change
  NOTE: This introduces a breaking change with dynamic tools, but I think
  it's ok since this concept was only recently introduced
  (https://github.com/openai/codex/pull/9539) and it's better to get the
  API contract correct. I don't think there are any real consumers of this
  yet (not even the Codex App).
  
  Old shape:
  `{ "output": "dynamic-ok", "success": true }`
  
  New shape:
  ```
  {
      "contentItems": [
        { "type": "inputText", "text": "dynamic-ok" },
        { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" }
      ]
    "success": true
  }
  ```

  Owen Lin · 2026-02-04 16:12:47 -08:00
  5ea107a088
• chore: nuke chat/completions API (#10157)
  jif-oai · 2026-02-03 11:31:57 +00:00
  d2394a2494
• chore: add phase to message responseitem (#10455)

  ### What
  
  add wiring for `phase` field on `ResponseItem::Message` to lay
  groundwork for differentiating model preambles and final messages.
  currently optional.
  
  follows pattern in #9698.
  
  updated schemas with `just write-app-server-schema` so we can see type
  changes.
  
  ### Tests
  Updated existing tests for SSE parsing and hydrating from history

  sayan-oai · 2026-02-03 02:52:26 +00:00
  fc05374344
• feat: vendor app-server protocol schema fixtures (#10371)

  Similar to what @sayan-oai did in openai/codex#8956 for
  `config.schema.json`, this PR updates the repo so that it includes the
  output of `codex app-server generate-json-schema` and `codex app-server
  generate-ts` and adds a test to verify it is in sync with the current
  code.
  
  Motivation:
  - This makes any schema changes introduced by a PR transparent during
  code review.
  - In particular, this should help us catch PRs that would introduce a
  non-backwards-compatible change to the app schema (eventually, this
  should also be enforced by tooling).
  - Once https://github.com/openai/codex/pull/10231 is in to formalize the
  notion of "experimental" fields, we can work on ensuring the
  non-experimental bits are backwards-compatible.
  
  `codex-rs/app-server-protocol/tests/schema_fixtures.rs` was added as the
  test and `just write-app-server-schema` can be use to generate the
  vendored schema files.
  
  Incidentally, when I run:
  
  ```
  rg _ codex-rs/app-server-protocol/schema/typescript/v2
  ```
  
  I see a number of `snake_case` names that should be `camelCase`.

  Michael Bolin · 2026-02-01 23:38:43 -08:00
  974355cfdd