CatGPT Worker newest version crashes at certain points - elevated sandbox might be culprit.

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

Version 26.818.21641

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Issue summary

I experienced an apparent ChatGPT application/session interruption while using ChatGPT Work for a long-running technical software-development task.

The Work session was actively executing a sequence of code inspection, test and build operations. During the process, the ChatGPT application/session interrupted unexpectedly before the current test gate had completed.

Importantly, the underlying work environment itself was recoverable. After the ChatGPT session returned, ChatGPT Work was able to determine that the interruption had occurred before the active test gate completed and resume from the appropriate point rather than repeating the entire workflow.

What I was doing

I was using ChatGPT Work on a substantial Windows software project involving:

• Python source inspection and modification
• pytest regression testing
• Windows subprocess/process-tree tests
• creation and validation of a production build
• multiple tool executions during one extended Work task

At the time of the interruption, ChatGPT Work was working through a test/build gate.

Observed behaviour

1. ChatGPT Work was performing the requested task normally.
2. A longer-running sequence of tool operations/tests was in progress.
3. The ChatGPT application/session unexpectedly interrupted/crashed before the current operation had completed.
4. The actual project/build process had not modified or completed the next build stage at the point of interruption.
5. After returning to the Work session, the model was able to inspect the existing state and continue from the interrupted gate.

This suggests that the interruption was associated with the ChatGPT client/session or Work execution environment rather than the software being developed.

Why this matters

Long-running Work tasks can involve substantial build and validation operations. An application/session crash creates uncertainty over:

• whether a tool process is still running;
• whether files were modified;
• whether a test/build completed;
• whether the operation should be restarted;
• whether restarting could duplicate or conflict with an existing process.

In this case ChatGPT Work recovered intelligently, but the interruption itself could be problematic for unattended or lengthy engineering workflows.

Environment

• Product: ChatGPT Work
• Platform: Windows PC
• Date: 20 August 2026
• Time zone: UK / BST (UTC+1)
• Subscription: ChatGPT Plus
• Workload: long-running software-development/build/test task

I can provide the exact timestamp, screenshots, conversation link, browser/application version, and any additional diagnostic information if required.

What steps can reproduce the bug?

Reproduction context

The issue occurred during an extended ChatGPT Work software-engineering session involving repeated tool calls and Windows build/test operations.

The immediate operation involved a Python/pytest validation gate for a Windows project.

The task included subprocesses that could run for several minutes, although the specific operation active when the ChatGPT interruption occurred had not yet completed.

What is the expected behavior?

Expected behaviour

A long-running ChatGPT Work task should remain connected and usable while tool executions, tests and builds are running.

If a client or session interruption does occur, ideally:

• the Work task should remain alive;
• current operation state should be preserved;
• the UI should reconnect automatically;
• the user should receive a clear indication that execution is continuing or has stopped;
• completed stages should not need to be repeated.

Additional information

Additional observation

After recovery, ChatGPT Work correctly determined that the interrupted test gate had not completed, preserved the previous successful diagnostic work, and resumed from that gate. That recovery behaviour was good; the issue being reported is the unexpected ChatGPT application/session interruption itself.

No source file, test, or entry point is named. Start by reviewing the Windows long-running tool-execution and session-recovery paths, then reproduce the interruption with the described Python/pytest subprocess and build workload; done means the interruption is explained and the task state remains usable or reconnects clearly.