17 Commits

• test: use automatic environments in app-server integration tests (#29789)

  ## Why
  
  Topology-neutral app-server integration tests should exercise automatic
  environment selection so the same setup covers local and remote
  executors.
  
  ## What
  
  Migrate eligible tests to `TestAppServer::new_with_auto_env()` and
  `send_thread_start_request_with_auto_env()`. Leave explicit-topology
  tests unchanged, and skip the request-permissions case on Windows with a
  TODO for cross-platform tool routing.
  
  ## Validation
  
  - `just test -p codex-app-server`
  - `bazel test //codex-rs/app-server:app-server-all-wine-exec-test
  --test_output=errors`
  
  Stacked on #29788.

  Adam Perry @ OpenAI · 2026-06-23 22:48:06 -07:00
  c2b3e3b4f5
• [codex] reject remote images at app-server ingress (#29419)

  ## Stack
  
  Stacked on #29417. Review and land that PR first.
  
  ## Summary
  
  - reject HTTP(S) image URLs in the handlers for `turn/start` and
  `turn/steer`
  - validate `thread/inject_items` after its existing
  JSON-to-`ResponseItem` conversion, so each item is deserialized once
  - turn invalid dynamic-tool image responses into the existing
  unsuccessful text fallback; the model receives the validation message as
  the function output
  - leave `thread/resume.history` compatible with legacy history; #29417
  replaces remote images before model input
  - continue accepting inline data URLs and `localImage` inputs
  - keep this policy in app-server; this PR does not add a shared protocol
  API or change core image preparation
  
  ## Test plan
  
  - `just test -p codex-app-server -E
  'test(/request_handlers_reject_remote_image_urls|dynamic_tool_remote_image_response_becomes_model_visible_error|dynamic_tool_call_round_trip_sends_content_items_to_model|turn_start_tracks_turn_event_analytics|standalone_image_edit_uses_recent_pathless_image/)'`
  (5 passed)
  - `just fix -p codex-app-server`
  - `just fmt`

  rka-oai · 2026-06-23 00:43:56 +00:00
  b294638bb5
• remove flag for image preparation (#29429)

  ## What
  
  - make Fjord's centralized response-item image preparation unconditional
  for new and resumed history
  - have local user images and `view_image` outputs always defer decoding
  and resizing to that path
  - retain `resize_all_images` as an ignored, removed compatibility key
  for released clients
  - delete the flag-off producer paths and obsolete policy-specific tests
  
  ## Why
  
  Centralized preparation is now the intended image path. Keeping the
  runtime feature checks also kept two image-processing implementations
  alive and allowed client config to select the legacy behavior.
  
  This is a clean replacement for #28975, rebuilt from the latest `main`.
  
  ## How
  
  `prepare_response_items` now runs whenever items enter history and
  whenever persisted history is reconstructed. Producers emit deferred
  image data, so malformed images become the existing model-visible
  placeholder instead of failing the session at the producer.
  
  ## Test plan
  
  - `just fmt`
  - `just fix -p codex-core -p codex-features`
  - `just test -p codex-features` — 52 passed
  - focused affected `codex-core` set — 20 passed
  - `just test -p codex-core handle_accepts_explicit_high_detail` — 1
  passed
  - full `just test -p codex-core` attempt — 2,723 passed; 88 unrelated
  environment failures from read-only `~/.codex` SQLite state and
  unavailable integration helper binaries

  rka-oai · 2026-06-22 10:05:11 -07:00
  e79d72d75d
• Expose explicit dynamic tool namespaces in thread start (#27371)

  Stacked on #27365.
  
  ## Stack note
  
  [#27365](https://github.com/openai/codex/pull/27365) kept `thread/start`
  unchanged and converted its input in `thread_processor`. This PR updates
  `thread/start` to accept explicit functions and namespaces directly.
  
  Legacy per-tool arrays are still accepted and converted while reading
  the request. As a result, `thread_processor` can validate and pass the
  tools through directly, which is why some code added in #27365 is
  removed here.
  
  ## Why
  
  `thread/start.dynamicTools` still repeats namespace data on each
  function even though core now stores explicit namespace groups. The
  request API should use the same shape so each namespace has one
  description and one member list.
  
  ## What changed
  
  - Accept top-level functions and explicit namespace objects in
  `dynamicTools`.
  - Continue accepting fully legacy flat arrays, including
  `exposeToContext`.
  - Reject arrays that mix legacy and canonical entries.
  - Reuse the protocol types directly and remove the temporary app-server
  adapter.
  - Update validation, docs, the test client, and generated schemas.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  dynamic_tool_call_round_trip_sends_text_content_items_to_model`
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-app-server
  thread_start_rejects_mixed_dynamic_tool_formats`
  - `just test -p codex-app-server
  thread_start_rejects_hidden_dynamic_tools_without_namespace`

  sayan-oai · 2026-06-15 15:35:57 +00:00
  11faf9af94
• Represent dynamic tools with explicit namespaces internally (#27365)

  Follow-up to #27356.
  
  ## Stack note
  
  This PR changes Codex's internal dynamic-tool shape while leaving
  `thread/start` unchanged. App-server therefore converts the existing
  per-tool input into explicit functions and namespaces before passing it
  to core.
  
  [#27371](https://github.com/openai/codex/pull/27371) updates
  `thread/start` to use the same explicit shape and removes this temporary
  conversion.
  
  ## Why
  
  Dynamic tools repeat namespace metadata on every function. Core should
  keep one explicit namespace with its member tools so descriptions and
  membership stay consistent across sessions and runtime planning.
  
  ## What changed
  
  - Represent dynamic tools as top-level functions or explicit namespaces
  in protocol and session state.
  - Read old flat rollout metadata and write the canonical hierarchy.
  - Flatten namespace members only when registering callable tools.
  - Keep `thread/start.dynamicTools` flat for now and normalize it at the
  app-server boundary.
  
  New builds can read old rollout metadata. Older builds cannot read newly
  written hierarchical metadata.
  
  ## Test plan
  
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-protocol
  session_meta_normalizes_legacy_dynamic_tools`
  - `just test -p codex-core
  resume_restores_dynamic_tools_from_rollout_with_sqlite_enabled`
  - `just test -p codex-core
  tool_search_returns_deferred_dynamic_tool_and_routes_follow_up_call`
  - `just test -p codex-core code_mode_can_call_hidden_dynamic_tools`
  - `just test -p codex-tools`

  sayan-oai · 2026-06-15 08:06:14 -07:00
  a292faae5a
• fix: rename McpServer to TestAppServer (#25701)

  This PR brought to you via VS Code rather than Codex...
  
  - opened `codex-rs/app-server/tests/common/mcp_process.rs`
  - put the cursor on `McpServer`
  - hit `F2` and renamed the symbol to `TestAppServer`
  - went to the file tree
  - hit enter and renamed `mcp_process.rs` to `test_app_server.rs`
  - ran **Save All Files** from the Command Palette
  - ran `just fmt`
  
  The End
  
  (Admittedly, most of the local variables for `TestAppServer` are still
  named `mcp`, though.)

  Michael Bolin · 2026-06-01 21:49:38 +00:00
  6536841d89
• [codex] Add user input client ids (#24653)

  ## Summary
  
  Adds an optional `clientId` field to app-server v2 `UserInput` and
  carries it through the core `UserInput` model so clients can correlate
  echoed user input items without relying on payload equality.
  
  ## Details
  
  - Adds `client_id: Option<String>` to core `UserInput` variants.
  - Exposes the v2 app-server field as `clientId` on the wire and in
  generated TypeScript.
  - Preserves the id when converting between app-server v2 and core
  protocol types.
  - Regenerates app-server schema fixtures.
  
  ## Validation
  
  - `just fmt`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-protocol`
  - `git diff --check`

  Alexi Christakis · 2026-05-28 14:54:39 -07:00
  e92c952b2e
• app-server: align dynamic tool identifiers with Responses API (#20724)

  ## Why
  
  Codex currently accepts dynamic tool names and namespaces that the
  upstream Responses function-tool path does not actually support. In
  practice, that means app-server can register a dynamic tool successfully
  and only discover later that the LLM-facing tool contract will reject or
  mishandle it.
  
  This PR tightens the app-server-side dynamic tool contract to match the
  Responses API before we stack dynamic tool hook support on top of it.
  
  ## What changed
  
  - validate dynamic tool `name` against the Responses function-tool
  identifier contract: `^[a-zA-Z0-9_-]+$`, length `1..128`
  - validate dynamic tool `namespace` the same way, with the Responses
  namespace length limit `1..64`
  - reject namespaces that collide with the always-reserved Responses
  runtime namespaces such as `functions`, `multi_tool_use`, `file_search`,
  `web`, `browser`, `image_gen`, `computer`, `container`, `terminal`,
  `python`, `python_user_visible`, `api_tool`, `tool_search`, and
  `submodel_delegator`
  - escape invalid identifiers in error messages so control characters do
  not spill raw into logs or client-visible error text
  - document the tightened dynamic tool identifier contract in
  `codex-rs/app-server/README.md`
  - add both unit coverage for the validator and an app-server integration
  test that rejects a `thread/start` request with Responses-incompatible
  dynamic tool identifiers
  
  ## Verification
  
  - `cargo test -p codex-app-server validate_dynamic_tools_`
  - `cargo test -p codex-app-server --test all
  thread_start_rejects_dynamic_tools_not_supported_by_responses`

  Andrei Eternal · 2026-05-05 21:05:00 -07:00
  8ef31894dc
• [tool search] support namespaced deferred dynamic tools (#18413)

  Deferred dynamic tools need to round-trip a namespace so a tool returned
  by `tool_search` can be called through the same registry key that core
  uses for dispatch.
  
  This change adds namespace support for dynamic tool specs/calls,
  persists it through app-server thread state, and routes dynamic tool
  calls by full `ToolName` while still sending the app the leaf tool name.
  Deferred dynamic tools must provide a namespace; non-deferred dynamic
  tools may remain top-level.
  
  It also introduces `LoadableToolSpec` as the shared
  function-or-namespace Responses shape used by both `tool_search` output
  and dynamic tool registration, so dynamic tools use the same wrapping
  logic in both paths.
  
  Validation:
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tool_search`
  
  ---------
  
  Co-authored-by: Sayan Sisodiya <sayan@openai.com>

  pash-openai · 2026-04-21 14:13:08 +08:00
  dc1a8f2190
• 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
• Stabilize Bazel tests (timeout tweaks and flake fixes) (#17791)
  David de Regt · 2026-04-16 07:57:51 -07:00
  6adba99f4d
• dynamic tool calls: add param exposeToContext to optionally hide tool (#14501)

  This extends dynamic_tool_calls to allow us to hide a tool from the
  model context but still use it as part of the general tool calling
  runtime (for ex from js_repl/code_mode)

  Channing Conger · 2026-03-14 01:58:43 -07:00
  70eddad6b0
• Enforce single tool output type in codex handlers (#14157)

  We'll need to associate output schema with each tool. Each tool can only
  have on output type.

  pakrym-oai · 2026-03-09 21:49:44 -07:00
  d71e042694
• 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
• feat(app-server): add ThreadItem::DynamicToolCall (#12732)

  Previously, clients would call `thread/start` with dynamic_tools set,
  and when a model invokes a dynamic tool, it would just make the
  server->client `item/tool/call` request and wait for the client's
  response to complete the tool call. This works, but it doesn't have an
  `item/started` or `item/completed` event.
  
  Now we are doing this:
  - [new] emit `item/started` with `DynamicToolCall` populated with the
  call arguments
  - send an `item/tool/call` server request
  - [new] once the client responds, emit `item/completed` with
  `DynamicToolCall` populated with the response.
  
  Also, with `persistExtendedHistory: true`, dynamic tool calls are now
  reconstructable in `thread/read` and `thread/resume` as
  `ThreadItem::DynamicToolCall`.

  Owen Lin · 2026-02-25 12:00:10 -08:00
  a0fd94bde6
• 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
• feat: dynamic tools injection (#9539)

  ## Summary
  Add dynamic tool injection to thread startup in API v2, wire dynamic
  tool calls through the app server to clients, and plumb responses back
  into the model tool pipeline.
  
  ### Flow (high level)
  - Thread start injects `dynamic_tools` into the model tool list for that
  thread (validation is done here).
  - When the model emits a tool call for one of those names, core raises a
  `DynamicToolCallRequest` event.
  - The app server forwards it to the client as `item/tool/call`, waits
  for the client’s response, then submits a `DynamicToolResponse` back to
  core.
  - Core turns that into a `function_call_output` in the next model
  request so the model can continue.
  
  ### What changed
  - Added dynamic tool specs to v2 thread start params and protocol types;
  introduced `item/tool/call` (request/response) for dynamic tool
  execution.
  - Core now registers dynamic tool specs at request time and routes those
  calls via a new dynamic tool handler.
  - App server validates tool names/schemas, forwards dynamic tool call
  requests to clients, and publishes tool outputs back into the session.
  - Integration tests

  jif-oai · 2026-01-26 10:06:44 +00:00
  d594693d1a