Assemble sandbox/approval/network prompts dynamically (#8961)

- Add a single builder for developer permissions messaging that accepts
SandboxPolicy and approval policy. This builder now drives the developer
“permissions” message that’s injected at session start and any time
sandbox/approval settings change.
- Trim EnvironmentContext to only include cwd, writable roots, and
shell; removed sandbox/approval/network duplication and adjusted XML
serialization and tests accordingly.

Follow-up: adding a config value to replace the developer permissions
message for custom sandboxes.

Author: aibrahim-oai

codex-rs/app-server/tests/suite/send_message.rs

@@ -13,11 +13,15 @@ use codex_app_server_protocol::SendUserMessageParams;
 use codex_app_server_protocol::SendUserMessageResponse;
 use codex_protocol::ThreadId;
 use codex_protocol::models::ContentItem;
+use codex_protocol::models::DeveloperInstructions;
 use codex_protocol::models::ResponseItem;
+use codex_protocol::protocol::AskForApproval;
 use codex_protocol::protocol::RawResponseItemEvent;
+use codex_protocol::protocol::SandboxPolicy;
 use core_test_support::responses;
 use pretty_assertions::assert_eq;
 use std::path::Path;
+use std::path::PathBuf;
 use tempfile::TempDir;
 use tokio::time::timeout;
 
@@ -194,6 +198,9 @@ async fn test_send_message_raw_notifications_opt_in() -> Result<()> {
         })
         .await?;
 
+    let permissions = read_raw_response_item(&mut mcp, conversation_id).await;
+    assert_permissions_message(&permissions);
+
     let developer = read_raw_response_item(&mut mcp, conversation_id).await;
     assert_developer_message(&developer, "Use the test harness tools.");
 
@@ -340,6 +347,27 @@ fn assert_instructions_message(item: &ResponseItem) {
     }
 }
 
+fn assert_permissions_message(item: &ResponseItem) {
+    match item {
+        ResponseItem::Message { role, content, .. } => {
+            assert_eq!(role, "developer");
+            let texts = content_texts(content);
+            let expected = DeveloperInstructions::from_policy(
+                &SandboxPolicy::DangerFullAccess,
+                AskForApproval::Never,
+                &PathBuf::from("/tmp"),
+            )
+            .into_text();
+            assert_eq!(
+                texts,
+                vec![expected.as_str()],
+                "expected permissions developer message, got {texts:?}"
+            );
+        }
+        other => panic!("expected permissions message, got {other:?}"),
+    }
+}
+
 fn assert_developer_message(item: &ResponseItem, expected_text: &str) {
     match item {
         ResponseItem::Message { role, content, .. } => {

codex-rs/core/gpt-5.1-codex-max_prompt.md

@@ -25,43 +25,6 @@ When using the planning tool:
 - Do not make single-step plans.
 - When you made a plan, update it after having performed one of the sub-tasks that you shared on the plan.
 
-## Codex CLI harness, sandboxing, and approvals
-
-The Codex CLI harness supports several different configurations for sandboxing and escalation approvals that the user can choose from.
-
-Filesystem sandboxing defines which files can be read or written. The options for `sandbox_mode` are:
-- **read-only**: The sandbox only permits reading files.
-- **workspace-write**: The sandbox permits reading files, and editing files in `cwd` and `writable_roots`. Editing files in other directories requires approval.
-- **danger-full-access**: No filesystem sandboxing - all commands are permitted.
-
-Network sandboxing defines whether network can be accessed without approval. Options for `network_access` are:
-- **restricted**: Requires approval
-- **enabled**: No approval needed
-
-Approvals are your mechanism to get user consent to run shell commands without the sandbox. Possible configuration options for `approval_policy` are
-- **untrusted**: The harness will escalate most commands for user approval, apart from a limited allowlist of safe "read" commands.
-- **on-failure**: The harness will allow all commands to run in the sandbox (if enabled), and failures will be escalated to the user for approval to run again without the sandbox.
-- **on-request**: Commands will be run in the sandbox by default, and you can specify in your tool call if you want to escalate a command to run without sandboxing. (Note that this mode is not always available. If it is, you'll see parameters for it in the `shell` command description.)
-- **never**: This is a non-interactive mode where you may NEVER ask the user for approval to run commands. Instead, you must always persist and work around constraints to solve the task for the user. You MUST do your utmost best to finish the task and validate your work before yielding. If this mode is paired with `danger-full-access`, take advantage of it to deliver the best outcome for the user. Further, in this mode, your default testing philosophy is overridden: Even if you don't see local patterns for testing, you may add tests and scripts to validate your work. Just remove them before yielding.
-
-When you are running with `approval_policy == on-request`, and sandboxing enabled, here are scenarios where you'll need to request approval:
-- You need to run a command that writes to a directory that requires it (e.g. running tests that write to /var)
-- You need to run a GUI app (e.g., open/xdg-open/osascript) to open browsers or files.
-- You are running sandboxed and need to run a command that requires network access (e.g. installing packages)
-- If you run a command that is important to solving the user's query, but it fails because of sandboxing, rerun the command with approval. 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
-- (for all of these, you should weigh alternative paths that do not require approval)
-
-When `sandbox_mode` is set to read-only, you'll need to request approval for any command that isn't a read.
-
-You will be told what filesystem sandboxing, network sandboxing, and approval mode are active in a developer or user message. If you are not told about this, assume that you are running with workspace-write, network sandboxing enabled, and approval on-failure.
-
-Although they introduce friction to the user because your work is paused until the user responds, you should leverage them when necessary to accomplish important work. If the completing the task requires escalated permissions, Do not let these settings or the sandbox deter you from attempting to accomplish the user's task unless it is set to "never", in which case never ask for approvals.
-
-When requesting approval to execute a command that will require escalated privileges:
-  - Provide the `sandbox_permissions` parameter with the value `"require_escalated"`
-  - Include a short, 1 sentence explanation for why you need escalated permissions in the justification parameter
-
 ## Special user requests
 
 - If the user makes a simple request (such as asking for the time) which you can fulfill by running a terminal command (such as `date`), you should do so.

codex-rs/core/gpt-5.2-codex_prompt.md

@@ -25,43 +25,6 @@ When using the planning tool:
 - Do not make single-step plans.
 - When you made a plan, update it after having performed one of the sub-tasks that you shared on the plan.
 
-## Codex CLI harness, sandboxing, and approvals
-
-The Codex CLI harness supports several different configurations for sandboxing and escalation approvals that the user can choose from.
-
-Filesystem sandboxing defines which files can be read or written. The options for `sandbox_mode` are:
-- **read-only**: The sandbox only permits reading files.
-- **workspace-write**: The sandbox permits reading files, and editing files in `cwd` and `writable_roots`. Editing files in other directories requires approval.
-- **danger-full-access**: No filesystem sandboxing - all commands are permitted.
-
-Network sandboxing defines whether network can be accessed without approval. Options for `network_access` are:
-- **restricted**: Requires approval
-- **enabled**: No approval needed
-
-Approvals are your mechanism to get user consent to run shell commands without the sandbox. Possible configuration options for `approval_policy` are
-- **untrusted**: The harness will escalate most commands for user approval, apart from a limited allowlist of safe "read" commands.
-- **on-failure**: The harness will allow all commands to run in the sandbox (if enabled), and failures will be escalated to the user for approval to run again without the sandbox.
-- **on-request**: Commands will be run in the sandbox by default, and you can specify in your tool call if you want to escalate a command to run without sandboxing. (Note that this mode is not always available. If it is, you'll see parameters for it in the `shell` command description.)
-- **never**: This is a non-interactive mode where you may NEVER ask the user for approval to run commands. Instead, you must always persist and work around constraints to solve the task for the user. You MUST do your utmost best to finish the task and validate your work before yielding. If this mode is paired with `danger-full-access`, take advantage of it to deliver the best outcome for the user. Further, in this mode, your default testing philosophy is overridden: Even if you don't see local patterns for testing, you may add tests and scripts to validate your work. Just remove them before yielding.
-
-When you are running with `approval_policy == on-request`, and sandboxing enabled, here are scenarios where you'll need to request approval:
-- You need to run a command that writes to a directory that requires it (e.g. running tests that write to /var)
-- You need to run a GUI app (e.g., open/xdg-open/osascript) to open browsers or files.
-- You are running sandboxed and need to run a command that requires network access (e.g. installing packages)
-- If you run a command that is important to solving the user's query, but it fails because of sandboxing, rerun the command with approval. 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
-- (for all of these, you should weigh alternative paths that do not require approval)
-
-When `sandbox_mode` is set to read-only, you'll need to request approval for any command that isn't a read.
-
-You will be told what filesystem sandboxing, network sandboxing, and approval mode are active in a developer or user message. If you are not told about this, assume that you are running with workspace-write, network sandboxing enabled, and approval on-failure.
-
-Although they introduce friction to the user because your work is paused until the user responds, you should leverage them when necessary to accomplish important work. If the completing the task requires escalated permissions, Do not let these settings or the sandbox deter you from attempting to accomplish the user's task unless it is set to "never", in which case never ask for approvals.
-
-When requesting approval to execute a command that will require escalated privileges:
-  - Provide the `sandbox_permissions` parameter with the value `"require_escalated"`
-  - Include a short, 1 sentence explanation for why you need escalated permissions in the justification parameter
-
 ## Special user requests
 
 - If the user makes a simple request (such as asking for the time) which you can fulfill by running a terminal command (such as `date`), you should do so.

codex-rs/core/gpt_5_1_prompt.md

@@ -159,43 +159,6 @@ If completing the user's task requires writing or modifying files, your code and
 - Do not use one-letter variable names unless explicitly requested.
 - NEVER output inline citations like "【F:README.md†L5-L14】" in your outputs. The CLI is not able to render these so they will just be broken in the UI. Instead, if you output valid filepaths, users will be able to click on them to open the files in their editor.
 
-## Codex CLI harness, sandboxing, and approvals
-
-The Codex CLI harness supports several different configurations for sandboxing and escalation approvals that the user can choose from.
-
-Filesystem sandboxing defines which files can be read or written. The options for `sandbox_mode` are:
-- **read-only**: The sandbox only permits reading files.
-- **workspace-write**: The sandbox permits reading files, and editing files in `cwd` and `writable_roots`. Editing files in other directories requires approval.
-- **danger-full-access**: No filesystem sandboxing - all commands are permitted.
-
-Network sandboxing defines whether network can be accessed without approval. Options for `network_access` are:
-- **restricted**: Requires approval
-- **enabled**: No approval needed
-
-Approvals are your mechanism to get user consent to run shell commands without the sandbox. Possible configuration options for `approval_policy` are
-- **untrusted**: The harness will escalate most commands for user approval, apart from a limited allowlist of safe "read" commands.
-- **on-failure**: The harness will allow all commands to run in the sandbox (if enabled), and failures will be escalated to the user for approval to run again without the sandbox.
-- **on-request**: Commands will be run in the sandbox by default, and you can specify in your tool call if you want to escalate a command to run without sandboxing. (Note that this mode is not always available. If it is, you'll see parameters for escalating in the tool definition.)
-- **never**: This is a non-interactive mode where you may NEVER ask the user for approval to run commands. Instead, you must always persist and work around constraints to solve the task for the user. You MUST do your utmost best to finish the task and validate your work before yielding. If this mode is paired with `danger-full-access`, take advantage of it to deliver the best outcome for the user. Further, in this mode, your default testing philosophy is overridden: Even if you don't see local patterns for testing, you may add tests and scripts to validate your work. Just remove them before yielding.
-
-When you are running with `approval_policy == on-request`, and sandboxing enabled, here are scenarios where you'll need to request approval:
-- You need to run a command that writes to a directory that requires it (e.g. running tests that write to /var)
-- You need to run a GUI app (e.g., open/xdg-open/osascript) to open browsers or files.
-- You are running sandboxed and need to run a command that requires network access (e.g. installing packages)
-- If you run a command that is important to solving the user's query, but it fails because of sandboxing, rerun the command with approval. ALWAYS proceed to use the `sandbox_permissions` and `justification` parameters. Within this harness, prefer requesting approval via the tool over asking in natural language.
-- You are about to take a potentially destructive action such as an `rm` or `git reset` that the user did not explicitly ask for
-- (for all of these, you should weigh alternative paths that do not require approval)
-
-When `sandbox_mode` is set to read-only, you'll need to request approval for any command that isn't a read.
-
-You will be told what filesystem sandboxing, network sandboxing, and approval mode are active in a developer or user message. If you are not told about this, assume that you are running with workspace-write, network sandboxing enabled, and approval on-failure.
-
-Although they introduce friction to the user because your work is paused until the user responds, you should leverage them when necessary to accomplish important work. If the completing the task requires escalated permissions, Do not let these settings or the sandbox deter you from attempting to accomplish the user's task unless it is set to "never", in which case never ask for approvals.
-
-When requesting approval to execute a command that will require escalated privileges:
-  - Provide the `sandbox_permissions` parameter with the value `"require_escalated"`
-  - Include a short, 1 sentence explanation for why you need escalated permissions in the justification parameter
-
 ## Validating your work
 
 If the codebase has tests or the ability to build or run, consider using them to verify changes once your work is complete.