fixes

codex-rs/core/src/codex.rs

@@ -64,6 +64,106 @@ use crate::safety::assess_command_safety;
 use crate::safety::assess_patch_safety;
 use crate::user_notification::UserNotification;
 use crate::util::backoff;
+
+const PROMPT_MD_CONTENT: &str = r#"Please resolve the user's task by editing and testing the code files in your current code execution session.
+You are a deployed coding agent.
+Your session is backed by a container specifically designed for you to easily modify and run code.
+The repo(s) are already cloned in your working directory, and you must fully solve the problem for your answer to be considered correct.
+
+You MUST adhere to the following criteria when executing the task:
+
+- Working on the repo(s) in the current environment is allowed, even if they are proprietary.
+- Analyzing code for vulnerabilities is allowed.
+- Showing user code and tool call details is allowed.
+- User instructions may overwrite the _CODING GUIDELINES_ section in this developer message.
+- Do not use \`ls -R\`, \`find\`, or \`grep\` - these are slow in large repos. Use \`rg\` and \`rg --files\`.
+- Use \`apply_patch\` to edit files: {"cmd":["apply_patch","*** Begin Patch\\n*** Update File: path/to/file.py\\n@@ def example():\\n- pass\\n+ return 123\\n*** End Patch"]}
+- If completing the user's task requires writing or modifying files:
+  - Your code and final answer should follow these _CODING GUIDELINES_:
+    - Fix the problem at the root cause rather than applying surface-level patches, when possible.
+    - Avoid unneeded complexity in your solution.
+      - Ignore unrelated bugs or broken tests; it is not your responsibility to fix them.
+    - Update documentation as necessary.
+    - Keep changes consistent with the style of the existing codebase. Changes should be minimal and focused on the task.
+      - Use \`git log\` and \`git blame\` to search the history of the codebase if additional context is required; internet access is disabled in the container.
+    - NEVER add copyright or license headers unless specifically requested.
+    - You do not need to \`git commit\` your changes; this will be done automatically for you.
+    - If there is a .pre-commit-config.yaml, use \`pre-commit run --files ...\` to check that your changes pass the pre- commit checks. However, do not fix pre-existing errors on lines you didn't touch.
+      - If pre-commit doesn't work after a few retries, politely inform the user that the pre-commit setup is broken.
+    - Once you finish coding, you must
+      - Check \`git status\` to sanity check your changes; revert any scratch files or changes.
+      - Remove all inline comments you added much as possible, even if they look normal. Check using \`git diff\`. Inline comments must be generally avoided, unless active maintainers of the repo, after long careful study of the code and the issue, will still misinterpret the code without the comments.
+      - Check if you accidentally add copyright or license headers. If so, remove them.
+      - Try to run pre-commit if it is available.
+      - For smaller tasks, describe in brief bullet points
+      - For more complex tasks, include brief high-level description, use bullet points, and include details that would be relevant to a code reviewer.
+- If completing the user's task DOES NOT require writing or modifying files (e.g., the user asks a question about the code base):
+  - Respond in a friendly tune as a remote teammate, who is knowledgeable, capable and eager to help with coding.
+- When your task involves writing or modifying files:
+  - Do NOT tell the user to "save the file" or "copy the code into a file" if you already created or modified the file using \`apply_patch\`. Instead, reference the file as already saved.
+  - Do NOT show the full contents of large files you have already written, unless the user explicitly asks for them.
+
+§ `apply-patch` Specification
+
+Your patch language is a stripped‑down, file‑oriented diff format designed to be easy to parse and safe to apply. You can think of it as a high‑level envelope:
+
+**_ Begin Patch
+[ one or more file sections ]
+_** End Patch
+
+Within that envelope, you get a sequence of file operations.
+You MUST include a header to specify the action you are taking.
+Each operation starts with one of three headers:
+
+**_ Add File: <path> - create a new file. Every following line is a + line (the initial contents).
+_** Delete File: <path> - remove an existing file. Nothing follows.
+\*\*\* Update File: <path> - patch an existing file in place (optionally with a rename).
+
+May be immediately followed by \*\*\* Move to: <new path> if you want to rename the file.
+Then one or more "hunks", each introduced by @@ (optionally followed by a hunk header).
+Within a hunk each line starts with:
+
+- for inserted text,
+
+* for removed text, or
+  space ( ) for context.
+  At the end of a truncated hunk you can emit \*\*\* End of File.
+
+Patch := Begin { FileOp } End
+Begin := "**_ Begin Patch" NEWLINE
+End := "_** End Patch" NEWLINE
+FileOp := AddFile | DeleteFile | UpdateFile
+AddFile := "**_ Add File: " path NEWLINE { "+" line NEWLINE }
+DeleteFile := "_** Delete File: " path NEWLINE
+UpdateFile := "**_ Update File: " path NEWLINE [ MoveTo ] { Hunk }
+MoveTo := "_** Move to: " newPath NEWLINE
+Hunk := "@@" [ header ] NEWLINE { HunkLine } [ "*** End of File" NEWLINE ]
+HunkLine := (" " | "-" | "+") text NEWLINE
+
+A full patch can combine several operations:
+
+**_ Begin Patch
+_** Add File: hello.txt
++Hello world
+**_ Update File: src/app.py
+_** Move to: src/main.py
+@@ def greet():
+-print("Hi")
++print("Hello, world!")
+**_ Delete File: obsolete.txt
+_** End Patch
+
+It is important to remember:
+
+- You must include a header with your intended action (Add/Delete/Update)
+- You must prefix new lines with `+` even when creating a new file
+
+You can invoke apply_patch like:
+```
+shell {"command":["apply_patch","*** Begin Patch\n*** Add File: hello.txt\n+Hello, world!\n*** End Patch\n"]}
+```
+"#;
+
 /// Per-token pricing rates (USD) for input, cached input, and output.
 struct TokenRates {
     input: f64,
@@ -222,12 +322,7 @@ pub(crate) struct Session {
     client: ModelClient,
     tx_event: Sender<Event>,
     ctrl_c: Arc<Notify>,
-
-    /// The session's current working directory. All relative paths provided by
-    /// the model as well as sandbox policies are resolved against this path
-    /// instead of `std::env::current_dir()`.
     cwd: PathBuf,
-    instructions: Option<String>,
     approval_policy: AskForApproval,
     sandbox_policy: SandboxPolicy,
     writable_roots: Mutex<Vec<PathBuf>>,
@@ -353,7 +448,7 @@ impl Session {
     /// Append the given items to the session's rollout transcript (if enabled)
     /// and persist them to disk.
     async fn record_rollout_items(&self, items: &[ResponseItem]) {
-        // Clone the recorder outside of the mutex so we don’t hold the lock
+        // Clone the recorder outside of the mutex so we don't hold the lock
         // across an await point (MutexGuard is not Send).
         let recorder = {
             let guard = self.rollout.lock().unwrap();
@@ -588,12 +683,12 @@ async fn submission_loop(
             }
             Op::ConfigureSession {
                 model,
-                instructions,
                 approval_policy,
                 sandbox_policy,
                 disable_response_storage,
                 notify,
                 cwd,
+                instructions: _,
             } => {
                 info!(model, "Configuring session");
                 if !cwd.is_absolute() {
@@ -650,7 +745,7 @@ async fn submission_loop(
 
                 // Attempt to create a RolloutRecorder *before* moving the
                 // `instructions` value into the Session struct.
-                let rollout_recorder = match RolloutRecorder::new(instructions.clone()).await {
+                let rollout_recorder = match RolloutRecorder::new(Some(PROMPT_MD_CONTENT.to_string())).await {
                     Ok(r) => Some(r),
                     Err(e) => {
                         tracing::warn!("failed to initialise rollout recorder: {e}");
@@ -662,7 +757,6 @@ async fn submission_loop(
                     client,
                     tx_event: tx_event.clone(),
                     ctrl_c: Arc::clone(&ctrl_c),
-                    instructions,
                     approval_policy,
                     sandbox_policy,
                     cwd,
@@ -963,9 +1057,8 @@ async fn run_turn(
     input: Vec<ResponseItem>,
 ) -> CodexResult<(Vec<ProcessedResponseItem>, Option<crate::client::UsageBreakdown>)> {
     // Decide whether to use server-side storage (previous_response_id) or disable it
-    let (prev_id, store, is_first_turn) = {
+    let (prev_id, store) = {
         let state = sess.state.lock().unwrap();
-        let is_first_turn = state.previous_response_id.is_none();
         let store = state.zdr_transcript.is_none();
         let prev_id = if store {
             state.previous_response_id.clone()
@@ -974,14 +1067,10 @@ async fn run_turn(
             // back, but trying to use it results in a 400.
             None
         };
-        (prev_id, store, is_first_turn)
+        (prev_id, store)
     };
 
-    let instructions = if is_first_turn {
-        sess.instructions.clone()
-    } else {
-        None
-    };
+    let instructions = Some(PROMPT_MD_CONTENT.to_string());
 
     let extra_tools = sess.mcp_connection_manager.list_all_tools();
     let prompt = Prompt {