All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

I have read the CLA Document and I hereby sign the CLA

@davidgilbertson, thanks for the contribution. I'm a bit confused by the commit comment. You mention that this fix relates to apply_patch, but the fix seems to target windows sandbox logging. I'm not sure how the two are connected. Can you elaborate?

Sure, it's a long and winding road from apply_patch to preview:

In codex-rs\core\src\tools\handlers\apply_patch.rs

Apply patch tool handler: ApplyPatchHandler::handle parses the tool payload and, when it needs to actually execute, delegates to the runtime via ToolOrchestrator and ApplyPatchRuntime.

In codex-rs\core\src\tools\runtimes\apply_patch.rs

Apply patch runtime: ApplyPatchRuntime::run builds a CommandSpec that invokes the current codex binary with the CODEX_APPLY_PATCH_ARG1 arg, then calls execute_env.

In codex-rs\core\src\sandboxing\mod.rs and codex-rs\core\src\exec.rs

Sandbox execution pipeline: execute_env is a thin wrapper that calls execute_exec_env, which chooses the Windows sandbox path when SandboxType::WindowsRestrictedToken is active.

In codex-rs\core\src\exec.rs

Windows sandbox entry: exec_windows_sandbox calls into the Windows sandbox crate, choosing run_windows_sandbox_capture or the elevated variant based on is_windows_elevated_sandbox_enabled().

In codex-rs\windows-sandbox-rs\src\lib.rs, codex-rs\windows-sandbox-rs\src\elevated_impl.rs, codex-rs\windows-sandbox-rs\src\logging.rs

Windows sandbox logging: both the non‑elevated and elevated run_windows_sandbox_capture log the command at start/end via log_start/log_success/log_failure. These functions call preview internally to truncate and format the command.

Has this fallen through the cracks?

@davidgilbertson, it's in the queue for review. Apologies for the slow response. The Codex Team has been very busy lately.