Work/Codex stream repeatedly disconnects when the selected Windows workspace is OneDrive-backed and OneDrive is degraded

No source files or tests are named. Start by running the isolation matrix across local, OneDrive-backed, hydrated, and placeholder workspaces, comparing the request IDs and failure behavior. Done means identifying the failing layer and defining a reproducible provider-specific diagnostic or confirmed product fix rather than only the generic stream error.

What issue are you seeing?

In the ChatGPT Work / Codex surface on Windows, requests repeatedly fail with:

stream disconnected before completion: An error occurred while processing your request.

Two request IDs were generated during the same failure pattern:

• a394f90f-44e4-4450-b79d-6ef1eec533fd
• 13b73af7-c989-43fb-9b47-0837a7605e58

At the same time, the Windows workspace being used is OneDrive-backed, and the OneDrive client is in a degraded state because it reports that the Microsoft 365 subscription payment could not be processed.

The practical result is that Codex cannot complete work in the selected workspace. This is especially serious when the user believes the project is local, but Windows has resolved the folder through OneDrive.

The current evidence establishes a strong correlation between:

1. a OneDrive-backed or redirected local workspace,
2. a degraded OneDrive state,
3. and repeated Codex stream disconnections.

It does not yet prove which layer is the root cause. The failure could originate from workspace resolution, file availability, sync-provider behavior, backend request handling, or the interaction among them.

Environment

• Product surface: ChatGPT Work / Codex
• Platform: Windows desktop browser
• Model shown: GPT-5.6 Sol
• Workspace type: intended as local, but Windows/OneDrive appears to back or redirect the selected location
• OneDrive state: degraded; Microsoft 365 subscription payment error visible
• Date observed: 2026-07-26

What steps can reproduce the bug?

Primary reproduction

1. On Windows, use a folder that appears local in Explorer but is actually under a OneDrive-managed or OneDrive-redirected location, such as Desktop, Documents, or another Known Folder.
2. Put a Codex project or working files in that folder.
3. Put OneDrive into a degraded state, for example:
   • account or subscription problem,
   • sync paused or unavailable,
   • files not fully hydrated,
   • provider unable to complete access.
4. Open the folder in ChatGPT Work / Codex.
5. Ask Codex to inspect, edit, build, or otherwise operate on the project.
6. Observe whether the request enters reconnect attempts and then fails with:

stream disconnected before completion: An error occurred while processing your request.

7. Retry the same request.
8. Observe whether a new request ID is generated while the same workspace remains unusable.

Isolation matrix

Run the same project under these conditions:

Test	Workspace location	OneDrive state	Expected result
A	Folder outside OneDrive, e.g. C:\CodexTest	Degraded	Codex should still work
B	OneDrive-backed folder, files fully local	Healthy	Codex should work
C	OneDrive-backed folder, files fully local	Degraded	Codex should either work locally or show a provider-specific error
D	OneDrive-backed folder, Files On-Demand placeholders	Healthy	Codex should hydrate or clearly report unavailable files
E	OneDrive-backed folder, Files On-Demand placeholders	Degraded	Codex should fail fast with a clear workspace/provider error, not a generic stream disconnect

Additional controls

• Copy the same repository to C:\CodexTest and repeat.
• Disable OneDrive Known Folder Backup, then repeat.
• Mark the entire project Always keep on this device, then repeat.
• Disconnect OneDrive after ensuring all files are physically local, then repeat.
• Compare browser and desktop Work surfaces if both are available.

What is the expected behavior?

Codex should not become unusable merely because the selected folder is backed by OneDrive.

At minimum:

• If every required file is physically present, Codex should operate from the local filesystem without depending on OneDrive service health.
• If the workspace contains cloud-only placeholders or cannot be read, Codex should fail before starting the task and identify the actual cause.
• The UI should clearly state whether the selected workspace resolves to:
  • local filesystem,
  • OneDrive,
  • SharePoint,
  • or another sync provider.
• A storage-provider failure should not be surfaced only as a generic stream disconnected before completion error.
• Retrying should not produce repeated opaque request IDs without actionable diagnostics.

Actual behavior

• The request repeatedly enters a reconnect state.
• The stream disconnects before completion.
• The user receives only a generic processing error and a request ID.
• The workspace cannot be used productively in Codex.
• The UI does not identify whether OneDrive workspace access caused the failure.

Proposed mitigation

1. Resolve and display workspace provenance

Before a task begins, resolve and show the actual workspace source:

Workspace: Local filesystem
Resolved path: C:\CodexTest\project

or:

Workspace: OneDrive-backed local folder
Resolved path: C:\Users\<user>\OneDrive\Documents\project
Hydration state: Fully local / Placeholder / Unavailable

2. Add a preflight workspace check

Before opening a Codex task:

• enumerate required paths,
• detect reparse points / cloud file attributes,
• verify read and write access,
• detect offline placeholders,
• test creation and deletion of a temporary file,
• and report the exact failing path.

3. Decouple local execution from sync-provider health

When files are fully hydrated and writable, local Codex operations should use the local filesystem directly and should not require successful OneDrive sync or an active Microsoft 365 subscription state.

4. Fail fast with a provider-specific error

Instead of:

stream disconnected before completion

show something like:

The selected workspace is OneDrive-backed and one or more required files are unavailable locally. Move the project to a local folder or mark it "Always keep on this device".

5. Preserve diagnostics across reconnects

Attach to each request ID:

• resolved workspace path,
• provider type,
• file hydration state,
• first inaccessible path,
• filesystem error code,
• reconnect count,
• and whether failure occurred before or after the model stream began.

6. Add a local-only workspace option

Provide an explicit mode that rejects cloud-backed or redirected paths and accepts only verified local folders.

Why this matters

On Windows, Desktop and Documents are frequently redirected into OneDrive without the user treating them as cloud workspaces. If Codex silently depends on OneDrive availability, a billing, sync, account, or hydration problem can disable the entire coding workflow.

That blocks:

• local repository work,
• builds and tests,
• evidence-processing pipelines,
• large local datasets,
• and any workflow where cloud storage is intentionally not part of the trust boundary.

The user should not have to discover through a generic stream failure that a supposedly local workspace was operationally dependent on OneDrive.

Evidence captured

Screenshots show:

1. OneDrive reporting a Microsoft 365 subscription-payment failure while files remain under OneDrive management.
2. ChatGPT Work / Codex repeatedly reconnecting and then failing with the two request IDs listed above.

Scope and uncertainty

This report does not claim that OneDrive billing status itself directly causes the model stream to disconnect. It reports a reproducible failure class to test: Codex becomes unusable when a selected Windows workspace is OneDrive-backed and the sync provider is degraded, while the product surfaces only a generic stream error.