Commit Graph

145 Commits

  • Fix get_auth_status response when using custom provider (#3581)
    This PR addresses an edge-case bug that appears in the VS Code extension
    in the following situation:
    1. Log in using ChatGPT (using either the CLI or extension). This will
    create an `auth.json` file.
    2. Manually modify `config.toml` to specify a custom provider.
    3. Start a fresh copy of the VS Code extension.
    
    The profile menu in the VS Code extension will indicate that you are
    logged in using ChatGPT even though you're not.
    
    This is caused by the `get_auth_status` method returning an
    `auth_method: 'chatgpt'` when a custom provider is configured and it
    doesn't use OpenAI auth (i.e. `requires_openai_auth` is false). The
    method should always return `auth_method: None` if
    `requires_openai_auth` is false.
    
    The same bug also causes the NUX (new user experience) screen to be
    displayed in the VSCE in this situation.
  • Review Mode (Core) (#3401)
    ## 📝 Review Mode -- Core
    
    This PR introduces the Core implementation for Review mode:
    
    - New op `Op::Review { prompt: String }:` spawns a child review task
    with isolated context, a review‑specific system prompt, and a
    `Config.review_model`.
    - `EnteredReviewMode`: emitted when the child review session starts.
    Every event from this point onwards reflects the review session.
    - `ExitedReviewMode(Option<ReviewOutputEvent>)`: emitted when the review
    finishes or is interrupted, with optional structured findings:
    
    ```json
    {
      "findings": [
        {
          "title": "<≤ 80 chars, imperative>",
          "body": "<valid Markdown explaining *why* this is a problem; cite files/lines/functions>",
          "confidence_score": <float 0.0-1.0>,
          "priority": <int 0-3>,
          "code_location": {
            "absolute_file_path": "<file path>",
            "line_range": {"start": <int>, "end": <int>}
          }
        }
      ],
      "overall_correctness": "patch is correct" | "patch is incorrect",
      "overall_explanation": "<1-3 sentence explanation justifying the overall_correctness verdict>",
      "overall_confidence_score": <float 0.0-1.0>
    }
    ```
    
    ## Questions
    
    ### Why separate out its own message history?
    
    We want the review thread to match the training of our review models as
    much as possible -- that means using a custom prompt, removing user
    instructions, and starting a clean chat history.
    
    We also want to make sure the review thread doesn't leak into the parent
    thread.
    
    ### Why do this as a mode, vs. sub-agents?
    
    1. We want review to be a synchronous task, so it's fine for now to do a
    bespoke implementation.
    2. We're still unclear about the final structure for sub-agents. We'd
    prefer to land this quickly and then refactor into sub-agents without
    rushing that implementation.
  • feat: reasoning effort as optional (#3527)
    Allow the reasoning effort to be optional
  • feat: change the behavior of SetDefaultModel RPC so None clears the value. (#3529)
    It turns out that we want slightly different behavior for the
    `SetDefaultModel` RPC because some models do not work with reasoning
    (like GPT-4.1), so we should be able to explicitly clear this value.
    
    Verified in `codex-rs/mcp-server/tests/suite/set_default_model.rs`.
  • feat: added SetDefaultModel to JSON-RPC server (#3512)
    This adds `SetDefaultModel`, which takes `model` and `reasoning_effort`
    as optional fields. If set, the field will overwrite what is in the
    user's `config.toml`.
    
    This reuses logic that was added to support the `/model` command in the
    TUI: https://github.com/openai/codex/pull/2799.
  • feat: include reasoning_effort in NewConversationResponse (#3506)
    `ClientRequest::NewConversation` picks up the reasoning level from the user's defaults in `config.toml`, so it should be reported in `NewConversationResponse`.
  • chore: enable clippy::redundant_clone (#3489)
    Created this PR by:
    
    - adding `redundant_clone` to `[workspace.lints.clippy]` in
    `cargo-rs/Cargol.toml`
    - running `cargo clippy --tests --fix`
    - running `just fmt`
    
    Though I had to clean up one instance of the following that resulted:
    
    ```rust
    let codex = codex;
    ```
  • Simplify auth flow and reconcile differences between ChatGPT and API Key auth (#3189)
    This PR does the following:
    * Adds the ability to paste or type an API key.
    * Removes the `preferred_auth_method` config option. The last login
    method is always persisted in auth.json, so this isn't needed.
    * If OPENAI_API_KEY env variable is defined, the value is used to
    prepopulate the new UI. The env variable is otherwise ignored by the
    CLI.
    * Adds a new MCP server entry point "login_api_key" so we can implement
    this same API key behavior for the VS Code extension.
    <img width="473" height="140" alt="Screenshot 2025-09-04 at 3 51 04 PM"
    src="https://github.com/user-attachments/assets/c11bbd5b-8a4d-4d71-90fd-34130460f9d9"
    />
    <img width="726" height="254" alt="Screenshot 2025-09-04 at 3 51 32 PM"
    src="https://github.com/user-attachments/assets/6cc76b34-309a-4387-acbc-15ee5c756db9"
    />
  • Change forking to read the rollout from file (#3440)
    This PR changes get history op to get path. Then, forking will use a
    path. This will help us have one unified codepath for resuming/forking
    conversations. Will also help in having rollout history in order. It
    also fixes a bug where you won't see the UI when resuming after forking.
  • feat: add UserInfo request to JSON-RPC server (#3428)
    This adds a simple endpoint that provides the email address encoded in
    `$CODEX_HOME/auth.json`.
    
    As noted, for now, we do not hit the server to verify this is the user's
    true email address.
  • fix: ensure output of codex-rs/mcp-types/generate_mcp_types.py matches codex-rs/mcp-types/src/lib.rs (#3439)
    https://github.com/openai/codex/pull/3395 updated `mcp-types/src/lib.rs`
    by hand, but that file is generated code that is produced by
    `mcp-types/generate_mcp_types.py`. Unfortunately, we do not have
    anything in CI to verify this right now, but I will address that in a
    subsequent PR.
    
    #3395 ended up introducing a change that added a required field when
    deserializing `InitializeResult`, breaking Codex when used as an MCP
    client, so the quick fix in #3436 was to make the new field `Optional`
    with `skip_serializing_if = "Option::is_none"`, but that did not address
    the problem that `mcp-types/generate_mcp_types.py` and
    `mcp-types/src/lib.rs` are out of sync.
    
    This PR gets things back to where they are in sync. It removes the
    custom `mcp_types::McpClientInfo` type that was added to
    `mcp-types/src/lib.rs` and forces us to use the generated
    `mcp_types::Implementation` type. Though this PR also updates
    `generate_mcp_types.py` to generate the additional `user_agent:
    Optional<String>` field on `Implementation` so that we can continue to
    specify it when Codex operates as an MCP server.
    
    However, this also requires us to specify `user_agent: None` when Codex
    operates as an MCP client.
    
    We may want to introduce our own `InitializeResult` type that is
    specific to when we run as a server to avoid this in the future, but my
    immediate goal is just to get things back in sync.
  • Make user_agent optional (#3436)
    # External (non-OpenAI) Pull Request Requirements
    
    Currently, mcp server fail to start with:
    ```
    🖐  MCP client for `<CLIENT>` failed to start: missing field `user_agent`
    ````
    
    It isn't clear to me yet why this is happening. My understanding is that
    this struct is simply added as a new field to the response but this
    should fix it until I figure out the full story here.
    
    <img width="714" height="262" alt="CleanShot 2025-09-10 at 13 58 59"
    src="https://github.com/user-attachments/assets/946b1313-5c1c-43d3-8ae8-ecc3de3406fc"
    />
  • Improved resiliency of two auth-related tests (#3427)
    This PR improves two existing auth-related tests. They were failing when
    run in an environment where an `OPENAI_API_KEY` env variable was
    defined. The change makes them more resilient.
  • Set a user agent suffix when used as a mcp server (#3395)
    This automatically adds a user agent suffix whenever the CLI is used as
    a MCP server
  • Introduce rollout items (#3380)
    This PR introduces Rollout items. This enable us to rollout eventmsgs
    and session meta.
    
    This is mostly #3214 with rebase on main
  • Replace config.responses_originator_header_internal_override with CODEX_INTERNAL_ORIGINATOR_OVERRIDE_ENV_VAR (#3388)
    The previous config approach had a few issues:
    1. It is part of the config but not designed to be used externally
    2. It had to be wired through many places (look at the +/- on this PR
    3. It wasn't guaranteed to be set consistently everywhere because we
    don't have a super well defined way that configs stack. For example, the
    extension would configure during newConversation but anything that
    happened outside of that (like login) wouldn't get it.
    
    This env var approach is cleaner and also creates one less thing we have
    to deal with when coming up with a better holistic story around configs.
    
    One downside is that I removed the unit test testing for the override
    because I don't want to deal with setting the global env or spawning
    child processes and figuring out how to introspect their originator
    header. The new code is sufficiently simple and I tested it e2e that I
    feel as if this is still worth it.
  • feat: add ArchiveConversation to ClientRequest (#3353)
    Adds support for `ArchiveConversation` in the JSON-RPC server that takes
    a `(ConversationId, PathBuf)` pair and:
    
    - verifies the `ConversationId` corresponds to the rollout id at the
    `PathBuf`
    - if so, invokes
    `ConversationManager.remove_conversation(ConversationId)`
    - if the `CodexConversation` was in memory, send `Shutdown` and wait for
    `ShutdownComplete` with a timeout
    - moves the `.jsonl` file to `$CODEX_HOME/archived_sessions`
    
    ---------
    
    Co-authored-by: Gabriel Peal <gabriel@openai.com>
  • fix: include rollout_path in NewConversationResponse (#3352)
    Adding the `rollout_path` to the `NewConversationResponse` makes it so a
    client can perform subsequent operations on a `(ConversationId,
    PathBuf)` pair. #3353 will introduce support for `ArchiveConversation`.
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/3352).
    * #3353
    * __->__ #3352
  • feat: Run cargo shear during CI (#3338)
    Run cargo shear as part of the CI to ensure no unused dependencies
  • 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
  • Add a getUserAgent MCP method (#3320)
    This will allow the extension to pass this user agent + a suffix for its
    requests
  • Use ConversationId instead of raw Uuids (#3282)
    We're trying to migrate from `session_id: Uuid` to `conversation_id:
    ConversationId`. Not only does this give us more type safety but it
    unifies our terminology across Codex and with the implementation of
    session resuming, a conversation (which can span multiple sessions) is
    more appropriate.
    
    I started this impl on https://github.com/openai/codex/pull/3219 as part
    of getting resume working in the extension but it's big enough that it
    should be broken out.
  • 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.
  • chore: improve serialization of ServerNotification (#3193)
    This PR introduces introduces a new
    `OutgoingMessage::AppServerNotification` variant that is designed to
    wrap a `ServerNotification`, which makes the serialization more
    straightforward compared to
    `OutgoingMessage::Notification(OutgoingNotification)`. We still use the
    latter for serializing an `Event` as a `JSONRPCMessage::Notification`,
    but I will try to get away from that in the near future.
    
    With this change, now the generated TypeScript type for
    `ServerNotification` is:
    
    ```typescript
    export type ServerNotification =
      | { "method": "authStatusChange", "params": AuthStatusChangeNotification }
      | { "method": "loginChatGptComplete", "params": LoginChatGptCompleteNotification };
    ```
    
    whereas before it was:
    
    ```typescript
    export type ServerNotification =
      | { type: "auth_status_change"; data: AuthStatusChangeNotification }
      | { type: "login_chat_gpt_complete"; data: LoginChatGptCompleteNotification };
    ```
    
    Once the `Event`s are migrated to the `ServerNotification` enum in Rust,
    it should be considerably easier to work with notifications on the
    TypeScript side, as it will be possible to `switch (message.method)` and
    check for exhaustiveness.
    
    Though we will probably need to introduce:
    
    ```typescript
    export type ServerMessage = ServerRequest | ServerNotification;
    ```
    
    and then we still need to group all of the `ServerResponse` types
    together, as well.
  • MCP: add session resume + history listing; (#3185)
    # 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.
  • [mcp-server] Update read config interface (#3093)
    ## Summary
    Follow-up to #3056
    
    This PR updates the mcp-server interface for reading the config settings
    saved by the user. At risk of introducing _another_ Config struct, I
    think it makes sense to avoid tying our protocol to ConfigToml, as its
    become a bit unwieldy. GetConfigTomlResponse was a de-facto struct for
    this already - better to make it explicit, in my opinion.
    
    This is technically a breaking change of the mcp-server protocol, but
    given the previous interface was introduced so recently in #2725, and we
    have not yet even started to call it, I propose proceeding with the
    breaking change - but am open to preserving the old endpoint.
    
    ## Testing
    - [x] Added additional integration test coverage
  • 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.
  • Replay EventMsgs from Response Items when resuming a session with history. (#3123)
    ### Overview
    
    This PR introduces the following changes:
    	1.	Adds a unified mechanism to convert ResponseItem into EventMsg.
    2. Ensures that when a session is initialized with initial history, a
    vector of EventMsg is sent along with the session configuration. This
    allows clients to re-render the UI accordingly.
    	3. 	Added integration testing
    
    ### Caveats
    
    This implementation does not send every EventMsg that was previously
    dispatched to clients. The excluded events fall into two categories:
    	•	“Arguably” rolled-out events
    Examples include tool calls and apply-patch calls. While these events
    are conceptually rolled out, we currently only roll out ResponseItems.
    These events are already being handled elsewhere and transformed into
    EventMsg before being sent.
    	•	Non-rolled-out events
    Certain events such as TurnDiff, Error, and TokenCount are not rolled
    out at all.
    
    ### Future Directions
    
    At present, resuming a session involves maintaining two states:
    	•	UI State
    Clients can replay most of the important UI from the provided EventMsg
    history.
    	•	Model State
    The model receives the complete session history to reconstruct its
    internal state.
    
    This design provides a solid foundation. If, in the future, more precise
    UI reconstruction is needed, we have two potential paths:
    1. Introduce a third data structure that allows us to derive both
    ResponseItems and EventMsgs.
    2. Clearly divide responsibilities: the core system ensures the
    integrity of the model state, while clients are responsible for
    reconstructing the UI.
  • MCP sandbox call (#3128)
    I have read the CLA Document and I hereby sign the CLA
  • Include originator in authentication URL parameters (#3117)
    Associates the client with an authentication session.
  • Add a common way to create HTTP client (#3110)
    Ensure User-Agent and originator are always sent.
  • Move CodexAuth and AuthManager to the core crate (#3074)
    Fix a long standing layering issue.
  • fix: remove unnecessary flush() calls (#2873)
    Because we are writing to a pipe, these `flush()` calls are unnecessary,
    so removing these saves us one syscall per write in these two cases.
  • fix: switch to unbounded channel (#2874)
    #2747 encouraged me to audit our codebase for similar issues, as now I
    am particularly suspicious that our flaky tests are due to a racy
    deadlock.
    
    I asked Codex to audit our code, and one of its suggestions was this:
    
    > **High-Risk Patterns**
    >
    > All `send_*` methods await on a bounded
    `mpsc::Sender<OutgoingMessage>`. If the writer blocks, the channel fills
    and the processor task blocks on send, stops draining incoming requests,
    and stdin reader eventually blocks on its send. This creates a
    backpressure deadlock cycle across the three tasks.
    >
    > **Recommendations**
    > * Server outgoing path: break the backpressure cycle
    > * Option A (minimal risk): Change `OutgoingMessageSender` to use an
    unbounded channel to decouple producer from stdout. Add rate logging so
    floods are visible.
    > * Option B (bounded + drop policy): Change `send_*` to try_send and
    drop messages (or coalesce) when the queue is full, logging a warning.
    This prevents processor stalls at the cost of losing messages under
    extreme backpressure.
    > * Option C (two-stage buffer): Keep bounded channel, but have a
    dedicated “egress” task that drains an unbounded internal queue, writing
    to stdout with retries and a shutdown timeout. This centralizes
    backpressure policy.
    
    So this PR is Option A.
    
    Indeed, we previously used a bounded channel with a capacity of `128`,
    but as we discovered recently with #2776, there are certainly cases
    where we can get flooded with events.
    
    That said, `test_shell_command_approval_triggers_elicitation` just
    failed one one build when I put up this PR, so clearly we are not out of
    the woods yet...
    
    **Update:** I think I found the true source of the deadlock! See
    https://github.com/openai/codex/pull/2876
  • Bug fix: clone of incoming_tx can lead to deadlock (#2747)
    POC code
    
    ```rust
    use tokio::sync::mpsc;
    use std::time::Duration;
    
    #[tokio::main]
    async fn main() {
        println!("=== Test 1: Simulating original MCP server pattern ===");
        test_original_pattern().await;
    }
    
    async fn test_original_pattern() {
        println!("Testing the original pattern from MCP server...");
        
        // Create channel - this simulates the original incoming_tx/incoming_rx
        let (tx, mut rx) = mpsc::channel::<String>(10);
        
        // Task 1: Simulates stdin reader that will naturally terminate
        let stdin_task = tokio::spawn({
            let tx_clone = tx.clone();
            async move {
                println!("  stdin_task: Started, will send 3 messages then exit");
                for i in 0..3 {
                    let msg = format!("Message {}", i);
                    if tx_clone.send(msg.clone()).await.is_err() {
                        println!("  stdin_task: Receiver dropped, exiting");
                        break;
                    }
                    println!("  stdin_task: Sent {}", msg);
                    tokio::time::sleep(Duration::from_millis(300)).await;
                }
                println!("  stdin_task: Finished (simulating EOF)");
                // tx_clone is dropped here
            }
        });
        
        // Task 2: Simulates message processor
        let processor_task = tokio::spawn(async move {
            println!("  processor_task: Started, waiting for messages");
            while let Some(msg) = rx.recv().await {
                println!("  processor_task: Processing {}", msg);
                tokio::time::sleep(Duration::from_millis(100)).await;
            }
            println!("  processor_task: Finished (channel closed)");
        });
        
        // Task 3: Simulates stdout writer or other background task
        let background_task = tokio::spawn(async move {
            for i in 0..2 {
                tokio::time::sleep(Duration::from_millis(500)).await;
                println!("  background_task: Tick {}", i);
            }
            println!("  background_task: Finished");
        });
        
        println!("  main: Original tx is still alive here");
        println!("  main: About to call tokio::join! - will this deadlock?");
        
        // This is the pattern from the original code
        let _ = tokio::join!(stdin_task, processor_task, background_task);
    }
    
    ```
    
    ---------
    
    Co-authored-by: Michael Bolin <bolinfest@gmail.com>
  • 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"
    />
  • Custom /prompts (#2696)
    Adds custom `/prompts` to `~/.codex/prompts/<command>.md`.
    
    <img width="239" height="107" alt="Screenshot 2025-08-25 at 6 22 42 PM"
    src="https://github.com/user-attachments/assets/fe6ebbaa-1bf6-49d3-95f9-fdc53b752679"
    />
    
    ---
    
    Details:
    
    1. Adds `Op::ListCustomPrompts` to core.
    2. Returns `ListCustomPromptsResponse` with list of `CustomPrompt`
    (name, content).
    3. TUI calls the operation on load, and populates the custom prompts
    (excluding prompts that collide with builtins).
    4. Selecting the custom prompt automatically sends the prompt to the
    agent.
  • chore: print stderr from MCP server to test output using eprintln! (#2849)
    Related to https://github.com/openai/codex/pull/2848, I don't see the
    stderr from `codex mcp` colocated with the other stderr from
    `test_shell_command_approval_triggers_elicitation()` when it fails even
    though we have `RUST_LOG=debug` set when we spawn `codex mcp`:
    
    
    https://github.com/openai/codex/blob/1e9e703b969d3f0965b31d1cc3d70fed3ebdd6f6/codex-rs/mcp-server/tests/common/mcp_process.rs#L65
    
    Let's try this new logic which should be more explicit.
  • chore: try to make it easier to debug the flakiness of test_shell_command_approval_triggers_elicitation (#2848)
    `test_shell_command_approval_triggers_elicitation()` is one of a number
    of integration tests that we have observed to be flaky on GitHub CI, so
    this PR tries to reduce the flakiness _and_ to provide us with more
    information when it flakes. Specifically:
    
    - Changed the command that we use to trigger the elicitation from `git
    init` to `python3 -c 'import pathlib; pathlib.Path(r"{}").touch()'`
    because running `git` seems more likely to invite variance.
    - Increased the timeout to wait for the task response from 10s to 20s.
    - Added more logging.
  • chore: require uninlined_format_args from clippy (#2845)
    - added `uninlined_format_args` to `[workspace.lints.clippy]` in the
    `Cargo.toml` for the workspace
    - ran `cargo clippy --tests --fix`
    - ran `just fmt`
  • Add "View Image" tool (#2723)
    Adds a "View Image" tool so Codex can find and see images by itself:
    
    <img width="1772" height="420" alt="Screenshot 2025-08-26 at 10 40
    04 AM"
    src="https://github.com/user-attachments/assets/7a459c7b-0b86-4125-82d9-05fbb35ade03"
    />
  • [mcp-server] Add GetConfig endpoint (#2725)
    ## Summary
    Adds a GetConfig request to the MCP Protocol, so MCP clients can
    evaluate the resolved config.toml settings which the harness is using.
    
    ## Testing
    - [x] Added an end to end test of the endpoint
  • send context window with task started (#2752)
    - Send context window with task started
    - Accounting for changing the model per turn
  • test: faster test execution in codex-core (#2633)
    this dramatically improves time to run `cargo test -p codex-core` (~25x
    speedup).
    
    before:
    ```
    cargo test -p codex-core  35.96s user 68.63s system 19% cpu 8:49.80 total
    ```
    
    after:
    ```
    cargo test -p codex-core  5.51s user 8.16s system 63% cpu 21.407 total
    ```
    
    both tests measured "hot", i.e. on a 2nd run with no filesystem changes,
    to exclude compile times.
    
    approach inspired by [Delete Cargo Integration
    Tests](https://matklad.github.io/2021/02/27/delete-cargo-integration-tests.html),
    we move all test cases in tests/ into a single suite in order to have a
    single binary, as there is significant overhead for each test binary
    executed, and because test execution is only parallelized with a single
    binary.
  • Add web search tool (#2371)
    Adds web_search tool, enabling the model to use Responses API web_search
    tool.
    - Disabled by default, enabled by --search flag
    - When --search is passed, exposes web_search_request function tool to
    the model, which triggers user approval. When approved, the model can
    use the web_search tool for the remainder of the turn
    <img width="1033" height="294" alt="image"
    src="https://github.com/user-attachments/assets/62ac6563-b946-465c-ba5d-9325af28b28f"
    />
    
    ---------
    
    Co-authored-by: easong-openai <easong@openai.com>
  • fork conversation from a previous message (#2575)
    This can be the underlying logic in order to start a conversation from a
    previous message. will need some love in the UI.
    
    Base for building this: #2588
  • Fix flakiness in shell command approval test (#2547)
    ## Summary
    - read the shell exec approval request's actual id instead of assuming
    it is always 0
    - use that id when validating and responding in the test
    
    ## Testing
    - `cargo test -p codex-mcp-server
    test_shell_command_approval_triggers_elicitation`
    
    ------
    https://chatgpt.com/codex/tasks/task_i_68a6ab9c732c832c81522cbf11812be0
  • Add AuthManager and enhance GetAuthStatus command (#2577)
    This PR adds a central `AuthManager` struct that manages the auth
    information used across conversations and the MCP server. Prior to this,
    each conversation and the MCP server got their own private snapshots of
    the auth information, and changes to one (such as a logout or token
    refresh) were not seen by others.
    
    This is especially problematic when multiple instances of the CLI are
    run. For example, consider the case where you start CLI 1 and log in to
    ChatGPT account X and then start CLI 2 and log out and then log in to
    ChatGPT account Y. The conversation in CLI 1 is still using account X,
    but if you create a new conversation, it will suddenly (and
    unexpectedly) switch to account Y.
    
    With the `AuthManager`, auth information is read from disk at the time
    the `ConversationManager` is constructed, and it is cached in memory.
    All new conversations use this same auth information, as do any token
    refreshes.
    
    The `AuthManager` is also used by the MCP server's GetAuthStatus
    command, which now returns the auth method currently used by the MCP
    server.
    
    This PR also includes an enhancement to the GetAuthStatus command. It
    now accepts two new (optional) input parameters: `include_token` and
    `refresh_token`. Callers can use this to request the in-use auth token
    and can optionally request to refresh the token.
    
    The PR also adds tests for the login and auth APIs that I recently added
    to the MCP server.
  • Added new auth-related methods and events to mcp server (#2496)
    This PR adds the following:
    * A getAuthStatus method on the mcp server. This returns the auth method
    currently in use (chatgpt or apikey) or none if the user is not
    authenticated. It also returns the "preferred auth method" which
    reflects the `preferred_auth_method` value in the config.
    * A logout method on the mcp server. If called, it logs out the user and
    deletes the `auth.json` file — the same behavior in the cli's `/logout`
    command.
    * An `authStatusChange` event notification that is sent when the auth
    status changes due to successful login or logout operations.
    * Logic to pass command-line config overrides to the mcp server at
    startup time. This allows use cases like `codex mcp -c
    preferred_auth_method=apikey`.