55 Commits

• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• 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
• fix(core) switching model appends model instructions (#10651)

  ## Summary
  When switching models, we should append the instructions of the new
  model to the conversation as a developer message.
  
  ## Test
  - [x] Adds a unit test

  Dylan Hurd · 2026-02-05 05:50:38 +00:00
  e482978261
• 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
• fix(core) updated request_rule guidance (#10379)

  ## Summary
  Update guidance for request_rule
  
  ## Testing
  - [x] Unit tests pass

  Dylan Hurd · 2026-02-03 22:29:52 -08:00
  968c029471
• 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: replace custom mcp-types crate with equivalents from rmcp (#10349)

  We started working with MCP in Codex before
  https://crates.io/crates/rmcp was mature, so we had our own crate for
  MCP types that was generated from the MCP schema:
  
  
  https://github.com/openai/codex/blob/8b95d3e082376f4cb23e92641705a22afb28a9da/codex-rs/mcp-types/README.md
  
  Now that `rmcp` is more mature, it makes more sense to use their MCP
  types in Rust, as they handle details (like the `_meta` field) that our
  custom version ignored. Though one advantage that our custom types had
  is that our generated types implemented `JsonSchema` and `ts_rs::TS`,
  whereas the types in `rmcp` do not. As such, part of the work of this PR
  is leveraging the adapters between `rmcp` types and the serializable
  types that are API for us (app server and MCP) introduced in #10356.
  
  Note this PR results in a number of changes to
  `codex-rs/app-server-protocol/schema`, which merit special attention
  during review. We must ensure that these changes are still
  backwards-compatible, which is possible because we have:
  
  ```diff
  - export type CallToolResult = { content: Array<ContentBlock>, isError?: boolean, structuredContent?: JsonValue, };
  + export type CallToolResult = { content: Array<JsonValue>, structuredContent?: JsonValue, isError?: boolean, _meta?: JsonValue, };
  ```
  
  so `ContentBlock` has been replaced with the more general `JsonValue`.
  Note that `ContentBlock` was defined as:
  
  ```typescript
  export type ContentBlock = TextContent | ImageContent | AudioContent | ResourceLink | EmbeddedResource;
  ```
  
  so the deletion of those individual variants should not be a cause of
  great concern.
  
  Similarly, we have the following change in
  `codex-rs/app-server-protocol/schema/typescript/Tool.ts`:
  
  ```
  - export type Tool = { annotations?: ToolAnnotations, description?: string, inputSchema: ToolInputSchema, name: string, outputSchema?: ToolOutputSchema, title?: string, };
  + export type Tool = { name: string, title?: string, description?: string, inputSchema: JsonValue, outputSchema?: JsonValue, annotations?: JsonValue, icons?: Array<JsonValue>, _meta?: JsonValue, };
  ```
  
  so:
  
  - `annotations?: ToolAnnotations` ➡️ `JsonValue`
  - `inputSchema: ToolInputSchema` ➡️ `JsonValue`
  - `outputSchema?: ToolOutputSchema` ➡️ `JsonValue`
  
  and two new fields: `icons?: Array<JsonValue>, _meta?: JsonValue`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10349).
  * #10357
  * __->__ #10349
  * #10356

  Michael Bolin · 2026-02-02 17:41:55 -08:00
  66447d5d2c
• fix(rules) Limit rules listed in conversation (#10351)

  ## Summary
  We should probably warn users that they have a million rules, and help
  clean them up. But for now, we should handle this unbounded case.
  
  Limit rules listed in conversations, with shortest / broadest rules
  first.
  
  ## Testing
  - [x] Updated unit tests

  Dylan Hurd · 2026-02-02 02:26:15 +00:00
  8b95d3e082
• add missing fields to WebSearchAction and update app-server types (#10276)

  - add `WebSearchAction` to app-server v2 types
  - add `queries` to `WebSearchAction::Search` type
  
  Updated tests.

  sayan-oai · 2026-01-30 16:37:56 -08:00
  eb86663dcb
• [connectors] Support connectors part 2 - slash command and tui (#9728)

  - [x] Support `/apps` slash command to browse the apps in tui.
  - [x] Support inserting apps to prompt using `$`.
  - [x] Lots of simplification/renaming from connectors to apps.

  Matthew Zeng · 2026-01-28 19:51:58 -08:00
  b9cd089d1f
• feat(core) RequestRule (#9489)

  ## Summary
  Instead of trying to derive the prefix_rule for a command mechanically,
  let's let the model decide for us.
  
  ## Testing
  - [x] tested locally

  Dylan Hurd · 2026-01-28 08:43:17 +00:00
  996e09ca24
• fix: handle all web_search actions and in progress invocations (#9960)

  ### Summary
  - Parse all `web_search` tool actions (`search`, `find_in_page`,
  `open_page`).
  - Previously we only parsed + displayed `search`, which made the TUI
  appear to pause when the other actions were being used.
  - Show in progress `web_search` calls as `Searching the web`
    - Previously we only showed completed tool calls
  
  <img width="308" height="149" alt="image"
  src="https://github.com/user-attachments/assets/90a4e8ff-b06a-48ff-a282-b57b31121845"
  />
  
  ### Tests
  Added + updated tests, tested locally
  
  ### Follow ups
  Update VSCode extension to display these as well

  sayan-oai · 2026-01-27 03:33:48 +00:00
  86adf53235
• change collaboration mode to struct (#9793)

  Shouldn't cause behavioral change

  Ahmed Ibrahim · 2026-01-23 17:00:23 -08:00
  69cfc73dc6
• feat(core) update Personality on turn (#9644)

  ## Summary
  Support updating Personality mid-Thread via UserTurn/OverwriteTurn. This
  is explicitly unused by the clients so far, to simplify PRs - app-server
  and tui implementations will be follow-ups.
  
  ## Testing
  - [x] added integration tests

  Dylan Hurd · 2026-01-22 12:04:23 -08:00
  8b3521ee77
• Support end_turn flag (#9698)

  Experimental flag that signals the end of the turn.

  pakrym-oai · 2026-01-22 17:27:48 +00:00
  b511c38ddb
• fix(core) Preserve base_instructions in SessionMeta (#9427)

  ## Summary
  This PR consolidates base_instructions onto SessionMeta /
  SessionConfiguration, so we ensure `base_instructions` is set once per
  session and should be (mostly) immutable, unless:
  - overridden by config on resume / fork
  - sub-agent tasks, like review or collab
  
  
  In a future PR, we should convert all references to `base_instructions`
  to consistently used the typed struct, so it's less likely that we put
  other strings there. See #9423. However, this PR is already quite
  complex, so I'm deferring that to a follow-up.
  
  ## Testing
  - [x] Added a resume test to assert that instructions are preserved. In
  particular, `resume_switches_models_preserves_base_instructions` fails
  against main.
  
  Existing test coverage thats assert base instructions are preserved
  across multiple requests in a session:
  - Manual compact keeps baseline instructions:
  core/tests/suite/compact.rs:199
  - Auto-compact keeps baseline instructions:
  core/tests/suite/compact.rs:1142
  - Prompt caching reuses the same instructions across two requests:
  core/tests/suite/prompt_caching.rs:150 and
  core/tests/suite/prompt_caching.rs:157
  - Prompt caching with explicit expected string across two requests:
  core/tests/suite/prompt_caching.rs:213 and
  core/tests/suite/prompt_caching.rs:222
  - Resume with model switch keeps original instructions:
  core/tests/suite/resume.rs:136
  - Compact/resume/fork uses request 0 instructions for later expected
  payloads: core/tests/suite/compact_resume_fork.rs:215

  Dylan Hurd · 2026-01-19 21:59:36 -08:00
  675f165c56
• Add collaboration modes test prompts (#9443)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2026-01-18 11:39:08 -08:00
  f72f87fbee
• Add collaboration developer instructions (#9424)

  - Add additional instructions when they are available
  - Make sure to update them on change either UserInput or UserTurn

  Ahmed Ibrahim · 2026-01-18 01:31:14 +00:00
  1478a88eb0
• Add text element metadata to types (#9235)

  Initial type tweaking PR to make the diff of
  https://github.com/openai/codex/pull/9116 smaller
  
  This should not change any behavior, just adds some fields to types

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a
• Assemble sandbox/approval/network prompts dynamically (#8961)

  - Add a single builder for developer permissions messaging that accepts
  SandboxPolicy and approval policy. This builder now drives the developer
  “permissions” message that’s injected at session start and any time
  sandbox/approval settings change.
  - Trim EnvironmentContext to only include cwd, writable roots, and
  shell; removed sandbox/approval/network duplication and adjusted XML
  serialization and tests accordingly.
  
  Follow-up: adding a config value to replace the developer permissions
  message for custom sandboxes.

  Ahmed Ibrahim · 2026-01-12 23:12:59 +00:00
  87f7226cca
• Label attached images so agent can understand in-message labels (#8950)

  Agent wouldn't "see" attached images and would instead try to use the
  view_file tool:
  <img width="1516" height="504" alt="image"
  src="https://github.com/user-attachments/assets/68a705bb-f962-4fc1-9087-e932a6859b12"
  />
  
  In this PR, we wrap image content items in XML tags with the name of
  each image (now just a numbered name like `[Image #1]`), so that the
  model can understand inline image references (based on name). We also
  put the image content items above the user message which the model seems
  to prefer (maybe it's more used to definitions being before references).
  
  We also tweak the view_file tool description which seemed to help a bit
  
  Results on a simple eval set of images:
  
  Before
  <img width="980" height="310" alt="image"
  src="https://github.com/user-attachments/assets/ba838651-2565-4684-a12e-81a36641bf86"
  />
  
  After
  <img width="918" height="322" alt="image"
  src="https://github.com/user-attachments/assets/10a81951-7ee6-415e-a27e-e7a3fd0aee6f"
  />
  
  ```json
  [
    {
      "id": "single_describe",
      "prompt": "Describe the attached image in one sentence.",
      "images": ["image_a.png"]
    },
    {
      "id": "single_color",
      "prompt": "What is the dominant color in the image? Answer with a single color word.",
      "images": ["image_b.png"]
    },
    {
      "id": "orientation_check",
      "prompt": "Is the image portrait or landscape? Answer in one sentence.",
      "images": ["image_c.png"]
    },
    {
      "id": "detail_request",
      "prompt": "Look closely at the image and call out any small details you notice.",
      "images": ["image_d.png"]
    },
    {
      "id": "two_images_compare",
      "prompt": "I attached two images. Are they the same or different? Briefly explain.",
      "images": ["image_a.png", "image_b.png"]
    },
    {
      "id": "two_images_captions",
      "prompt": "Provide a short caption for each image (Image 1, Image 2).",
      "images": ["image_c.png", "image_d.png"]
    },
    {
      "id": "multi_image_rank",
      "prompt": "Rank the attached images from most colorful to least colorful.",
      "images": ["image_a.png", "image_b.png", "image_c.png"]
    },
    {
      "id": "multi_image_choice",
      "prompt": "Which image looks more vibrant? Answer with 'Image 1' or 'Image 2'.",
      "images": ["image_b.png", "image_d.png"]
    }
  ]
  ```

  charley-oai · 2026-01-09 21:33:45 -08:00
  6709ad8975
• nit: parse_arguments (#8927)
  jif-oai · 2026-01-08 19:49:17 +00:00
  c9c6560685
• Log compaction request bodies (#8676)

  We already log request bodies for normal requests, logging for
  compaction helps with debugging.

  pakrym-oai · 2026-01-02 11:27:37 -08:00
  7078a0b676
• Remote compact for API-key users (#7835)
  pakrym-oai · 2025-12-12 10:05:02 -08:00
  b3ddd50eee
• Inject SKILL.md when it's explicitly mentioned. (#7763)

  1. Skills load once in core at session start; the cached outcome is
  reused across core and surfaced to TUI via SessionConfigured.
  2. TUI detects explicit skill selections, and core injects the matching
  SKILL.md content into the turn when a selected skill is present.

  xl-openai · 2025-12-10 13:59:17 -08:00
  b36ecb6c32
• refactoring with_escalated_permissions to use SandboxPermissions instead (#7750)

  helpful in the future if we want more granularity for requesting
  escalated permissions:
  e.g when running in readonly sandbox, model can request to escalate to a
  sandbox that allows writes

  zhao-oai · 2025-12-10 17:18:48 +00:00
  e0fb3ca1db
• Fix: gracefully error out for unsupported images (#7478)

  Fix for #7459 
  ## What
  Since codex errors out for unsupported images, stop attempting to
  base64/attach them and instead emit a clear placeholder when the file
  isn’t a supported image MIME.
  
  ## Why
  Local uploads for unsupported formats (e.g., SVG/GIF/etc.) were
  dead-ending after decode failures because of the 400 retry loop. Users
  now get an explicit “cannot attach … unsupported image format …”
  response.
  
  ## How
  Replace the fallback read/encode path with MIME detection that bails out
  for non-image or unsupported image types, returning a consistent
  placeholder. Unreadable and invalid images still produce their existing
  error placeholders.

  Job Chong · 2025-12-09 10:28:41 -08:00
  ac3237721e
• feat(core) Add login to shell_command tool (#6846)

  ## Summary
  Adds the `login` parameter to the `shell_command` tool - optional,
  defaults to true.
  
  ## Testing
  - [x] Tested locally

  Dylan Hurd · 2025-12-05 11:03:25 -08:00
  a8cbbdbc6e
• feat: alias compaction (#7442)
  jif-oai · 2025-12-02 09:21:30 +00:00
  85e2fabc9f
• Support all types of search actions (#7061)

  Fixes the 
  
  ```
  {
    "error": {
      "message": "Invalid value: 'other'. Supported values are: 'search', 'open_page', and 'find_in_page'.",
      "type": "invalid_request_error",
      "param": "input[150].action.type",
      "code": "invalid_value"
    }
  ```
  error.
  
  
  The actual-actual fix here is supporting absent `query` parameter.

  pakrym-oai · 2025-11-20 20:45:28 -08:00
  ab5972d447
• feat: remote compaction (#6795)

  Co-authored-by: pakrym-oai <pakrym@openai.com>

  jif-oai · 2025-11-18 16:51:16 +00:00
  838531d3e4
• Demote function call payload log to debug to avoid noisy error-level stderr (#6808)
  cassirer-openai · 2025-11-18 01:16:11 +00:00
  8465f1f2f4
• feat: placeholder for image that can't be decoded to prevent 400 (#6773)
  jif-oai · 2025-11-17 16:10:53 +00:00
  7c8d333980
• feat: shell_command tool (#6510)

  This adds support for a new variant of the shell tool behind a flag. To
  test, run `codex` with `--enable shell_command_tool`, which will
  register the tool with Codex under the name `shell_command` that accepts
  the following shape:
  
  ```python
  {
    command: str
    workdir: str | None,
    timeout_ms: int | None,
    with_escalated_permissions: bool | None,
    justification: str | None,
  }
  ```
  
  This is comparable to the existing tool registered under
  `shell`/`container.exec`. The primary difference is that it accepts
  `command` as a `str` instead of a `str[]`. The `shell_command` tool
  executes by running `execvp(["bash", "-lc", command])`, though the exact
  arguments to `execvp(3)` depend on the user's default shell.
  
  The hypothesis is that this will simplify things for the model. For
  example, on Windows, instead of generating:
  
  ```json
  {"command": ["pwsh.exe", "-NoLogo", "-Command", "ls -Name"]}
  ```
  
  The model could simply generate:
  
  ```json
  {"command": "ls -Name"}
  ```
  
  As part of this change, I extracted some logic out of `user_shell.rs` as
  `Shell::derive_exec_args()` so that it can be reused in
  `codex-rs/core/src/tools/handlers/shell.rs`. Note the original code
  generated exec arg lists like:
  
  ```javascript
  ["bash", "-lc", command]
  ["zsh", "-lc", command]
  ["pwsh.exe", "-NoProfile", "-Command", command]
  ```
  
  Using `-l` for Bash and Zsh, but then specifying `-NoProfile` for
  PowerShell seemed inconsistent to me, so I changed this in the new
  implementation while also adding a `use_login_shell: bool` option to
  make this explicit. If we decide to add a `login: bool` to
  `ShellCommandToolCallParams` like we have for unified exec:
  
  
  https://github.com/openai/codex/blob/807e2c27f0a9f2e85c50e7e6df5533f0d9b853c7/codex-rs/core/src/tools/handlers/unified_exec.rs#L33-L34
  
  Then this should make it straightforward to support.

  Michael Bolin · 2025-11-12 08:18:57 -08:00
  29364f3a9b
• [app-server] remove serde(skip_serializing_if = "Option::is_none") annotations (#5939)

  We had this annotation everywhere in app-server APIs which made it so
  that fields get serialized as `field?: T`, meaning if the field as
  `None` we would omit the field in the payload. Removing this annotation
  changes it so that we return `field: T | null` instead, which makes
  codex app-server's API more aligned with the convention of public OpenAI
  APIs like Responses.
  
  Separately, remove the `#[ts(optional_fields = nullable)]` annotations
  that were recently added which made all the TS types become `field?: T |
  null` which is not great since clients need to handle undefined and
  null.
  
  I think generally it'll be best to have optional types be either:
  - `field: T | null` (preferred, aligned with public OpenAI APIs)
  - `field?: T` where we have to, such as types generated from the MCP
  schema:
  https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/schema/2025-06-18/schema.ts
  (see changes to `mcp-types/`)
  
  I updated @etraut-openai's unit test to check that all generated TS
  types are one or the other, not both (so will error if we have a type
  that has `field?: T | null`). I don't think there's currently a good use
  case for that - but we can always revisit.

  Owen Lin · 2025-10-30 18:18:53 +00:00
  89c00611c2
• Add missing "nullable" macro to protocol structs that contain optional fields (#5901)

  This PR addresses a current hole in the TypeScript code generation for
  the API server protocol. Fields that are marked as "Optional<>" in the
  Rust code are serialized such that the value is omitted when it is
  deserialized — appearing as `undefined`, but the TS type indicates
  (incorrectly) that it is always defined but possibly `null`. This can
  lead to subtle errors that the TypeScript compiler doesn't catch. The
  fix is to include the `#[ts(optional_fields = nullable)]` macro for all
  protocol structs that contain one or more `Optional<>` fields.
  
  This PR also includes a new test that validates that all TS protocol
  code containing "| null" in its type is marked optional ("?") to catch
  cases where `#[ts(optional_fields = nullable)]` is omitted.

  Eric Traut · 2025-10-29 12:09:47 -07:00
  069a38a06c
• chore: merge git crates (#5909)

  Merge `git-apply` and `git-tooling` into `utils/`

  jif-oai · 2025-10-29 12:11:44 +00:00
  fa92cd92fa
• verify mime type of images (#5888)

  solves: https://github.com/openai/codex/issues/5675
  
  Block non-image uploads in the view_image workflow. We now confirm the
  file’s MIME is image/* before building the data URL; otherwise we emit a
  “unsupported MIME type” error to the model. This stops the agent from
  sending application/json blobs that the Responses API rejects with 400s.
  
  <img width="409" height="556" alt="Screenshot 2025-10-28 at 1 15 10 PM"
  src="https://github.com/user-attachments/assets/a92199e8-2769-4b1d-8e33-92d9238c90fe"
  />

  zhao-oai · 2025-10-28 14:52:51 -07:00
  36113509f2
• [MCP] Render MCP tool call result images to the model (#5600)

  It's pretty amazing we have gotten here without the ability for the
  model to see image content from MCP tool calls.
  
  This PR builds off of 4391 and fixes #4819. I would like @KKcorps to get
  adequete credit here but I also want to get this fix in ASAP so I gave
  him a week to update it and haven't gotten a response so I'm going to
  take it across the finish line.
  
  
  This test highlights how absured the current situation is. I asked the
  model to read this image using the Chrome MCP
  <img width="2378" height="674" alt="image"
  src="https://github.com/user-attachments/assets/9ef52608-72a2-4423-9f5e-7ae36b2b56e0"
  />
  
  After this change, it correctly outputs:
  > Captured the page: image dhows a dark terminal-style UI labeled
  `OpenAI Codex (v0.0.0)` with prompt `model: gpt-5-codex medium` and
  working directory `/codex/codex-rs`
  (and more)  
  
  Before this change, it said:
  > Took the full-page screenshot you asked for. It shows a long,
  horizontally repeating pattern of stylized people in orange, light-blue,
  and mustard clothing, holding hands in alternating poses against a white
  background. No text or other graphics-just rows of flat illustration
  stretching off to the right.
  
  Without this change, the Figma, Playwright, Chrome, and other visual MCP
  servers are pretty much entirely useless.
  
  I tested this change with the openai respones api as well as a third
  party completions api

  Gabriel Peal · 2025-10-27 17:55:57 -04:00
  b0bdc04c30
• feat: image resizing (#5446)

  Add image resizing on the client side to reduce load on the API

  jif-oai · 2025-10-27 16:58:10 +00:00
  aea7610c76
• feat: TUI undo op (#5629)
  jif-oai · 2025-10-27 10:55:29 +00:00
  afc4eaab8b
• feat: async ghost commit (#5618)
  jif-oai · 2025-10-27 10:09:10 +00:00
  e92c4f6561
• Add ItemStarted/ItemCompleted events for UserInputItem (#5306)

  Adds a new ItemStarted event and delivers UserMessage as the first item
  type (more to come).
  
  
  Renames `InputItem` to `UserInput` considering we're using the `Item`
  suffix for actual items.

  pakrym-oai · 2025-10-20 13:34:44 -07:00
  9c903c4716
• Generate JSON schema for app-server protocol (#5063)

  Add annotations and an export script that let us generate app-server
  protocol types as typescript and JSONSchema.
  
  The script itself is a bit hacky because we need to manually label some
  of the types. Unfortunately it seems that enum variants don't get good
  names by default and end up with something like `EventMsg1`,
  `EventMsg2`, etc. I'm not an expert in this by any means, but since this
  is only run manually and we already need to enumerate the types required
  to describe the protocol, it didn't seem that much worse. An ideal
  solution here would be to have some kind of root that we could generate
  schemas for in one go, but I'm not sure if that's compatible with how we
  generate the protocol today.

  Rasmus Rygaard · 2025-10-20 11:45:11 -07:00
  846960ae3d
• chore: refactor tool handling (#4510)

  # Tool System Refactor
  
  - Centralizes tool definitions and execution in `core/src/tools/*`:
  specs (`spec.rs`), handlers (`handlers/*`), router (`router.rs`),
  registry/dispatch (`registry.rs`), and shared context (`context.rs`).
  One registry now builds the model-visible tool list and binds handlers.
  - Router converts model responses to tool calls; Registry dispatches
  with consistent telemetry via `codex-rs/otel` and unified error
  handling. Function, Local Shell, MCP, and experimental `unified_exec`
  all flow through this path; legacy shell aliases still work.
  - Rationale: reduce per‑tool boilerplate, keep spec/handler in sync, and
  make adding tools predictable and testable.
  
  Example: `read_file`
  - Spec: `core/src/tools/spec.rs` (see `create_read_file_tool`,
  registered by `build_specs`).
  - Handler: `core/src/tools/handlers/read_file.rs` (absolute `file_path`,
  1‑indexed `offset`, `limit`, `L#: ` prefixes, safe truncation).
  - E2E test: `core/tests/suite/read_file.rs` validates the tool returns
  the requested lines.
  
  ## Next steps:
  - Decompose `handle_container_exec_with_params` 
  - Add parallel tool calls

  jif-oai · 2025-10-03 13:21:06 +01:00
  33d3ecbccc
• Use anyhow::Result in tests for error propagation (#4105)
  pakrym-oai · 2025-09-23 13:31:36 -07:00
  0f9a796617
• bug: default to image (#3501)

  Default the MIME type to image

  jif-oai · 2025-09-11 23:10:24 +00:00
  44bb53df1e
• Unified execution (#3288)

  ## Unified PTY-Based Exec Tool
  
  Note: this requires to have this flag in the config:
  `use_experimental_unified_exec_tool=true`
  
  - Adds a PTY-backed interactive exec feature (“unified_exec”) with
  session reuse via
    session_id, bounded output (128 KiB), and timeout clamping (≤ 60 s).
  - Protocol: introduces ResponseItem::UnifiedExec { session_id,
  arguments, timeout_ms }.
  - Tools: exposes unified_exec as a function tool (Responses API);
  excluded from Chat
    Completions payload while still supported in tool lists.
  - Path handling: resolves commands via PATH (or explicit paths), with
  UTF‑8/newline‑aware
    truncation (truncate_middle).
  - Tests: cover command parsing, path resolution, session
  persistence/cleanup, multi‑session
    isolation, timeouts, and truncation behavior.

  jif-oai · 2025-09-10 17:38:11 -07:00
  c09ed74a16
• Do not send reasoning item IDs (#3390)

  Response API doesn't require IDs on reasoning items anymore. 
  
  Fixes: https://github.com/openai/codex/issues/3292

  pakrym-oai · 2025-09-09 14:47:06 -07:00
  5bcc9d8b77