42 Commits

• fix: artifacts from previous frames were bleeding through in TUI (#989)

  Prior to this PR, I would frequently see glyphs from previous frames
  "bleed" through like this:
  
  
  ![image](https://github.com/user-attachments/assets/8784b3d7-f691-4df6-8666-34e2f134ee85)
  
  I think this was due to two issues (now addressed in this PR):
  
  * We were not making use of `ratatui::widgets::Clear` to clear out the
  buffer before drawing into it.
  * To calculate the `width` used with `wrapped_line_count_for_cell()`, we
  were not accounting for the scrollbar.
  * Now we calculate `effective_width` using
  `inner.width.saturating_sub(1)` where the `1` is for the scrollbar.
  * We compute `text_area` using `effective_with` and pass the `text_area`
  to `paragraph.render()`.
  * We eliminate the conditional `needs_scrollbar` check and always call
  `render(Scrollbar)`
  
  I suspect this bug was introduced in
  https://github.com/openai/codex/pull/937, though I did not try to
  verify: I'm just happy that it appears to be fixed!

  Michael Bolin · 2025-05-17 10:51:11 -07:00
  1c6a3f1097
• fix: ensure the first user message always displays after the session info (#988)

  Previously, if the first user message was sent with the command
  invocation, e.g.:
  
  ```
  $ cargo run --bin codex 'hello'
  ```
  
  Then the user message was added as the first entry in the history and
  then `is_first_event` would be `false` here:
  
  
  https://github.com/openai/codex/blob/031df77dfb9248fe47b40ec52bf8b05052231722/codex-rs/tui/src/conversation_history_widget.rs#L178-L179
  
  which would prevent the "welcome" message with things like the the model
  version from displaying.
  
  The fix in this PR is twofold:
  
  * Reorganize the logic so the `ChatWidget` constructor stores
  `initial_user_message` rather than sending it right away. Now inside
  `handle_codex_event()`, it waits for the `SessionConfigured` event and
  sends the `initial_user_message`, if it exists.
  * In `conversation_history_widget.rs`, `add_session_info()` checks to
  see whether a `WelcomeMessage` exists in the history when determining
  the value of `has_welcome_message`. By construction, we expect that
  `WelcomeMessage` is always the first message (in which case the existing
  `let is_first_event = self.entries.is_empty();` logic would be sound),
  but we decide to be extra defensive in case an `EventMsg::Error` is
  processed before `EventMsg::SessionConfigured`.

  Michael Bolin · 2025-05-17 09:00:23 -07:00
  f8b6b1db81
• fix: do not let Tab keypress flow through to composer when used to toggle focus (#977)

  One line fix from Codex!

  Michael Bolin · 2025-05-16 19:27:49 -07:00
  f9143d0361
• feat: make it possible to toggle mouse mode in the Rust TUI (#971)

  I did a bit of research to understand why I could not use my mouse to
  drag to select text to copy to the clipboard in iTerm.
  
  Apparently https://github.com/openai/codex/pull/641 to enable mousewheel
  scrolling broke this functionality. It seems that, unless we put in a
  bit of effort, we can have drag-to-select or scrolling, but not both.
  Though if you know the trick to hold down `Option` will dragging with
  the mouse in iTerm, you can probably get by with this. (I did not know
  about this option prior to researching this issue.)
  
  Nevertheless, users may still prefer to disable mouse capture
  altogether, so this PR introduces:
  
  * the ability to set `tui.disable_mouse_capture = true` in `config.toml`
  to disable mouse capture
  * a new command, `/toggle-mouse-mode` to toggle mouse capture

  Michael Bolin · 2025-05-16 16:16:50 -07:00
  7ca84087e6
• fix: use text other than 'TODO' as test example (#969)

  I casually `rg TODO` to look for TODOs, so the use of TODO in a sample
  string in test output was throwing things off.

  Michael Bolin · 2025-05-16 14:51:03 -07:00
  67ac8ef605
• feat: add support for file_opener option in Rust, similiar to #911 (#957)

  This ports the enhancement introduced in
  https://github.com/openai/codex/pull/911 (and the fixes in
  https://github.com/openai/codex/pull/919) for the TypeScript CLI to the
  Rust one.

  Michael Bolin · 2025-05-16 11:33:08 -07:00
  1e39189393
• feat: record messages from user in ~/.codex/history.jsonl (#939)

  This is a large change to support a "history" feature like you would
  expect in a shell like Bash.
  
  History events are recorded in `$CODEX_HOME/history.jsonl`. Because it
  is a JSONL file, it is straightforward to append new entries (as opposed
  to the TypeScript file that uses `$CODEX_HOME/history.json`, so to be
  valid JSON, each new entry entails rewriting the entire file). Because
  it is possible for there to be multiple instances of Codex CLI writing
  to `history.jsonl` at once, we use advisory file locking when working
  with `history.jsonl` in `codex-rs/core/src/message_history.rs`.
  
  Because we believe history is a sufficiently useful feature, we enable
  it by default. Though to provide some safety, we set the file
  permissions of `history.jsonl` to be `o600` so that other users on the
  system cannot read the user's history. We do not yet support a default
  list of `SENSITIVE_PATTERNS` as the TypeScript CLI does:
  
  
  https://github.com/openai/codex/blob/3fdf9df1335ac9501e3fb0e61715359145711e8b/codex-cli/src/utils/storage/command-history.ts#L10-L17
  
  We are going to take a more conservative approach to this list in the
  Rust CLI. For example, while `/\b[A-Za-z0-9-_]{20,}\b/` might exclude
  sensitive information like API tokens, it would also exclude valuable
  information such as references to Git commits.
  
  As noted in the updated documentation, users can opt-out of history by
  adding the following to `config.toml`:
  
  ```toml
  [history]
  persistence = "none" 
  ```
  
  Because `history.jsonl` could, in theory, be quite large, we take a[n
  arguably overly pedantic] approach in reading history entries into
  memory. Specifically, we start by telling the client the current number
  of entries in the history file (`history_entry_count`) as well as the
  inode (`history_log_id`) of `history.jsonl` (see the new fields on
  `SessionConfiguredEvent`).
  
  The client is responsible for keeping new entries in memory to create a
  "local history," but if the user hits up enough times to go "past" the
  end of local history, then the client should use the new
  `GetHistoryEntryRequest` in the protocol to fetch older entries.
  Specifically, it should pass the `history_log_id` it was given
  originally and work backwards from `history_entry_count`. (It should
  really fetch history in batches rather than one-at-a-time, but that is
  something we can improve upon in subsequent PRs.)
  
  The motivation behind this crazy scheme is that it is designed to defend
  against:
  
  * The `history.jsonl` being truncated during the session such that the
  index into the history is no longer consistent with what had been read
  up to that point. We do not yet have logic to enforce a `max_bytes` for
  `history.jsonl`, but once we do, we will aspire to implement it in a way
  that should result in a new inode for the file on most systems.
  * New items from concurrent Codex CLI sessions amending to the history.
  Because, in absence of truncation, `history.jsonl` is an append-only
  log, so long as the client reads backwards from `history_entry_count`,
  it should always get a consistent view of history. (That said, it will
  not be able to read _new_ commands from concurrent sessions, but perhaps
  we will introduce a `/` command to reload latest history or something
  down the road.)
  
  Admittedly, my testing of this feature thus far has been fairly light. I
  expect we will find bugs and introduce enhancements/fixes going forward.

  Michael Bolin · 2025-05-15 16:26:23 -07:00
  ce2ecbe72f
• chore: introduce AppEventSender to help fix clippy warnings and update to Rust 1.87 (#948)

  Moving to Rust 1.87 introduced a clippy warning that
  `SendError<AppEvent>` was too large.
  
  In practice, the only thing we ever did when we got this error was log
  it (if the mspc channel is closed, then the app is likely shutting down
  or something, so there's not much to do...), so this finally motivated
  me to introduce `AppEventSender`, which wraps
  `std::sync::mpsc::Sender<AppEvent>` with a `send()` method that invokes
  `send()` on the underlying `Sender` and logs an `Err` if it gets one.
  
  This greatly simplifies the code, as many functions that previously
  returned `Result<(), SendError<AppEvent>>` now return `()`, so we don't
  have to propagate an `Err` all over the place that we don't really
  handle, anyway.
  
  This also makes it so we can upgrade to Rust 1.87 in CI.

  Michael Bolin · 2025-05-15 14:50:30 -07:00
  3fdf9df133
• chore: expose codex_home via Config (#941)
  Michael Bolin · 2025-05-15 00:30:13 -07:00
  5fc9fc3e3e
• fix: properly wrap lines in the Rust TUI (#937)

  As discussed on
  https://github.com/openai/codex/commit/699ec5a87f09796d17c0202cd92a1dd4d8b4f3f5#commitcomment-156776835,
  to properly support scrolling long content in Ratatui for a sequence of
  cells, we need to:
  
  * take the `Vec<Line>` for each cell
  * using the wrapping logic we want to use at render time, compute the
  _effective line count_ using `Paragraph::line_count()` (see
  `wrapped_line_count_for_cell()` in this PR)
  * sum up the effective line count to compute the height of the area
  being scrolled
  * given a `scroll_position: usize`, index into the list of "effective
  lines" and accumulate the appropriate `Vec<Line>` for the cells that
  should be displayed
  * take that `Vec<Line>` to create a `Paragraph` and use the same
  line-wrapping policy that was used in `wrapped_line_count_for_cell()`
  * display the resulting `Paragraph` and use the accounting to display a
  scrollbar with the appropriate thumb size and offset without having to
  render the `Vec<Line>` for the full history
  
  With this change, lines wrap as I expect and everything appears to
  redraw correctly as I resize my terminal!

  Michael Bolin · 2025-05-14 16:51:41 -07:00
  0b9ef93da5
• feat: add mcp subcommand to CLI to run Codex as an MCP server (#934)

  Previously, running Codex as an MCP server required a standalone binary
  in our Cargo workspace, but this PR makes it available as a subcommand
  (`mcp`) of the main CLI.
  
  Ran this with:
  
  ```
  RUST_LOG=debug npx @modelcontextprotocol/inspector cargo run --bin codex -- mcp
  ```
  
  and verified it worked as expected in the inspector at
  `http://127.0.0.1:6274/`.

  Michael Bolin · 2025-05-14 13:15:41 -07:00
  497c5396c0
• feat: add support for commands in the Rust TUI (#935)

  Introduces support for slash commands like in the TypeScript CLI. We do
  not support the full set of commands yet, but the core abstraction is
  there now.
  
  In particular, we have a `SlashCommand` enum and due to thoughtful use
  of the [strum](https://crates.io/crates/strum) crate, it requires
  minimal boilerplate to add a new command to the list.
  
  The key new piece of UI is `CommandPopup`, though the keyboard events
  are still handled by `ChatComposer`. The behavior is roughly as follows:
  
  * if the first character in the composer is `/`, the command popup is
  displayed (if you really want to send a message to Codex that starts
  with a `/`, simply put a space before the `/`)
  * while the popup is displayed, up/down can be used to change the
  selection of the popup
  * if there is a selection, hitting tab completes the command, but does
  not send it
  * if there is a selection, hitting enter sends the command
  * if the prefix of the composer matches a command, the command will be
  visible in the popup so the user can see the description (commands could
  take arguments, so additional text may appear after the command name
  itself)
  
  
  https://github.com/user-attachments/assets/39c3e6ee-eeb7-4ef7-a911-466d8184975f
  
  Incidentally, Codex wrote almost all the code for this PR!

  Michael Bolin · 2025-05-14 12:55:49 -07:00
  a12e4b0b31
• chore: move each view used in BottomPane into its own file (#928)

  `BottomPane` was getting a bit unwieldy because it maintained a
  `PaneState` enum with three variants and many of its methods had `match`
  statements to handle each variant. To replace the enum, this PR:
  
  * Introduces a `trait BottomPaneView` that has two implementations:
  `StatusIndicatorView` and `ApprovalModalView`.
  * Migrates `PaneState::TextInput` into its own struct, `ChatComposer`,
  that does **not** implement `BottomPaneView`.
  * Updates `BottomPane` so it has `composer: ChatComposer` and
  `active_view: Option<Box<dyn BottomPaneView<'a> + 'a>>`. The idea is
  that `active_view` takes priority and is displayed when it is `Some`;
  otherwise, `ChatComposer` is displayed.
  * While methods of `BottomPane` often have to check whether
  `active_view` is present to decide which component to delegate to, the
  code is more straightforward than before and introducing new
  implementations of `BottomPaneView` should be less painful.
  
  Because we want to retain the `TextArea` owned by `ChatComposer` even
  when another view is displayed, to keep the ownership logic simple, it
  seemed best to keep `ChatComposer` distinct from `BottomPaneView`.

  Michael Bolin · 2025-05-14 10:13:29 -07:00
  0402aef126
• feat: Ctrl+J for newline in Rust TUI, default to one line of height (#926)

  While the `TextArea` used in the Rust TUI is "multiline," it is not like
  an HTML `<textarea>` in that it does not wrap, so there was not much
  benefit to setting `MIN_TEXTAREA_ROWS` to `3`, so this PR changes it to
  `1`. Though there are now three ways to "increase" the height due to
  actual linebreaks:
  
  * paste in multiline content (this worked before this PR)
  * pressing `Ctrl+J` will insert a newline
  * if you have your terminal emulator set such that it is possible to
  press something that `crossterm` interprets as "Enter plus some
  modifier," then now that will also work
  
  Now things look a bit more compact on startup:
  
  <img width="745" alt="image"
  src="https://github.com/user-attachments/assets/86e2857f-f31c-46f5-a80b-1ab2120b266e"
  />

  Michael Bolin · 2025-05-13 21:42:14 -07:00
  1bf00a3a95
• fix: change EventMsg enum so every variant takes a single struct (#925)

  https://github.com/openai/codex/pull/922 did this for the
  `SessionConfigured` enum variant, and I think it is generally helpful to
  be able to work with the values as each enum variant as their own type,
  so this converts the remaining variants and updates all of the
  callsites.
  
  Added a simple unit test to verify that the JSON-serialized version of
  `Event` does not have any unexpected nesting.

  Michael Bolin · 2025-05-13 20:44:42 -07:00
  a5f3a34827
• fix: tighten up some logic around session timestamps and ids (#922)

  * update `SessionConfigured` event to include the UUID for the session
  * show the UUID in the Rust TUI
  * use local timestamps in log files instead of UTC
  * include timestamps in log file names for easier discovery

  Michael Bolin · 2025-05-13 19:22:16 -07:00
  e6c206d19d
• feat: introduce --profile for Rust CLI (#921)

  This introduces a much-needed "profile" concept where users can specify
  a collection of options under one name and then pass that via
  `--profile` to the CLI.
  
  This PR introduces the `ConfigProfile` struct and makes it a field of
  `CargoToml`. It further updates
  `Config::load_from_base_config_with_overrides()` to respect
  `ConfigProfile`, overriding default values where appropriate. A detailed
  unit test is added at the end of `config.rs` to verify this behavior.
  
  Details on how to use this feature have also been added to
  `codex-rs/README.md`.

  Michael Bolin · 2025-05-13 16:52:52 -07:00
  3c03c25e56
• fix: use "thinking" instead of "codex reasoning" as the label for reasoning events in the TUI (#905)
  Michael Bolin · 2025-05-12 15:19:45 -07:00
  55142e3e6c
• fix: fix border style for BottomPane (#893)

  This PR fixes things so that:
  
  * when the `BottomPane` is in the `StatusIndicator` state, the border
  should be dim
  * when the `BottomPane` does not have input focus, the border should be
  dim
  
  To make it easier to enforce this invariant, this PR introduces
  `BottomPane::set_state()` that will:
  
  * update `self.state`
  * call `update_border_for_input_focus()`
  * request a repaint
  
  This should make it easier to enforce other updates for state changes
  going forward.

  Michael Bolin · 2025-05-10 23:34:13 -07:00
  a1f51bf91b
• feat: include "reasoning" messages in Rust TUI (#892)

  As shown in the screenshot, we now include reasoning messages from the
  model in the TUI under the heading "codex reasoning":
  
  
  ![image](https://github.com/user-attachments/assets/d8eb3dc3-2f9f-4e95-847e-d24b421249a8)
  
  To ensure these are visible by default when using `o4-mini`, this also
  changes the default value for `summary` (formerly `generate_summary`,
  which is deprecated in favor of `summary` according to the docs) from
  unset to `"auto"`.

  Michael Bolin · 2025-05-10 21:43:27 -07:00
  b4785b5f88
• feat: Allow pasting newlines (#866)

  Noticed that when pasting multi-line blocks, each newline was treated
  like a new submission.
  Update tui to handle Paste directly and map newlines to shift+enter.
  
  # Test
  
  Copied this into clipboard:
  ```
  Do nothing.
  Explain this repo to me.
  ```
  
  Pasted in and saw multi-line input. Hitting Enter then submitted the
  full block.

  jcoens-openai · 2025-05-09 11:33:46 -07:00
  78843c3940
• feat: support the chat completions API in the Rust CLI (#862)

  This is a substantial PR to add support for the chat completions API,
  which in turn makes it possible to use non-OpenAI model providers (just
  like in the TypeScript CLI):
  
  * It moves a number of structs from `client.rs` to `client_common.rs` so
  they can be shared.
  * It introduces support for the chat completions API in
  `chat_completions.rs`.
  * It updates `ModelProviderInfo` so that `env_key` is `Option<String>`
  instead of `String` (for e.g., ollama) and adds a `wire_api` field
  * It updates `client.rs` to choose between `stream_responses()` and
  `stream_chat_completions()` based on the `wire_api` for the
  `ModelProviderInfo`
  * It updates the `exec` and TUI CLIs to no longer fail if the
  `OPENAI_API_KEY` environment variable is not set
  * It updates the TUI so that `EventMsg::Error` is displayed more
  prominently when it occurs, particularly now that it is important to
  alert users to the `CodexErr::EnvVar` variant.
  * `CodexErr::EnvVar` was updated to include an optional `instructions`
  field so we can preserve the behavior where we direct users to
  https://platform.openai.com if `OPENAI_API_KEY` is not set.
  * Cleaned up the "welcome message" in the TUI to ensure the model
  provider is displayed.
  * Updated the docs in `codex-rs/README.md`.
  
  To exercise the chat completions API from OpenAI models, I added the
  following to my `config.toml`:
  
  ```toml
  model = "gpt-4o"
  model_provider = "openai-chat-completions"
  
  [model_providers.openai-chat-completions]
  name = "OpenAI using Chat Completions"
  base_url = "https://api.openai.com/v1"
  env_key = "OPENAI_API_KEY"
  wire_api = "chat"
  ```
  
  Though to test a non-OpenAI provider, I installed ollama with mistral
  locally on my Mac because ChatGPT said that would be a good match for my
  hardware:
  
  ```shell
  brew install ollama
  ollama serve
  ollama pull mistral
  ```
  
  Then I added the following to my `~/.codex/config.toml`:
  
  ```toml
  model = "mistral"
  model_provider = "ollama"
  ```
  
  Note this code could certainly use more test coverage, but I want to get
  this in so folks can start playing with it.
  
  For reference, I believe https://github.com/openai/codex/pull/247 was
  roughly the comparable PR on the TypeScript side.

  Michael Bolin · 2025-05-08 21:46:06 -07:00
  e924070cee
• fix: remove wrapping in Rust TUI that was incompatible with scrolling math (#868)

  I noticed that sometimes I would enter a new message, but it would not
  show up in the conversation history. Even if I focused the conversation
  history and tried to scroll it to the bottom, I could not bring it into
  view. At first, I was concerned that messages were not making it to the
  UI layer, but I added debug statements and verified that was not the
  issue.
  
  It turned out that, previous to this PR, lines that are wider than the
  viewport take up multiple lines of vertical space because `wrap()` was
  set on the `Paragraph` inside the scroll pane. Unfortunately, that broke
  our "scrollbar math" that assumed each `Line` contributes one line of
  height in the UI.
  
  This PR removes the `wrap()`, but introduces a new issue, which is that
  now you cannot see long lines without resizing your terminal window. For
  now, I filed an issue here:
  
  https://github.com/openai/codex/issues/869
  
  I think the long-term fix is to fix our math so it calculates the height
  of a `Line` after it is wrapped given the current width of the viewport.

  Michael Bolin · 2025-05-08 15:17:17 -07:00
  699ec5a87f
• Workspace lints and disallow unwrap (#855)

  Sets submodules to use workspace lints. Added denying unwrap as a
  workspace level lint, which found a couple of cases where we could have
  propagated errors. Also manually labeled ones that were fine by my eye.

  jcoens-openai · 2025-05-08 09:46:18 -07:00
  87cf120873
• feat: read model_provider and model_providers from config.toml (#853)

  This is the first step in supporting other model providers in the Rust
  CLI. Specifically, this PR adds support for the new entries in `Config`
  and `ConfigOverrides` to specify a `ModelProviderInfo`, which is the
  basic config needed for an LLM provider. This PR does not get us all the
  way there yet because `client.rs` still categorically appends
  `/responses` to the URL and expects the endpoint to support the OpenAI
  Responses API. Will fix that next!

  Michael Bolin · 2025-05-07 17:38:28 -07:00
  86022f097e
• feat: introduce the use of tui-markdown (#851)

  This introduces the use of the `tui-markdown` crate to parse an
  assistant message as Markdown and style it using ANSI for a better user
  experience. As shown in the screenshot below, it has support for syntax
  highlighting for _tagged_ fenced code blocks:
  
  <img width="907" alt="image"
  src="https://github.com/user-attachments/assets/900dc229-80bb-46e8-b1bb-efee4c70ba3c"
  />
  
  That said, `tui-markdown` is not as configurable (or stylish!) as
  https://www.npmjs.com/package/marked-terminal, which is what we use in
  the TypeScript CLI. In particular:
  
  * The styles are hardcoded and `tui_markdown::from_str()` does not take
  any options whatsoever. It uses "bold white" for inline code style which
  does not stand out as much as the yellow used by `marked-terminal`:
  
  
  https://github.com/joshka/tui-markdown/blob/65402cbda70325f34e7ddf6fe1ec629bcd9459cf/tui-markdown/src/lib.rs#L464
  
  I asked Codex to take a first pass at this and it came up with:
  
  https://github.com/joshka/tui-markdown/pull/80
  
  * If a fenced code block is not tagged, then it does not get
  highlighted. I would rather add some logic here:
  
  
  https://github.com/joshka/tui-markdown/blob/65402cbda70325f34e7ddf6fe1ec629bcd9459cf/tui-markdown/src/lib.rs#L262
  
  that uses something like https://pypi.org/project/guesslang/ to examine
  the value of `text` and try to use the appropriate syntax highlighter.
  
  * When we have a fenced code block, we do not want to show the opening
  and closing triple backticks in the output.
  
  To unblock ourselves, we might want to bundle our own fork of
  `tui-markdown` temporarily until we figure out what the shape of the API
  should be and then try to upstream it.

  Michael Bolin · 2025-05-07 10:46:32 -07:00
  0360b4d0d7
• Update cargo to 2024 edition (#842)

  Some effects of this change:
  - New formatting changes across many files. No functionality changes
  should occur from that.
  - Calls to `set_env` are considered unsafe, since this only happens in
  tests we wrap them in `unsafe` blocks

  jcoens-openai · 2025-05-07 08:37:48 -07:00
  8a89d3aeda
• chore: introduce codex-common crate (#843)

  I started this PR because I wanted to share the `format_duration()`
  utility function in `codex-rs/exec/src/event_processor.rs` with the TUI.
  The question was: where to put it?
  
  `core` should have as few dependencies as possible, so moving it there
  would introduce a dependency on `chrono`, which seemed undesirable.
  `core` already had this `cli` feature to deal with a similar situation
  around sharing common utility functions, so I decided to:
  
  * make `core` feature-free
  * introduce `common`
  * `common` can have as many "special interest" features as it needs,
  each of which can declare their own deps
  * the first two features of common are `cli` and `elapsed`
  
  In practice, this meant updating a number of `Cargo.toml` files,
  replacing this line:
  
  ```toml
  codex-core = { path = "../core", features = ["cli"] }
  ```
  
  with these:
  
  ```toml
  codex-core = { path = "../core" }
  codex-common = { path = "../common", features = ["cli"] }
  ```
  
  Moving `format_duration()` into its own file gave it some "breathing
  room" to add a unit test, so I had Codex generate some tests and new
  support for durations over 1 minute.

  Michael Bolin · 2025-05-06 17:38:56 -07:00
  c577e94b67
• feat: drop support for q in the Rust TUI since we already support ctrl+d (#799)

  Out of the box, we will make `/` the only official "escape sequence" for
  commands in the Rust TUI. We will look to support `q` (or any string you
  want to use as a "macro") via a plugin, but not make it part of the
  default experience.
  
  Existing `q` users will have to get by with `ctrl+d` for now.

  Michael Bolin · 2025-05-06 16:34:17 -07:00
  6f87f4c69f
• feat: show MCP tool calls in TUI (#836)

  Adds logic for the `McpToolCallBegin` and `McpToolCallEnd` events in
  `codex-rs/tui/src/chatwidget.rs` so they get entries in the conversation
  history in the TUI.
  
  Building on top of https://github.com/openai/codex/pull/829, here is the
  result of running:
  
  ```
  cargo run --bin codex -- 'what is the weather in san francisco tomorrow'
  ```
  
  
  ![image](https://github.com/user-attachments/assets/db4a79bb-4988-46cb-acb2-446d5ba9e058)

  Michael Bolin · 2025-05-06 16:12:15 -07:00
  88e7ca5f2b
• fix: is_inside_git_repo should take the directory as a param (#809)

  https://github.com/openai/codex/pull/800 made `cwd` a property of
  `Config` and made it so the `cwd` is not necessarily
  `std::env::current_dir()`. As such, `is_inside_git_repo()` should check
  `Config.cwd` rather than `std::env::current_dir()`.
  
  This PR updates `is_inside_git_repo()` to take `Config` instead of an
  arbitrary `PathBuf` to force the check to operate on a `Config` where
  `cwd` has been resolved to what the user specified.

  Michael Bolin · 2025-05-04 11:39:10 -07:00
  a134bdde49
• fix: TUI should use cwd from Config (#808)

  https://github.com/openai/codex/pull/800 made `cwd` a property of
  `Config`, so the TUI should use this instead of running
  `std::env::current_dir()`.

  Michael Bolin · 2025-05-04 11:12:40 -07:00
  cd12f0c24a
• feat: make cwd a required field of Config so we stop assuming std::env::current_dir() in a session (#800)

  In order to expose Codex via an MCP server, I realized that we should be
  taking `cwd` as a parameter rather than assuming
  `std::env::current_dir()` as the `cwd`. Specifically, the user may want
  to start a session in a directory other than the one where the MCP
  server has been started.
  
  This PR makes `cwd: PathBuf` a required field of `Session` and threads
  it all the way through, though I think there is still an issue with not
  honoring `workdir` for `apply_patch`, which is something we also had to
  fix in the TypeScript version: https://github.com/openai/codex/pull/556.
  
  This also adds `-C`/`--cd` to change the cwd via the command line.
  
  To test, I ran:
  
  ```
  cargo run --bin codex -- exec -C /tmp 'show the output of ls'
  ```
  
  and verified it showed the contents of my `/tmp` folder instead of
  `$PWD`.

  Michael Bolin · 2025-05-04 10:57:12 -07:00
  421e159888
• feat: bring back -s option to specify sandbox permissions (#739)
  Michael Bolin · 2025-04-29 18:42:52 -07:00
  27bc4516bf
• fix: overhaul SandboxPolicy and config loading in Rust (#732)

  Previous to this PR, `SandboxPolicy` was a bit difficult to work with:
  
  
  https://github.com/openai/codex/blob/237f8a11e11fdcc793a09e787e48215676d9b95b/codex-rs/core/src/protocol.rs#L98-L108
  
  Specifically:
  
  * It was an `enum` and therefore options were mutually exclusive as
  opposed to additive.
  * It defined things in terms of what the agent _could not_ do as opposed
  to what they _could_ do. This made things hard to support because we
  would prefer to build up a sandbox config by starting with something
  extremely restrictive and only granting permissions for things the user
  as explicitly allowed.
  
  This PR changes things substantially by redefining the policy in terms
  of two concepts:
  
  * A `SandboxPermission` enum that defines permissions that can be
  granted to the agent/sandbox.
  * A `SandboxPolicy` that internally stores a `Vec<SandboxPermission>`,
  but externally exposes a simpler API that can be used to configure
  Seatbelt/Landlock.
  
  Previous to this PR, we supported a `--sandbox` flag that effectively
  mapped to an enum value in `SandboxPolicy`. Though now that
  `SandboxPolicy` is a wrapper around `Vec<SandboxPermission>`, the single
  `--sandbox` flag no longer makes sense. While I could have turned it
  into a flag that the user can specify multiple times, I think the
  current values to use with such a flag are long and potentially messy,
  so for the moment, I have dropped support for `--sandbox` altogether and
  we can bring it back once we have figured out the naming thing.
  
  Since `--sandbox` is gone, users now have to specify `--full-auto` to
  get a sandbox that allows writes in `cwd`. Admittedly, there is no clean
  way to specify the equivalent of `--full-auto` in your `config.toml`
  right now, so we will have to revisit that, as well.
  
  Because `Config` presents a `SandboxPolicy` field and `SandboxPolicy`
  changed considerably, I had to overhaul how config loading works, as
  well. There are now two distinct concepts, `ConfigToml` and `Config`:
  
  * `ConfigToml` is the deserialization of `~/.codex/config.toml`. As one
  might expect, every field is `Optional` and it is `#[derive(Deserialize,
  Default)]`. Consistent use of `Optional` makes it clear what the user
  has specified explicitly.
  * `Config` is the "normalized config" and is produced by merging
  `ConfigToml` with `ConfigOverrides`. Where `ConfigToml` contains a raw
  `Option<Vec<SandboxPermission>>`, `Config` presents only the final
  `SandboxPolicy`.
  
  The changes to `core/src/exec.rs` and `core/src/linux.rs` merit extra
  special attention to ensure we are faithfully mapping the
  `SandboxPolicy` to the Seatbelt and Landlock configs, respectively.
  
  Also, take note that `core/src/seatbelt_readonly_policy.sbpl` has been
  renamed to `codex-rs/core/src/seatbelt_base_policy.sbpl` and that
  `(allow file-read*)` has been removed from the `.sbpl` file as now this
  is added to the policy in `core/src/exec.rs` when
  `sandbox_policy.has_full_disk_read_access()` is `true`.

  Michael Bolin · 2025-04-29 15:01:16 -07:00
  0a00b5ed29
• feat: make it possible to set disable_response_storage = true in config.toml (#714)

  https://github.com/openai/codex/pull/642 introduced support for the
  `--disable-response-storage` flag, but if you are a ZDR customer, it is
  tedious to set this every time, so this PR makes it possible to set this
  once in `config.toml` and be done with it.
  
  Incidentally, this tidies things up such that now `init_codex()` takes
  only one parameter: `Config`.

  Michael Bolin · 2025-04-28 15:39:34 -07:00
  e7ad9449ea
• fix: drop d as keyboard shortcut for scrolling in the TUI (#704)

  The existing `b` and `space` are sufficient and `d` and `u` default to
  half-page scrolling in `less`, so the way we supported `d` and `u`
  wasn't faithful to that, anyway:
  
  https://man7.org/linux/man-pages/man1/less.1.html
  
  If we decide to bring `d` and `u` back, they should probably match
  `less`?

  Michael Bolin · 2025-04-28 10:39:58 -07:00
  77e2918049
• feat: load defaults into Config and introduce ConfigOverrides (#677)

  This changes how instantiating `Config` works and also adds
  `approval_policy` and `sandbox_policy` as fields. The idea is:
  
  * All fields of `Config` have appropriate default values.
  * `Config` is initially loaded from `~/.codex/config.toml`, so values in
  `config.toml` will override those defaults.
  * Clients must instantiate `Config` via
  `Config::load_with_overrides(ConfigOverrides)` where `ConfigOverrides`
  has optional overrides that are expected to be settable based on CLI
  flags.
  
  The `Config` should be defined early in the program and then passed
  down. Now functions like `init_codex()` take fewer individual parameters
  because they can just take a `Config`.
  
  Also, `Config::load()` used to fail silently if `~/.codex/config.toml`
  had a parse error and fell back to the default config. This seemed
  really bad because it wasn't clear why the values in my `config.toml`
  weren't getting picked up. I changed things so that
  `load_with_overrides()` returns `Result<Config>` and verified that the
  various CLIs print a reasonable error if `config.toml` is malformed.
  
  Finally, I also updated the TUI to show which **sandbox** value is being
  used, as we do for other key values like **model** and **approval**.
  This was also a reminder that the various values of `--sandbox` are
  honored on Linux but not macOS today, so I added some TODOs about fixing
  that.

  Michael Bolin · 2025-04-27 21:47:50 -07:00
  4eda4dd772
• fix: write logs to ~/.codex/log instead of /tmp (#669)

  Previously, the Rust TUI was writing log files to `/tmp`, which is
  world-readable and not available on Windows, so that isn't great.
  
  This PR tries to clean things up by adding a function that provides the
  path to the "Codex config dir," e.g., `~/.codex` (though I suppose we
  could support `$CODEX_HOME` to override this?) and then defines other
  paths in terms of the result of `codex_dir()`.
  
  For example, `log_dir()` returns the folder where log files should be
  written which is defined in terms of `codex_dir()`. I updated the TUI to
  use this function. On UNIX, we even go so far as to `chmod 600` the log
  file by default, though as noted in a comment, it's a bit tedious to do
  the equivalent on Windows, so we just let that go for now.
  
  This also changes the default logging level to `info` for `codex_core`
  and `codex_tui` when `RUST_LOG` is not specified. I'm not really sure if
  we should use a more verbose default (it may be helpful when debugging
  user issues), though if so, we should probably also set up log rotation?

  Michael Bolin · 2025-04-25 17:37:41 -07:00
  b0ba65a936
• feat: add ZDR support to Rust implementation (#642)

  This adds support for the `--disable-response-storage` flag across our
  multiple Rust CLIs to support customers who have opted into Zero-Data
  Retention (ZDR). The analogous changes to the TypeScript CLI were:
  
  * https://github.com/openai/codex/pull/481
  * https://github.com/openai/codex/pull/543
  
  For a client using ZDR, `previous_response_id` will never be available,
  so the `input` field of an API request must include the full transcript
  of the conversation thus far. As such, this PR changes the type of
  `Prompt.input` from `Vec<ResponseInputItem>` to `Vec<ResponseItem>`.
  
  Practically speaking, `ResponseItem` was effectively a "superset" of
  `ResponseInputItem` already. The main difference for us is that
  `ResponseItem` includes the `FunctionCall` variant that we have to
  include as part of the conversation history in the ZDR case.
  
  Another key change in this PR is modifying `try_run_turn()` so that it
  returns the `Vec<ResponseItem>` for the turn in addition to the
  `Vec<ResponseInputItem>` produced by `try_run_turn()`. This is because
  the caller of `run_turn()` needs to record the `Vec<ResponseItem>` when
  ZDR is enabled.
  
  To that end, this PR introduces `ZdrTranscript` (and adds
  `zdr_transcript: Option<ZdrTranscript>` to `struct State` in `codex.rs`)
  to take responsibility for maintaining the conversation transcript in
  the ZDR case.

  Michael Bolin · 2025-04-25 12:08:18 -07:00
  b323d10ea7
• feat(tui-rs): add support for mousewheel scrolling (#641)

  It is intuitive to try to scroll the conversation history using the
  mouse in the TUI, but prior to this change, we only supported scrolling
  via keyboard events.
  
  This PR enables mouse capture upon initialization (and disables it on
  exit) such that we get `ScrollUp` and `ScrollDown` events in
  `codex-rs/tui/src/app.rs`. I initially mapped each event to scrolling by
  one line, but that felt sluggish. I decided to introduce
  `ScrollEventHelper` so we could debounce scroll events and measure the
  number of scroll events in a 100ms window to determine the "magnitude"
  of the scroll event. I put in a basic heuristic to start, but perhaps
  someone more motivated can play with it over time.
  
  `ScrollEventHelper` takes care of handling the atomic fields and thread
  management to ensure an `AppEvent::Scroll` event is pumped back through
  the event loop at the appropriate time with the accumulated delta.

  Michael Bolin · 2025-04-25 12:01:52 -07:00
  dc7b83666a
• feat: initial import of Rust implementation of Codex CLI in codex-rs/ (#629)

  As stated in `codex-rs/README.md`:
  
  Today, Codex CLI is written in TypeScript and requires Node.js 22+ to
  run it. For a number of users, this runtime requirement inhibits
  adoption: they would be better served by a standalone executable. As
  maintainers, we want Codex to run efficiently in a wide range of
  environments with minimal overhead. We also want to take advantage of
  operating system-specific APIs to provide better sandboxing, where
  possible.
  
  To that end, we are moving forward with a Rust implementation of Codex
  CLI contained in this folder, which has the following benefits:
  
  - The CLI compiles to small, standalone, platform-specific binaries.
  - Can make direct, native calls to
  [seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) and
  [landlock](https://man7.org/linux/man-pages/man7/landlock.7.html) in
  order to support sandboxing on Linux.
  - No runtime garbage collection, resulting in lower memory consumption
  and better, more predictable performance.
  
  Currently, the Rust implementation is materially behind the TypeScript
  implementation in functionality, so continue to use the TypeScript
  implmentation for the time being. We will publish native executables via
  GitHub Releases as soon as we feel the Rust version is usable.

  Michael Bolin · 2025-04-24 13:31:40 -07:00
  31d0d7a305