Different tool-error recovery behavior between GPT-6 Lune and GPT-5.6 Lune after Windows sandbox setup refresh failures #48479

What version of the Codex App are you using (From “About Codex” dialog)?

26.909.11814

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Product: Codex on Windows
Workspace: same workspace for all tests
Shells installed:

• Windows PowerShell 5.1
• PowerShell 7.6.5

No project files, Windows permissions, sandbox configuration,
or system settings were changed between model tests.

Both GPT-5.6 Lune and GPT-6 Lune encounter:

Failed to create unified exec process:
helper_unknown_error: setup refresh had errors

GPT-6 Lune:

• Encountered setup refresh failure.
• Tried simpler PowerShell commands.
• Tried cmd.exe.
• Tried other execution approaches.
• Eventually terminated the task.

Controlled retry:

• Explicitly instructed to repeatedly use Get-Location
  as a minimal readiness probe.
• 11 consecutive attempts failed.
• Task remained blocked.

GPT-5.6 Lune:

• Encountered the same initial setup refresh failure.
• Continued trying alternative/minimal process invocations.
• Eventually unified exec began accepting processes.
• Some intermediate attempts then reached the shell and
  produced quoting/argument errors, demonstrating that
  process creation had recovered.
• It continued correcting those errors.
• Eventually successfully launched BOTH:

Windows PowerShell: 5.1.26100.9444
PowerShell 7: 7.6.5

Get-Location:
D:\chat_gpt_codex\ebook

Is tool-error recovery/retry policy intentionally different between GPT-5.6 Lune and GPT-6 Lune?
Could transient setup refresh failures be classified as retryable infrastructure errors so that recovery does not depend on the model deciding whether to keep retrying?

What steps can reproduce the bug?

I can reproduce a difference in recovery behavior between GPT-6 Lune and GPT-5.6 Lune when Codex on Windows encounters:

Failed to create unified exec process: helper_unknown_error: setup refresh had errors

The underlying setup refresh failure can occur with both models. The issue I am reporting here is that GPT-5.6 Lune can eventually recover and complete the task, while GPT-6 Lune consistently fails to recover under the tested conditions.

Environment

• Codex on Windows
• Same machine and same workspace for the tests
• Workspace: D:\chat_gpt_codex\ebook
• Windows PowerShell 5.1: 5.1.26100.9444
• PowerShell 7: 7.6.5
• No project files, Windows permissions, sandbox configuration, or system settings were intentionally changed during the A/B tests.

Reproduction 1: GPT-6 Lune minimal retry test

Session ID:
01a0de48-a033-7812-822d-49cb6b59bba4

After encountering setup refresh had errors, I explicitly instructed GPT-6 Lune not to switch to GUI or other approaches and to repeatedly use:

Get-Location

as a minimal readiness probe.
GPT-6 Lune retried Get-Location 11 times. All 11 attempts failed with setup refresh had errors, and the command execution environment never became available.

Reproduction 2: GPT-6 Lune self-recovery test

Session ID:
01a0de57-c0aa-7671-a8a5-124a77a8fbfc
I asked GPT-6 Lune to repeat the PowerShell experiment and attempt to recover by itself.
The experiment explicitly tested both Windows PowerShell 5.1 and PowerShell 7.
Both failed before the requested shell could start with:
exec_command failed: CreateProcess { message: "Rejected("Failed to create unified exec process: helper_unknown_error: setup refresh had errors")" }
GPT-6 Lune also attempted alternative execution approaches, including cmd.exe, but the failure continued to occur while creating the unified exec process.
It eventually stopped and reported that it could not complete the experiment.
The rollout log for this session contains GPT-6 Lune calls but no codex-auto-review calls.

Reproduction 3: GPT-5.6 Lune recovery

Session ID:
01a0de52-69be-75e3-8913-75cb221e7ffc
In this session, GPT-6 Lune initially encountered the same PowerShell/unified-exec failure.
After switching to GPT-5.6 Lune and asking it to attempt recovery and complete the same experiment, GPT-5.6 Lune continued trying different process invocation forms.
It initially encountered the same:
helper_unknown_error: setup refresh had errors
but continued attempting execution. Later attempts progressed past unified-exec initialization and reached the shell (some intermediate attempts produced quoting/argument errors).
Eventually GPT-5.6 Lune successfully launched both shells:

• Windows PowerShell: 5.1.26100.9444
• PowerShell 7: 7.6.5
  and Get-Location successfully returned:
  D:\chat_gpt_codex\ebook
  No project files, permissions, sandbox settings, or system settings were changed to achieve the recovery.
  The rollout log for this session also shows multiple codex-auto-review calls during the GPT-5.6 Lune recovery sequence. I do not know whether these calls are related to the recovery, but I am including this observation because the GPT-6-only failed session above contains no codex-auto-review calls.
  Observed behavior
  Both GPT-6 Lune and GPT-5.6 Lune can encounter the same Windows unified-exec setup refresh failure.
  However, in these tests:
• GPT-6 Lune failed to recover, including after 11 explicit minimal Get-Location retries.
• GPT-6 Lune also failed when instructed to diagnose/recover autonomously.
• GPT-5.6 Lune eventually recovered from the same class of failure and successfully completed the PowerShell 5.1/7 experiment.
  Expected behavior
  Transient infrastructure/sandbox initialization failures should ideally be handled consistently by the Codex execution/runtime layer, or models should have comparable recovery behavior.
  A transient setup refresh failure should not cause the task completion rate to depend strongly on which model is selected.
  Additional observation
  The GPT-5.6 Lune recovery session contains multiple codex-auto-review model calls in the rollout log, while the GPT-6 Lune self-recovery failure session contains no codex-auto-review calls.
  I cannot determine whether this difference is causal, but it may be useful when comparing the internal execution traces of the supplied sessions.

What is the expected behavior?

Is tool-error recovery/retry policy intentionally different between GPT-5.6 Lune and GPT-6 Lune?
Could transient setup refresh failures be classified as retryable infrastructure errors so that recovery does not depend on the model deciding whether to keep retrying?

Additional information