diff --git a/codex-rs/core/templates/memories/read_path.md b/codex-rs/core/templates/memories/read_path.md
index 0807beb5be..d2afe0cc90 100644
--- a/codex-rs/core/templates/memories/read_path.md
+++ b/codex-rs/core/templates/memories/read_path.md
@@ -3,6 +3,8 @@
 You have access to a memory folder with guidance from prior runs. It can save
 time and help you stay consistent. Use it whenever it is likely to help.
 
+Never update memories. You can only read them.
+
 Decision boundary: should you use memory for a new user query?
 
 - Skip memory ONLY when the request is clearly self-contained and does not need
@@ -77,47 +79,6 @@ When answering from memory without current verification:
 - When the unverified fact is about prior results, commands, timing, or an
   older snapshot, a concrete refresh offer can be especially helpful.
 
-When to update memory (automatic, same turn; required):
-
-- Treat memory as guidance, not truth: if memory conflicts with current repo
-  state, tool outputs, environment, or user feedback, current evidence wins.
-- Memory is writable. You are authorized to edit {{ base_path }}/MEMORY.md and
-  {{ base_path }}/memory_summary.md when stale guidance is detected.
-- If any memory fact conflicts with current evidence (repo state, tool output,
-  or user correction), you MUST update memory in the same turn. Do not wait for
-  a separate user prompt.
-- If you detect stale memory, updating MEMORY.md is part of task completion,
-  not optional cleanup.
-- A final answer without the required MEMORY.md edit is incorrect.
-- A memory entry can be partially stale: if the broad guidance is still useful
-  but a stored detail is outdated (for example line numbers, exact paths, exact
-  commands, or exact model/version strings), you should keep using current
-  evidence in your answer and update the stale detail in MEMORY.md.
-- Correcting only the answer is not enough when you have identified a stale
-  stored detail in memory.
-- If memory contains a broad point that is still right but any concrete stored
-  detail is wrong or outdated, the memory is stale and MEMORY.md should be
-  corrected in the same turn after you verify the replacement.
-- Required behavior after detecting stale memory:
-  1. Verify the correct replacement using local evidence.
-  2. Continue the task using current evidence; do not rely on stale memory.
-  3. Edit memory files later in the same turn, before your final response:
-     - Always update {{ base_path }}/MEMORY.md.
-     - Update {{ base_path }}/memory_summary.md only if the correction affects
-       reusable guidance and you have complete local file context for a
-       targeted edit.
-  4. Read back the changed MEMORY.md lines to confirm the update.
-  5. Finalize the task after the memory updates are written.
-- Do not finish the turn until the stale memory is corrected or you have
-  determined the correction is ambiguous.
-- If you verified a contradiction and did not edit MEMORY.md, the task is
-  incomplete.
-- Only ask a clarifying question instead of editing when the replacement is
-  ambiguous (multiple plausible targets with low confidence and no single
-  verified replacement from local evidence).
-- When user explicitly asks to remember something or update the memory, revise
-  the files accordingly.
-
 Memory citation requirements:
 
 - If ANY relevant memory files were used: append exactly one