chore: update windows sandbox docs (#6872)

docs/sandbox.md

@@ -4,21 +4,12 @@ What Codex is allowed to do is governed by a combination of **sandbox modes** (w
 
 ### Approval policies
 
-Codex starts conservatively. Until you explicitly tell it a workspace is trusted, the CLI defaults to **read-only sandboxing** with the `read-only` approval preset. Codex can inspect files and answer questions, but every edit or command requires approval.
+Codex starts conservatively. Until you explicitly tell it a working directory is trusted, the CLI defaults to **read-only**. Codex can inspect files and answer questions, but every edit or command requires approval.
 
-When you mark a workspace as trusted (for example via the onboarding prompt or `/approvals` → “Trust this directory”), Codex upgrades the default preset to **Auto**: sandboxed writes inside the workspace with `AskForApproval::OnRequest`. Codex only interrupts you when it needs to leave the workspace or rerun something outside the sandbox.
+When you mark a working directory as trusted (for example via the onboarding prompt or `/approvals` → “Trust this directory”), Codex upgrades the default preset to **Agent**, which allows writes inside the workspace. Codex only interrupts you when it needs to leave the workspace or rerun something outside the sandbox. Note that the workspace includes the working directory plus temporary directories like `/tmp`. Use `/status` to confirm the exact writable roots.
 
 If you want maximum guardrails for a trusted repo, switch back to Read Only from the `/approvals` picker. If you truly need hands-off automation, use `Full Access`—but be deliberate, because that skips both the sandbox and approvals.
 
-#### Defaults and recommendations
-
-- Every session starts in a sandbox. Until a repo is trusted, Codex enforces read-only access and will prompt before any write or command.
-- Marking a repo as trusted switches the default preset to Auto (`workspace-write` + `ask-for-approval on-request`) so Codex can keep iterating locally without nagging you.
-- The workspace always includes the current directory plus temporary directories like `/tmp`. Use `/status` to confirm the exact writable roots.
-- You can override the defaults from the command line at any time:
-  - `codex --sandbox read-only --ask-for-approval on-request`
-  - `codex --sandbox workspace-write --ask-for-approval on-request`
-
 ### Can I run without ANY approvals?
 
 Yes, you can disable all approval prompts with `--ask-for-approval never`. This option works with all `--sandbox` modes, so you still have full control over Codex's level of autonomy. It will make its best attempt with whatever constraints you provide.
@@ -63,22 +54,32 @@ approval_policy = "never"
 sandbox_mode    = "read-only"
 ```
 
-### Sandbox mechanics by platform {#platform-sandboxing-details}
+### Sandbox mechanics by platform
 
 The mechanism Codex uses to enforce the sandbox policy depends on your OS:
 
-- **macOS 12+** uses **Apple Seatbelt**. Codex invokes `sandbox-exec` with a profile that corresponds to the selected `--sandbox` mode, constraining filesystem and network access at the OS level.
-- **Linux** combines **Landlock** and **seccomp** APIs to approximate the same guarantees. Kernel support is required; older kernels may not expose the necessary features.
-- **Windows (experimental)**:
-  - Launches commands inside a restricted token derived from an AppContainer profile.
-  - Grants only specifically requested filesystem capabilities by attaching capability SIDs to that profile.
-  - Disables outbound network access by overriding proxy-related environment variables and inserting stub executables for common network tools.
+#### macOS 12+
 
-Windows sandbox support remains highly experimental. It cannot prevent file writes, deletions, or creations in any directory where the Everyone SID already has write permissions (for example, world-writable folders).
+Uses **Apple Seatbelt**. Codex invokes `sandbox-exec` with a profile that corresponds to the selected `--sandbox` mode, constraining filesystem and network access at the OS level.
+
+#### Linux
+
+Combines **Landlock** and **seccomp** APIs to approximate the same guarantees. Kernel support is required; older kernels may not expose the necessary features.
 
 In containerized Linux environments (for example Docker), sandboxing may not work when the host or container configuration does not expose Landlock/seccomp. In those cases, configure the container to provide the isolation you need and run Codex with `--sandbox danger-full-access` (or the shorthand `--dangerously-bypass-approvals-and-sandbox`) inside that container.
 
-### Experimenting with the Codex Sandbox
+#### Windows
+
+Windows sandbox support remains experimental. How it works:
+
+- Launches commands inside a restricted token derived from an AppContainer profile.
+- Grants only specifically requested filesystem capabilities by attaching capability SIDs to that profile.
+- Disables outbound network access by overriding proxy-related environment variables and inserting stub executables for common network tools.
+
+Its primary limitation is that it cannot prevent file writes, deletions, or creations in any directory where the Everyone SID already has write permissions (for example, world-writable folders).
+See more discussion and limitations at [Windows Sandbox Security Details](./windows_sandbox_security.md).
+
+## Experimenting with the Codex Sandbox
 
 To test how commands behave under Codex's sandbox, use the CLI helpers:
 

docs/windows_sandbox_security.md

@@ -1,4 +1,6 @@
-# Windows Sandbox Status
+# Windows Sandbox Security Details
+
+For overall context on sandboxing in Codex, see [sandbox.md](./sandbox.md).
 
 ## Implementation Overview