26 Commits

• 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
• Generate more typescript types and return conversation id with ConversationSummary (#3219)

  This PR does multiple things that are necessary for conversation resume
  to work from the extension. I wanted to make sure everything worked so
  these changes wound up in one PR:
  1. Generate more ts types
  2. Resume rollout history files rather than create a new one every time
  it is resumed so you don't see a duplicate conversation in history for
  every resume. Chatted with @aibrahim-oai to verify this
  3. Return conversation_id in conversation summaries
  4. [Cleanup] Use serde and strong types for a lot of the rollout file
  parsing

  Gabriel Peal · 2025-09-08 17:54:47 -04:00
  5eaaf307e1
• Never store requests (#3212)

  When item ids are sent to Responses API it will load them from the
  database ignoring the provided values. This adds extra latency.
  
  Not having the mode to store requests also allows us to simplify the
  code.
  
  ## Breaking change
  
  The `disable_response_storage` configuration option is removed.

  pakrym-oai · 2025-09-05 10:41:47 -07:00
  5775174ec2
• Dividing UserMsgs into categories to send it back to the tui (#3127)

  This PR does the following:
  
  - divides user msgs into 3 categories: plain, user instructions, and
  environment context
  - Centralizes adding user instructions and environment context to a
  degree
  - Improve the integration testing
  
  Building on top of #3123
  
  Specifically this
  [comment](https://github.com/openai/codex/pull/3123#discussion_r2319885089).
  We need to send the user message while ignoring the User Instructions
  and Environment Context we attach.

  Ahmed Ibrahim · 2025-09-04 05:34:50 +00:00
  2b96f9f569
• Following up on #2371 post commit feedback (#2852)

  - Introduce websearch end to complement the begin 
  - Moves the logic of adding the sebsearch tool to
  create_tools_json_for_responses_api
  - Making it the client responsibility to toggle the tool on or off 
  - Other misc in #2371 post commit feedback
  - Show the query:
  
  <img width="1392" height="151" alt="image"
  src="https://github.com/user-attachments/assets/8457f1a6-f851-44cf-bcca-0d4fe460ce89"
  />

  Ahmed Ibrahim · 2025-08-28 19:24:38 -07:00
  9dbe7284d2
• Move models.rs to protocol (#2595)

  Moving models.rs to protocol so we can use them in `Codex` operations

  Ahmed Ibrahim · 2025-08-22 22:18:54 +00:00
  097782c775