Codex Desktop stops the entire task after its own WSL write command is rejected by Auto-review

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

26.903.61454

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

Environment:

• Codex Desktop for Windows
• Windows 11
• WSL2 Ubuntu-24.04
• Project folder configured in Codex UI as:
  \wsl.localhost\Ubuntu-24.04\home<user><workspace>
• Codex runtime is Windows/PowerShell
• Explicit WSL access to the workspace works

Problem:

When working on a long-running task in a WSL-backed project, Codex sometimes chooses a filesystem-write command such as:

wsl.exe -d Ubuntu-24.04 --cd /home// patch -p0

or:

wsl.exe -d Ubuntu-24.04 --cd /home// python3 -

Codex Auto-review rejects the command before execution.

Example:

"The command executes unspecified Python supplied via stdin and explicitly permits filesystem writes despite calling itself read-only; without the payload and exact output path, its scope and side effects cannot be verified."

The critical problem is what happens next:

AFTER THE AUTO-REVIEW REJECTION, CODEX STOPS THE ENTIRE CURRENT TASK.

It does not automatically:

• continue reasoning;
• choose a safer write method;
• skip the non-essential write and continue the task;
• preserve and continue from the current research frontier;
• retry with a statically inspectable command;
• report the write as a non-fatal tooling boundary and proceed.

The task simply stops and waits for another user message.

The user must manually send something like:

"Continue"

before Codex resumes the task and then stops it again.

This is particularly disruptive for long-running reasoning/research tasks, because the rejected command may be only an incidental artifact/checkpoint write rather than a necessary part of the substantive task.

Observed behavior:

1. Codex performs a long reasoning/research task.
2. Codex itself decides to persist a checkpoint or artifact.
3. It generates a WSL write command.
4. Auto-review rejects that command.
5. Codex execution stops completely.
6. No fallback is attempted.
7. No further reasoning occurs.
8. The user must manually send a new message to resume the same task but Codex stops then for the same reason.

In some sessions this occurs after significant reasoning has already happened, which creates additional problems:

• wasted limited model/session quota;
• interruption of the current reasoning trajectory;
• additional context compression before continuation;
• risk that Codex resumes from a summarized state rather than the exact pre-rejection frontier;
• repeated recovery work;
• unnecessary user supervision for otherwise autonomous tasks.

There is also a related WSL-path issue in the same project:

Configured project folder:

\wsl.localhost\Ubuntu-24.04\home<user><workspace>

but the thread/runtime may use:

C:\home<user><workspace>

as its initial cwd.

That invalid cwd causes additional spawn_ready failures, while explicit:

wsl.exe -d Ubuntu-24.04 --cd /home// ...

works.

However, the Auto-review hard-stop described in this issue is independently problematic even when the WSL command itself is correctly targeted.

What steps can reproduce the bug?

1. Open a Codex Desktop project backed by WSL:
   \wsl.localhost\Ubuntu-24.04\home<user><workspace>

2. Start a sufficiently long task that causes Codex to create/update an artifact or checkpoint.

3. Codex generates a command such as:

   wsl.exe -d Ubuntu-24.04 --cd /home// python3 -

   or:

   wsl.exe -d Ubuntu-24.04 --cd /home// patch -p0

4. Auto-review rejects the command.

5. Observe that Codex stops the entire task immediately.

6. No fallback is selected and no reasoning continues.

7. Send "Continue" manually.

8. Codex resumes the same task, and then stops for the same reason.

Suggested improvement:

Treat Auto-review rejection as a recoverable tool exception in the agent loop, not automatically as a terminal task boundary.

Additionally, teach the planner not to select WSL write transports that cannot be statically inspected by Auto-review.

What is the expected behavior?

If Codex generates a command that Auto-review rejects, the rejection should be treated as a recoverable tool failure unless the rejected action is essential to the task.

Codex should automatically:

1. Preserve the current reasoning state.
2. Recognize that the attempted command was rejected.
3. Avoid retrying an equivalent opaque command.
4. Select an Auto-review-compatible alternative when possible.
5. If the write is non-essential, skip it and continue the substantive task.
6. If persistence is required but no safe write method is available, report a tooling boundary while continuing all work that does not require the write.
7. Stop the entire task only when the rejected action is genuinely required and no safe alternative exists.

In particular, an incidental checkpoint/artifact write should not terminate a multi-hour research task.

Expected fallback behavior could be similar to:

WRITE_COMMAND_REJECTED=true
WRITE_IS_NON_FATAL=true
SAFE_FALLBACK_AVAILABLE=<true/false>
TASK_CONTINUING=true

If no fallback exists:

ARTIFACT_WRITE_BOUNDARY=true

but Codex should preserve the result in the conversation and continue or complete the task rather than silently stopping execution.

Why this matters:

The issue is not merely that Auto-review rejects opaque stdin-based commands.
That rejection may be correct.

The defect is the interaction between:

• Codex choosing a command its own Auto-review cannot approve, and
• the agent runtime treating that rejection as a terminal stop for the entire user task.

For users with limited reasoning/session quotas, this can consume a meaningful part of the available quota while repeatedly interrupting otherwise valid work.

Additional information

No response

No implementation files or tests are named. Reproduce the WSL Auto-review rejection, then trace how that rejection propagates through the agent loop and task state; done means a rejected non-essential write no longer terminates the task, while required failures remain clearly reported.