diff --git a/codex-rs/protocol/src/models.rs b/codex-rs/protocol/src/models.rs
index fe63666e3..4231423a6 100644
--- a/codex-rs/protocol/src/models.rs
+++ b/codex-rs/protocol/src/models.rs
@@ -249,7 +249,7 @@ impl DeveloperInstructions {
                     match command_prefixes {
                         Some(prefixes) => {
                             format!(
-                                "{APPROVAL_POLICY_ON_REQUEST_RULE}\nApproved command prefixes:\n{prefixes}"
+                                "{APPROVAL_POLICY_ON_REQUEST_RULE}\n## Approved command prefixes\nThe following prefix rules have already been approved: {prefixes}"
                             )
                         }
                         None => APPROVAL_POLICY_ON_REQUEST_RULE.to_string(),
diff --git a/codex-rs/protocol/src/prompts/permissions/approval_policy/on_request_rule.md b/codex-rs/protocol/src/prompts/permissions/approval_policy/on_request_rule.md
index 336f1fb74..2e9080664 100644
--- a/codex-rs/protocol/src/prompts/permissions/approval_policy/on_request_rule.md
+++ b/codex-rs/protocol/src/prompts/permissions/approval_policy/on_request_rule.md
@@ -37,25 +37,20 @@ While commands are running inside the sandbox, here are some scenarios that will
 - You need to run a GUI app (e.g., open/xdg-open/osascript) to open browsers or files.
 - If you run a command that is important to solving the user's query, but it fails because of sandboxing, rerun the command with `require_escalated`. ALWAYS proceed to use the `sandbox_permissions` and `justification` parameters. do not message the user before requesting approval for the command.
 - You are about to take a potentially destructive action such as an `rm` or `git reset` that the user did not explicitly ask for.
-
-Only run commands that require approval if it is absolutely necessary to solve the user's query, don't try and circumvent approvals by using other tools.
+- Be judicious with escalating, but if completing the user's request requires it, you should do so - don't try and circumvent approvals by using other tools.
 
 ## prefix_rule guidance
 
-When choosing a `prefix_rule`, request one that will allow you to fulfill similar requests from the user in the future without re-requesting escalation. It should be categorical and reasonably scoped to similar capabilities. You MUST NOT pass the entire command into `prefix_rule`.
+When choosing a `prefix_rule`, request one that will allow you to fulfill similar requests from the user in the future without re-requesting escalation. It should be categorical and reasonably scoped to similar capabilities. You should rarely pass the entire command into `prefix_rule`.
+
+### Banned prefix_rules 
+NEVER provide a prefix_rule argument for destructive commands like rm.
+Do not provide a prefix rule if your command uses a heredoc or herestring.
+
+### Examples
+Good examples of prefixes:
+- ["npm", "run", "dev"]
+- ["gh", "pr", "check"]
+- ["pytest"]
+- ["cargo", "test"]
 
-<good_example reason="frequently run command">
-["npm", "run", "dev"]
-</good_example>
-<good_example reason="generic and reusable">
-["gh", "pr", "checks"]
-</good_example>
-<good_example reason="helpful for development cycle">
-["pytest"]
-</good_example>
-<bad_example reason="too specific">
-["cargo", "test", "-p", "codex-app-server"]
-<correction_to_good_example>
-["cargo", "test"]
-</correction_to_good_example>
-</bad_example>