124 Commits

• Include reasoning tokens in the context window calculation (#6161)

  This value is used to determine whether mid-turn compaction is required.
  Reasoning items are only excluded between turns (and soon will start to
  be preserved even across turns) so it's incorrect to subtract
  reasoning_output_tokens mid term.
  
  This will result in higher values reported between turns but we are also
  looking into preserving reasoning items for the entire conversation to
  improve performance and caching.

  pakrym-oai · 2025-11-03 10:02:23 -08:00
  e5e13479d0
• Changes to sandbox command assessment feature based on initial experiment feedback (#6091)

  * Removed sandbox risk categories; feedback indicates that these are not
  that useful and "less is more"
  * Tweaked the assessment prompt to generate terser answers
  * Fixed bug in orchestrator that prevents this feature from being
  exposed in the extension

  Eric Traut · 2025-11-01 14:52:23 -07:00
  d5853d9c47
• Add warning on compact (#6052)

  This PR introduces the ability for `core` to send `warnings` as it can
  send `errors. It also sends a warning on compaction.
  
  <img width="811" height="187" alt="image"
  src="https://github.com/user-attachments/assets/0947a42d-b720-420d-b7fd-115f8a65a46a"
  />

  Ahmed Ibrahim · 2025-10-31 13:27:33 -07:00
  c8ebb2a0dc
• [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
• Send delegate header (#5942)

  Send delegate type header

  Ahmed Ibrahim · 2025-10-30 09:49:40 +00:00
  fac548e430
• Add item streaming events (#5546)

  Adds AgentMessageContentDelta, ReasoningContentDelta,
  ReasoningRawContentDelta item streaming events while maintaining
  compatibility for old events.
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  pakrym-oai · 2025-10-29 22:33:57 +00:00
  3429e82e45
• Delegate review to codex instance (#5572)

  In this PR, I am exploring migrating task kind to an invocation of
  Codex. The main reason would be getting rid off multiple
  `ConversationHistory` state and streamlining our context/history
  management.
  
  This approach depends on opening a channel between the sub-codex and
  codex. This channel is responsible for forwarding `interactive`
  (`approvals`) and `non-interactive` events. The `task` is responsible
  for handling those events.
  
  This opens the door for implementing `codex as a tool`, replacing
  `compact` and `review`, and potentially subagents.
  
  One consideration is this code is very similar to `app-server` specially
  in the approval part. If in the future we wanted an interactive
  `sub-codex` we should consider using `codex-mcp`

  Ahmed Ibrahim · 2025-10-29 21:04:25 +00:00
  13e1d0362d
• fix: icu_decimal version (#5919)
  jif-oai · 2025-10-29 20:46:45 +00:00
  2b20cd66af
• Add a wrapper around raw response items (#5923)

  We currently have nested enums when sending raw response items in the
  app-server protocol. This makes downstream schemas confusing because we
  need to embed `type`-discriminated enums within each other.
  
  This PR adds a small wrapper around the response item so we can keep the
  schemas separate

  Rasmus Rygaard · 2025-10-29 20:32:40 +00:00
  39e09c289d
• 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
• feat: deprecation warning (#5825)

  <img width="955" height="311" alt="Screenshot 2025-10-28 at 14 26 25"
  src="https://github.com/user-attachments/assets/99729b3d-3bc9-4503-aab3-8dc919220ab4"
  />

  jif-oai · 2025-10-29 12:29:28 +00:00
  060637b4d4
• chore: merge git crates (#5909)

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

  jif-oai · 2025-10-29 12:11:44 +00:00
  fa92cd92fa
• feature: Add "!cmd" user shell execution (#2471)

  feature: Add "!cmd" user shell execution
  
  This change lets users run local shell commands directly from the TUI by
  prefixing their input with ! (e.g. !ls). Output is truncated to keep the
  exec cell usable, and Ctrl-C cleanly
    interrupts long-running commands (e.g. !sleep 10000).
  
  **Summary of changes**
  
  - Route Op::RunUserShellCommand through a dedicated UserShellCommandTask
  (core/src/tasks/user_shell.rs), keeping the task logic out of codex.rs.
  - Reuse the existing tool router: the task constructs a ToolCall for the
  local_shell tool and relies on ShellHandler, so no manual MCP tool
  lookup is required.
  - Emit exec lifecycle events (ExecCommandBegin/ExecCommandEnd) so the
  TUI can show command metadata, live output, and exit status.
  
  **End-to-end flow**
  
    **TUI handling**
  
  1. ChatWidget::submit_user_message (TUI) intercepts messages starting
  with !.
  2. Non-empty commands dispatch Op::RunUserShellCommand { command };
  empty commands surface a help hint.
  3. No UserInput items are created, so nothing is enqueued for the model.
  
    **Core submission loop**
  4. The submission loop routes the op to handlers::run_user_shell_command
  (core/src/codex.rs).
  5. A fresh TurnContext is created and Session::spawn_user_shell_command
  enqueues UserShellCommandTask.
  
    **Task execution**
  6. UserShellCommandTask::run emits TaskStartedEvent, formats the
  command, and prepares a ToolCall targeting local_shell.
    7. ToolCallRuntime::handle_tool_call dispatches to ShellHandler.
  
    **Shell tool runtime**
  8. ShellHandler::run_exec_like launches the process via the unified exec
  runtime, honoring sandbox and shell policies, and emits
  ExecCommandBegin/End.
  9. Stdout/stderr are captured for the UI, but the task does not turn the
  resulting ToolOutput into a model response.
  
    **Completion**
  10. After ExecCommandEnd, the task finishes without an assistant
  message; the session marks it complete and the exec cell displays the
  final output.
  
    **Conversation context**
  
  - The command and its output never enter the conversation history or the
  model prompt; the flow is local-only.
    - Only exec/task events are emitted for UI rendering.
  
  **Demo video**
  
  
  https://github.com/user-attachments/assets/fcd114b0-4304-4448-a367-a04c43e0b996

  Abhishek Bhardwaj · 2025-10-29 00:31:20 -07:00
  89591e4246
• 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
• fix: move account struct to app-server-protocol and use camelCase (#5829)

  Makes sense to move this struct to `app-server-protocol/` since we want
  to serialize as camelCase, but we don't for structs defined in
  `protocol/`
  
  It was:
  ```
  export type Account = { "type": "ApiKey", api_key: string, } | { "type": "chatgpt", email: string | null, plan_type: PlanType, };
  ```
  
  But we want:
  ```
  export type Account = { "type": "apiKey", apiKey: string, } | { "type": "chatgpt", email: string | null, planType: PlanType, };
  ```

  Owen Lin · 2025-10-27 14:06:13 -07:00
  67a219ffc2
• 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
• feat: annotate conversations with model_provider for filtering (#5658)

  Because conversations that use the Responses API can have encrypted
  reasoning messages, trying to resume a conversation with a different
  provider could lead to confusing "failed to decrypt" errors. (This is
  reproducible by starting a conversation using ChatGPT login and resuming
  it as a conversation that uses OpenAI models via Azure.)
  
  This changes `ListConversationsParams` to take a `model_providers:
  Option<Vec<String>>` and adds `model_provider` on each
  `ConversationSummary` it returns so these cases can be disambiguated.
  
  Note this ended up making changes to
  `codex-rs/core/src/rollout/tests.rs` because it had a number of cases
  where it expected `Some` for the value of `next_cursor`, but the list of
  rollouts was complete, so according to this docstring:
  
  
  https://github.com/openai/codex/blob/bcd64c7e7231d6316a2377d1525a0fa74f21b783/codex-rs/app-server-protocol/src/protocol.rs#L334-L337
  
  If there are no more items to return, then `next_cursor` should be
  `None`. This PR updates that logic.
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/5658).
  * #5803
  * #5793
  * __->__ #5658

  Michael Bolin · 2025-10-27 02:03:30 -07:00
  5907422d65
• Add feedback upload request handling (#5682)
  Ahmed Ibrahim · 2025-10-27 05:53:39 +00:00
  f178805252
• [codex][app-server] introduce codex/event/raw_item events (#5578)
  Anton Panasenko · 2025-10-24 22:41:52 +00:00
  6af83d86ff
• Added model summary and risk assessment for commands that violate sandbox policy (#5536)

  This PR adds support for a model-based summary and risk assessment for
  commands that violate the sandbox policy and require user approval. This
  aids the user in evaluating whether the command should be approved.
  
  The feature works by taking a failed command and passing it back to the
  model and asking it to summarize the command, give it a risk level (low,
  medium, high) and a risk category (e.g. "data deletion" or "data
  exfiltration"). It uses a new conversation thread so the context in the
  existing thread doesn't influence the answer. If the call to the model
  fails or takes longer than 5 seconds, it falls back to the current
  behavior.
  
  For now, this is an experimental feature and is gated by a config key
  `experimental_sandbox_command_assessment`.
  
  Here is a screen shot of the approval prompt showing the risk assessment
  and summary.
  
  <img width="723" height="282" alt="image"
  src="https://github.com/user-attachments/assets/4597dd7c-d5a0-4e9f-9d13-414bd082fd6b"
  />

  Eric Traut · 2025-10-24 15:23:44 -07:00
  f8af4f5c8d
• [app-server] add new account method API stubs (#5527)

  These are the schema definitions for the new JSON-RPC APIs associated
  with accounts. These are not wired up to business logic yet and will
  currently throw an internal error indicating these are unimplemented.

  Owen Lin · 2025-10-22 15:36:11 -07:00
  aee321f62b
• Add new thread items and rewire event parsing to use them (#5418)

  1. Adds AgentMessage,  Reasoning,  WebSearch items.
  2. Switches the ResponseItem parsing to use new items and then also emit
  3. Removes user-item kind and filters out "special" (environment) user
  items when returning to clients.

  pakrym-oai · 2025-10-22 10:14:50 -07:00
  3c90728a29
• [app-server] read rate limits API (#5302)

  Adds a `GET account/rateLimits/read` API to app-server. This calls the
  codex backend to fetch the user's current rate limits.
  
  This would be helpful in checking rate limits without having to send a
  message.
  
  For calling the codex backend usage API, I generated the types and
  manually copied the relevant ones into `codex-backend-openapi-types`.
  It'll be nice to extend our internal openapi generator to support Rust
  so we don't have to run these manual steps.
  
  # 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.

  Owen Lin · 2025-10-20 14:11:54 -07:00
  5c680c6587
• 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
• Use int timestamps for rate limit reset_at (#5383)

  The backend will be returning unix timestamps (seconds since epoch)
  instead of RFC 3339 strings. This will make it more ergonomic for
  developers to integrate against - no string parsing.

  Owen Lin · 2025-10-20 12:26:46 -07:00
  c84fc83222
• 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
• Auto compact at ~90% (#5292)

  Users now hit a window exceeded limit and they usually don't know what
  to do. This starts auto compact at ~90% of the window.

  Ahmed Ibrahim · 2025-10-20 11:29:49 -07:00
  049a61bcfc
• Add forced_chatgpt_workspace_id and forced_login_method configuration options (#5303)

  This PR adds support for configs to specify a forced login method
  (chatgpt or api) as well as a forced chatgpt account id. This lets
  enterprises uses [managed
  configs](https://developers.openai.com/codex/security#managed-configuration)
  to force all employees to use their company's workspace instead of their
  own or any other.
  
  When a workspace id is set, a query param is sent to the login flow
  which auto-selects the given workspace or errors if the user isn't a
  member of it.
  
  This PR is large but a large % of it is tests, wiring, and required
  formatting changes.
  
  API login with chatgpt forced
  <img width="1592" height="116" alt="CleanShot 2025-10-19 at 22 40 04"
  src="https://github.com/user-attachments/assets/560c6bb4-a20a-4a37-95af-93df39d057dd"
  />
  
  ChatGPT login with api forced
  <img width="1018" height="100" alt="CleanShot 2025-10-19 at 22 40 29"
  src="https://github.com/user-attachments/assets/d010bbbb-9c8d-4227-9eda-e55bf043b4af"
  />
  
  Onboarding with api forced
  <img width="892" height="460" alt="CleanShot 2025-10-19 at 22 41 02"
  src="https://github.com/user-attachments/assets/cc0ed45c-b257-4d62-a32e-6ca7514b5edd"
  />
  
  Onboarding with ChatGPT forced
  <img width="1154" height="426" alt="CleanShot 2025-10-19 at 22 41 27"
  src="https://github.com/user-attachments/assets/41c41417-dc68-4bb4-b3e7-3b7769f7e6a1"
  />
  
  Logging in with the wrong workspace
  <img width="2222" height="84" alt="CleanShot 2025-10-19 at 22 42 31"
  src="https://github.com/user-attachments/assets/0ff4222c-f626-4dd3-b035-0b7fe998a046"
  />

  Gabriel Peal · 2025-10-20 08:50:54 -07:00
  d87f87e25b
• fix: switch rate limit reset handling to timestamps (#5304)

  This change ensures that we store the absolute time instead of relative
  offsets of when the primary and secondary rate limits will reset.
  Previously these got recalculated relative to current time, which leads
  to the displayed reset times to change over time, including after doing
  a codex resume.
  
  For previously changed sessions, this will cause the reset times to not
  show due to this being a breaking change:
  <img width="524" height="55" alt="Screenshot 2025-10-17 at 5 14 18 PM"
  src="https://github.com/user-attachments/assets/53ebd43e-da25-4fef-9c47-94a529d40265"
  />
  
  Fixes https://github.com/openai/codex/issues/4761

  Thibault Sottiaux · 2025-10-17 17:39:37 -07:00
  0e08dd6055
• feat: add path field to ParsedCommand::Read variant (#5275)

  `ParsedCommand::Read` has a `name` field that attempts to identify the
  name of the file being read, but the file may not be in the `cwd` in
  which the command is invoked as demonstrated by this existing unit test:
  
  
  https://github.com/openai/codex/blob/0139f6780c850d87bb37bbb3a11e763d5dc3b50d/codex-rs/core/src/parse_command.rs#L250-L260
  
  As you can see, `tui/Cargo.toml` is the relative path to the file being
  read.
  
  This PR introduces a new `path: PathBuf` field to `ParsedCommand::Read`
  that attempts to capture this information. When possible, this is an
  absolute path, though when relative, it should be resolved against the
  `cwd` that will be used to run the command to derive the absolute path.
  
  This should make it easier for clients to provide UI for a "read file"
  event that corresponds to the command execution.

  Michael Bolin · 2025-10-17 06:19:54 +00:00
  50f53e7071
• [MCP] Add support for resources (#5239)

  This PR adds support for [MCP
  resources](https://modelcontextprotocol.io/specification/2025-06-18/server/resources)
  by adding three new tools for the model:
  1. `list_resources`
  2. `list_resource_templates`
  3. `read_resource`
  
  These 3 tools correspond to the [three primary MCP resource protocol
  messages](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#protocol-messages).
  
  Example of listing and reading a GitHub resource tempalte
  <img width="2984" height="804" alt="CleanShot 2025-10-15 at 17 31 10"
  src="https://github.com/user-attachments/assets/89b7f215-2e2a-41c5-90dd-b932ac84a585"
  />
  
  `/mcp` with Figma configured
  <img width="2984" height="442" alt="CleanShot 2025-10-15 at 18 29 35"
  src="https://github.com/user-attachments/assets/a7578080-2ed2-4c59-b9b4-d8461f90d8ee"
  />
  
  Fixes #4956

  Gabriel Peal · 2025-10-17 01:05:15 -04:00
  40fba1bb4c
• feat: add Vec<ParsedCommand> to ExecApprovalRequestEvent (#5222)

  This adds `parsed_cmd: Vec<ParsedCommand>` to `ExecApprovalRequestEvent`
  in the core protocol (`protocol/src/protocol.rs`), which is also what
  this field is named on `ExecCommandBeginEvent`. Honestly, I don't love
  the name (it sounds like a single command, but it is actually a list of
  them), but I don't want to get distracted by a naming discussion right
  now.
  
  This also adds `parsed_cmd` to `ExecCommandApprovalParams` in
  `codex-rs/app-server-protocol/src/protocol.rs`, so it will be available
  via `codex app-server`, as well.
  
  For consistency, I also updated `ExecApprovalElicitRequestParams` in
  `codex-rs/mcp-server/src/exec_approval.rs` to include this field under
  the name `codex_parsed_cmd`, as that struct already has a number of
  special `codex_*` fields. Note this is the code for when Codex is used
  as an MCP _server_ and therefore has to conform to the official spec for
  an MCP elicitation type.

  Michael Bolin · 2025-10-15 13:58:40 -07:00
  995f5c3614
• feat: message when stream get correctly resumed (#4988)

  <img width="366" height="109" alt="Screenshot 2025-10-09 at 17 44 16"
  src="https://github.com/user-attachments/assets/26bc6f60-11bc-4fc6-a1cc-430ca1203969"
  />

  jif-oai · 2025-10-10 09:07:14 +00:00
  f98fa85b44
• revert /name for now (#4978)

  There was a regression where we'd read entire rollout contents if there
  was no /name present.

  dedrisian-oai · 2025-10-08 17:13:49 -07:00
  4300236681
• feat: Set chat name (#4974)

  Set chat name with `/name` so they appear in the codex resume page:
  
  
  https://github.com/user-attachments/assets/c0252bba-3a53-44c7-a740-f4690a3ad405

  dedrisian-oai · 2025-10-08 16:35:35 -07:00
  ec238a2c39
• [MCP] Add auth status to MCP servers (#4918)

  This adds a queryable auth status for MCP servers which is useful:
  1. To determine whether a streamable HTTP server supports auth or not
  based on whether or not it supports RFC 8414-3.2
  2. Allow us to build a better user experience on top of MCP status

  Gabriel Peal · 2025-10-08 17:37:57 -04:00
  3c5e12e2a4
• [Codex] Use Number instead of BigInt for TokenCountEvent (#4856)

  Adjust to use typescript number so reduce casting and normalizing code
  for VSCE since js supports up to 2^53-1

  Colin Young · 2025-10-06 18:59:37 -07:00
  b09f62a1c3
• Surface context window error to the client (#4675)

  In the past, we were treating `input exceeded context window` as a
  streaming error and retrying on it. Retrying on it has no point because
  it won't change the behavior. In this PR, we surface the error to the
  client without retry and also send a token count event to indicate that
  the context window is full.
  
  <img width="650" height="125" alt="image"
  src="https://github.com/user-attachments/assets/c26b1213-4c27-4bfc-90f4-51a270a3efd5"
  />

  Ahmed Ibrahim · 2025-10-05 01:40:06 +00:00
  90ef94d3b3
• [MCP] Add support for MCP Oauth credentials (#4517)

  This PR adds oauth login support to streamable http servers when
  `experimental_use_rmcp_client` is enabled.
  
  This PR is large but represents the minimal amount of work required for
  this to work. To keep this PR smaller, login can only be done with
  `codex mcp login` and `codex mcp logout` but it doesn't appear in `/mcp`
  or `codex mcp list` yet. Fingers crossed that this is the last large MCP
  PR and that subsequent PRs can be smaller.
  
  Under the hood, credentials are stored using platform credential
  managers using the [keyring crate](https://crates.io/crates/keyring).
  When the keyring isn't available, it falls back to storing credentials
  in `CODEX_HOME/.credentials.json` which is consistent with how other
  coding agents handle authentication.
  
  I tested this on macOS, Windows, WSL (ubuntu), and Linux. I wasn't able
  to test the dbus store on linux but did verify that the fallback works.
  
  One quirk is that if you have credentials, during development, every
  build will have its own ad-hoc binary so the keyring won't recognize the
  reader as being the same as the write so it may ask for the user's
  password. I may add an override to disable this or allow
  users/enterprises to opt-out of the keyring storage if it causes issues.
  
  <img width="5064" height="686" alt="CleanShot 2025-09-30 at 19 31 40"
  src="https://github.com/user-attachments/assets/9573f9b4-07f1-4160-83b8-2920db287e2d"
  />
  <img width="745" height="486" alt="image"
  src="https://github.com/user-attachments/assets/9562649b-ea5f-4f22-ace2-d0cb438b143e"
  />

  Gabriel Peal · 2025-10-03 13:43:12 -04:00
  1d17ca1fa3
• 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
• Separate interactive and non-interactive sessions (#4612)

  Do not show exec session in VSCode/TUI selector.

  pakrym-oai · 2025-10-02 13:06:21 -07:00
  4c566d484a
• show "Viewed Image" when the model views an image (#4475)

  <img width="1022" height="339" alt="Screenshot 2025-09-29 at 4 22 00 PM"
  src="https://github.com/user-attachments/assets/12da7358-19be-4010-a71b-496ede6dfbbf"
  />

  Jeremy Rose · 2025-10-02 18:36:03 +00:00
  45936f8fbd
• fix: remove mcp-types from app server protocol (#4537)

  We continue the separation between `codex app-server` and `codex
  mcp-server`.
  
  In particular, we introduce a new crate, `codex-app-server-protocol`,
  and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it
  `codex-rs/app-server-protocol/src/protocol.rs`.
  
  Because `ConversationId` was defined in `mcp_protocol.rs`, we move it
  into its own file, `codex-rs/protocol/src/conversation_id.rs`, and
  because it is referenced in a ton of places, we have to touch a lot of
  files as part of this PR.
  
  We also decide to get away from proper JSON-RPC 2.0 semantics, so we
  also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which
  is basically the same `JSONRPCMessage` type defined in `mcp-types`
  except with all of the `"jsonrpc": "2.0"` removed.
  
  Getting rid of `"jsonrpc": "2.0"` makes our serialization logic
  considerably simpler, as we can lean heavier on serde to serialize
  directly into the wire format that we use now.

  Michael Bolin · 2025-10-01 02:16:26 +00:00
  5881c0d6d4
• fix: use macros to ensure request/response symmetry (#4529)

  Manually curating `protocol-ts/src/lib.rs` was error-prone, as expected.
  I finally asked Codex to write some Rust macros so we can ensure that:
  
  - For every variant of `ClientRequest` and `ServerRequest`, there is an
  associated `params` and `response` type.
  - All response types are included automatically in the output of `codex
  generate-ts`.

  Michael Bolin · 2025-09-30 18:06:05 -07:00
  32853ecbc5
• fix: ensure every variant of ClientRequest has a params field (#4512)

  This ensures changes the generated TypeScript type for `ClientRequest`
  so that instead of this:
  
  ```typescript
  /**
   * Request from the client to the server.
   */
  export type ClientRequest =
    | { method: "initialize"; id: RequestId; params: InitializeParams }
    | { method: "newConversation"; id: RequestId; params: NewConversationParams }
    // ...
    | { method: "getUserAgent"; id: RequestId }
    | { method: "userInfo"; id: RequestId }
    // ...
  ```
  
  we have this:
  
  ```typescript
  /**
   * Request from the client to the server.
   */
  export type ClientRequest =
    | { method: "initialize"; id: RequestId; params: InitializeParams }
    | { method: "newConversation"; id: RequestId; params: NewConversationParams }
    // ...
    | { method: "getUserAgent"; id: RequestId; params: undefined }
    | { method: "userInfo"; id: RequestId; params: undefined }
    // ...
  ```
  
  which makes TypeScript happier when it comes to destructuring instances
  of `ClientRequest` because it does not complain about `params` not being
  guaranteed to exist anymore.

  Michael Bolin · 2025-09-30 12:03:32 -07:00
  6910be3224
• fix: separate codex mcp into codex mcp-server and codex app-server (#4471)

  This is a very large PR with some non-backwards-compatible changes.
  
  Historically, `codex mcp` (or `codex mcp serve`) started a JSON-RPC-ish
  server that had two overlapping responsibilities:
  
  - Running an MCP server, providing some basic tool calls.
  - Running the app server used to power experiences such as the VS Code
  extension.
  
  This PR aims to separate these into distinct concepts:
  
  - `codex mcp-server` for the MCP server
  - `codex app-server` for the "application server"
  
  Note `codex mcp` still exists because it already has its own subcommands
  for MCP management (`list`, `add`, etc.)
  
  The MCP logic continues to live in `codex-rs/mcp-server` whereas the
  refactored app server logic is in the new `codex-rs/app-server` folder.
  Note that most of the existing integration tests in
  `codex-rs/mcp-server/tests/suite` were actually for the app server, so
  all the tests have been moved with the exception of
  `codex-rs/mcp-server/tests/suite/mod.rs`.
  
  Because this is already a large diff, I tried not to change more than I
  had to, so `codex-rs/app-server/tests/common/mcp_process.rs` still uses
  the name `McpProcess` for now, but I will do some mechanical renamings
  to things like `AppServer` in subsequent PRs.
  
  While `mcp-server` and `app-server` share some overlapping functionality
  (like reading streams of JSONL and dispatching based on message types)
  and some differences (completely different message types), I ended up
  doing a bit of copypasta between the two crates, as both have somewhat
  similar `message_processor.rs` and `outgoing_message.rs` files for now,
  though I expect them to diverge more in the near future.
  
  One material change is that of the initialize handshake for `codex
  app-server`, as we no longer use the MCP types for that handshake.
  Instead, we update `codex-rs/protocol/src/mcp_protocol.rs` to add an
  `Initialize` variant to `ClientRequest`, which takes the `ClientInfo`
  object we need to update the `USER_AGENT_SUFFIX` in
  `codex-rs/app-server/src/message_processor.rs`.
  
  One other material change is in
  `codex-rs/app-server/src/codex_message_processor.rs` where I eliminated
  a use of the `send_event_as_notification()` method I am generally trying
  to deprecate (because it blindly maps an `EventMsg` into a
  `JSONNotification`) in favor of `send_server_notification()`, which
  takes a `ServerNotification`, as that is intended to be a custom enum of
  all notification types supported by the app server. So to make this
  update, I had to introduce a new variant of `ServerNotification`,
  `SessionConfigured`, which is a non-backwards compatible change with the
  old `codex mcp`, and clients will have to be updated after the next
  release that contains this PR. Note that
  `codex-rs/app-server/tests/suite/list_resume.rs` also had to be update
  to reflect this change.
  
  I introduced `codex-rs/utils/json-to-toml/src/lib.rs` as a small utility
  crate to avoid some of the copying between `mcp-server` and
  `app-server`.

  Michael Bolin · 2025-09-30 07:06:18 +00:00
  d9dbf48828
• Custom prompts begin with /prompts: (#4476)

  <img width="608" height="354" alt="Screenshot 2025-09-29 at 4 41 08 PM"
  src="https://github.com/user-attachments/assets/162508eb-c1ac-4bc0-95f2-5e23cb4ae428"
  />

  dedrisian-oai · 2025-09-29 17:58:16 -07:00
  bf76258cdc