From 11e390bb10bb74960cf144309bc677cc3513f240 Mon Sep 17 00:00:00 2001 From: andrewgu-oai Date: Tue, 4 Aug 2026 22:53:01 +0000 Subject: [PATCH] Remove legacy collaboration mode variants (#36990) ## What changed - Remove the hidden `PairProgramming` and `Execute` variants from `ModeKind`. - Delete their unused prompt templates and simplify mode handling to cover only `Default` and `Plan`. GitOrigin-RevId: 8d24e3f562a09e3071b2decae275d2b3871a1e9c --- codex-rs/analytics/src/reducer.rs | 2 +- .../collaboration-mode-templates/src/lib.rs | 2 - .../templates/execute.md | 45 ------------------- .../templates/pair_programming.md | 7 --- .../context/world_state/collaboration_mode.rs | 1 - .../handlers/request_user_input_spec_tests.rs | 11 ----- .../core/tests/suite/request_user_input.rs | 26 ----------- codex-rs/protocol/src/config_types.rs | 15 ------- codex-rs/tui/src/chatwidget/settings.rs | 2 +- 9 files changed, 2 insertions(+), 109 deletions(-) delete mode 100644 codex-rs/collaboration-mode-templates/templates/execute.md delete mode 100644 codex-rs/collaboration-mode-templates/templates/pair_programming.md diff --git a/codex-rs/analytics/src/reducer.rs b/codex-rs/analytics/src/reducer.rs index 03a9e6ea51..4aadf724b0 100644 --- a/codex-rs/analytics/src/reducer.rs +++ b/codex-rs/analytics/src/reducer.rs @@ -3183,7 +3183,7 @@ fn sandbox_policy_mode(permission_profile: &PermissionProfile, cwd: &Path) -> &' fn collaboration_mode_mode(mode: ModeKind) -> &'static str { match mode { ModeKind::Plan => "plan", - ModeKind::Default | ModeKind::PairProgramming | ModeKind::Execute => "default", + ModeKind::Default => "default", } } diff --git a/codex-rs/collaboration-mode-templates/src/lib.rs b/codex-rs/collaboration-mode-templates/src/lib.rs index 345990db0b..d2ccec1bad 100644 --- a/codex-rs/collaboration-mode-templates/src/lib.rs +++ b/codex-rs/collaboration-mode-templates/src/lib.rs @@ -1,4 +1,2 @@ pub const PLAN: &str = include_str!("../templates/plan.md"); pub const DEFAULT: &str = include_str!("../templates/default.md"); -pub const EXECUTE: &str = include_str!("../templates/execute.md"); -pub const PAIR_PROGRAMMING: &str = include_str!("../templates/pair_programming.md"); diff --git a/codex-rs/collaboration-mode-templates/templates/execute.md b/codex-rs/collaboration-mode-templates/templates/execute.md deleted file mode 100644 index c57878242d..0000000000 --- a/codex-rs/collaboration-mode-templates/templates/execute.md +++ /dev/null @@ -1,45 +0,0 @@ -# Collaboration Style: Execute -You execute on a well-specified task independently and report progress. - -You do not collaborate on decisions in this mode. You execute end-to-end. -You make reasonable assumptions when the user hasn't specified something, and you proceed without asking questions. - -## Assumptions-first execution -When information is missing, do not ask the user questions. -Instead: -- Make a sensible assumption. -- Clearly state the assumption in the final message (briefly). -- Continue executing. - -Group assumptions logically, for example architecture/frameworks/implementation, features/behavior, design/themes/feel. -If the user does not react to a proposed suggestion, consider it accepted. - -## Execution principles -*Think out loud.* Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. Avoid design lectures or exhaustive option lists. - -*Use reasonable assumptions.* When the user hasn't specified something, suggest a sensible choice instead of asking an open-ended question. Group your assumptions logically, for example architecture/frameworks/implementation, features/behavior, design/themes/feel. Clearly label suggestions as provisional. Share reasoning when it helps the user evaluate tradeoffs. Keep explanations short and grounded in consequences. They should be easy to accept or override. If the user does not react to a proposed suggestion, consider it accepted. - -Example: "There are a few viable ways to structure this. A plugin model gives flexibility but adds complexity; a simpler core with extension points is easier to reason about. Given what you've said about your team's size, I'd lean towards the latter." -Example: "If this is a shared internal library, I'll assume API stability matters more than rapid iteration." - -*Think ahead.* What else might the user need? How will the user test and understand what you did? Think about ways to support them and propose things they might need BEFORE you build. Offer at least one suggestion you came up with by thinking ahead. -Example: "This feature changes as time passes but you probably want to test it without waiting for a full hour to pass. I'll include a debug mode where you can move through states without just waiting." - -*Be mindful of time.* The user is right here with you. Any time you spend reading files or searching for information is time that the user is waiting for you. Do make use of these tools if helpful, but minimize the time the user is waiting for you. As a rule of thumb, spend only a few seconds on most turns and no more than 60 seconds when doing research. If you are missing information and would normally ask, make a reasonable assumption and continue. -Example: "I checked the readme and searched for the feature you mentioned, but didn't find it immediately. I'll proceed with the most likely implementation and verify behavior with a quick test." - -## Long-horizon execution -Treat the task as a sequence of concrete steps that add up to a complete delivery. -- Break the work into milestones that move the task forward in a visible way. -- Execute step by step, verifying along the way rather than doing everything at the end. -- If the task is large, keep a running checklist of what is done, what is next, and what is blocked. -- Avoid blocking on uncertainty: choose a reasonable default and continue. - -## Reporting progress -In this phase you show progress on your task and appraise the user of your progress using plan tool. -- Provide updates that directly map to the work you are doing (what changed, what you verified, what remains). -- If something fails, report what failed, what you tried, and what you will do next. -- When you finish, summarize what you delivered and how the user can validate it. - -## Executing -Once you start working, you should execute independently. Your job is to deliver the task and report progress. diff --git a/codex-rs/collaboration-mode-templates/templates/pair_programming.md b/codex-rs/collaboration-mode-templates/templates/pair_programming.md deleted file mode 100644 index 1297129b1d..0000000000 --- a/codex-rs/collaboration-mode-templates/templates/pair_programming.md +++ /dev/null @@ -1,7 +0,0 @@ -# Collaboration Style: Pair Programming - -## Build together as you go -You treat collaboration as pairing by default. The user is right with you in the terminal, so avoid taking steps that are too large or take a lot of time (like running long tests), unless asked for it. You check for alignment and comfort before moving forward, explain reasoning step by step, and dynamically adjust depth based on the user's signals. There is no need to ask multiple rounds of questions—build as you go. When there are multiple viable paths, you present clear options with friendly framing, ground them in examples and intuition, and explicitly invite the user into the decision so the choice feels empowering rather than burdensome. When you do more complex work you use the planning tool liberally to keep the user updated on what you are doing. - -## Debugging -If you are debugging something with the user, assume you are a team. You can ask them what they see and ask them to provide you with information you don't have access to, for example you can ask them to check error messages in developer tools or provide you with screenshots. diff --git a/codex-rs/core/src/context/world_state/collaboration_mode.rs b/codex-rs/core/src/context/world_state/collaboration_mode.rs index 14bb761f7c..f06a2d5e6a 100644 --- a/codex-rs/core/src/context/world_state/collaboration_mode.rs +++ b/codex-rs/core/src/context/world_state/collaboration_mode.rs @@ -26,7 +26,6 @@ impl CollaborationModeState { catalog_messages.and_then(|messages| match collaboration_mode.mode { ModeKind::Default => messages.default.as_ref(), ModeKind::Plan => messages.plan.as_ref(), - ModeKind::PairProgramming | ModeKind::Execute => None, }); Self { diff --git a/codex-rs/core/src/tools/handlers/request_user_input_spec_tests.rs b/codex-rs/core/src/tools/handlers/request_user_input_spec_tests.rs index 65864eac2c..6d2e25ec0f 100644 --- a/codex-rs/core/src/tools/handlers/request_user_input_spec_tests.rs +++ b/codex-rs/core/src/tools/handlers/request_user_input_spec_tests.rs @@ -171,17 +171,6 @@ fn request_user_input_unavailable_messages_respect_default_mode_feature_flag() { ), None ); - assert_eq!( - request_user_input_unavailable_message(ModeKind::Execute, &default_available_modes()), - Some("request_user_input is unavailable in Execute mode".to_string()) - ); - assert_eq!( - request_user_input_unavailable_message( - ModeKind::PairProgramming, - &default_available_modes() - ), - Some("request_user_input is unavailable in Pair Programming mode".to_string()) - ); } #[test] diff --git a/codex-rs/core/tests/suite/request_user_input.rs b/codex-rs/core/tests/suite/request_user_input.rs index f0bc84f66a..585af3be56 100644 --- a/codex-rs/core/tests/suite/request_user_input.rs +++ b/codex-rs/core/tests/suite/request_user_input.rs @@ -411,19 +411,6 @@ where Ok(()) } -#[tokio::test(flavor = "multi_thread", worker_threads = 2)] -async fn request_user_input_rejected_in_execute_mode_alias() -> anyhow::Result<()> { - assert_request_user_input_rejected("Execute", |model| CollaborationMode { - mode: ModeKind::Execute, - settings: Settings { - model, - reasoning_effort: None, - developer_instructions: None, - }, - }) - .await -} - #[tokio::test(flavor = "multi_thread", worker_threads = 2)] async fn request_user_input_rejected_in_default_mode_by_default() -> anyhow::Result<()> { assert_request_user_input_rejected("Default", |model| CollaborationMode { @@ -441,16 +428,3 @@ async fn request_user_input_rejected_in_default_mode_by_default() -> anyhow::Res async fn request_user_input_round_trip_in_default_mode_with_feature() -> anyhow::Result<()> { request_user_input_round_trip_for_mode(ModeKind::Default).await } - -#[tokio::test(flavor = "multi_thread", worker_threads = 2)] -async fn request_user_input_rejected_in_pair_mode_alias() -> anyhow::Result<()> { - assert_request_user_input_rejected("Pair Programming", |model| CollaborationMode { - mode: ModeKind::PairProgramming, - settings: Settings { - model, - reasoning_effort: None, - developer_instructions: None, - }, - }) - .await -} diff --git a/codex-rs/protocol/src/config_types.rs b/codex-rs/protocol/src/config_types.rs index 4156677256..38a7217273 100644 --- a/codex-rs/protocol/src/config_types.rs +++ b/codex-rs/protocol/src/config_types.rs @@ -650,16 +650,6 @@ pub enum ModeKind { alias = "custom" )] Default, - #[doc(hidden)] - #[serde(skip_serializing, skip_deserializing)] - #[schemars(skip)] - #[ts(skip)] - PairProgramming, - #[doc(hidden)] - #[serde(skip_serializing, skip_deserializing)] - #[schemars(skip)] - #[ts(skip)] - Execute, } pub const TUI_VISIBLE_COLLABORATION_MODES: [ModeKind; 2] = [ModeKind::Default, ModeKind::Plan]; @@ -669,8 +659,6 @@ impl ModeKind { match self { Self::Plan => "Plan", Self::Default => "Default", - Self::PairProgramming => "Pair Programming", - Self::Execute => "Execute", } } @@ -869,9 +857,6 @@ mod tests { for mode in TUI_VISIBLE_COLLABORATION_MODES { assert!(mode.is_tui_visible()); } - - assert!(!ModeKind::PairProgramming.is_tui_visible()); - assert!(!ModeKind::Execute.is_tui_visible()); } #[test] diff --git a/codex-rs/tui/src/chatwidget/settings.rs b/codex-rs/tui/src/chatwidget/settings.rs index 58fe920905..473bccb4cf 100644 --- a/codex-rs/tui/src/chatwidget/settings.rs +++ b/codex-rs/tui/src/chatwidget/settings.rs @@ -605,7 +605,7 @@ impl ChatWidget { } match self.active_mode_kind() { ModeKind::Plan => Some(CollaborationModeIndicator::Plan), - ModeKind::Default | ModeKind::PairProgramming | ModeKind::Execute => None, + ModeKind::Default => None, } }