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

Update: I found a practical migration workaround in the Codex project UI.

1. Copy and verify the project outside OneDrive, for example:

C:\CodexProjects\ideas

1. Open Edit project in Codex.
2. Add the exact local project folder—not only its parent directory.
3. Remove the old OneDrive-backed folder association.
4. Start a new task from the newly registered local folder.

Important UI behavior: adding the local folder does not automatically replace the old OneDrive location. Both locations can remain associated with the same project, and Codex may continue retaining or selecting the OneDrive-backed location. Existing tasks also preserve their original OneDrive-backed working directory.

Therefore, this is only a manual workaround—not a root-cause fix. As long as Codex silently retains or prioritizes a OneDrive-backed path, users can be routed back into the same failure condition even after creating a valid local copy.

A product-level fix should:

• Prefer the exact local folder explicitly selected by the user.
• Never silently prioritize a previously registered OneDrive path.
• Clearly display which folder will be used before a task starts.
• Warn when multiple project roots exist or when the active root is cloud-backed.
• Provide a proper “move project” action that updates future task routing and detaches the old location.
• Allow a local-only mode that rejects OneDrive-backed or redirected folders.

This establishes a concrete workaround and exposes an underlying project-routing/design problem. It does not by itself prove that OneDrive caused every stream disconnection, but the workaround will remain fragile until the path-selection behavior is corrected.

Why I consider this a critical agent-boundary issue

This should not be treated only as a OneDrive compatibility or connectivity bug. The deeper issue is that the product may allow an agent to operate beyond the filesystem boundary the user believes they explicitly selected.

There is an important distinction from the recent Hugging Face security incident described by OpenAI:

• In the Hugging Face incident, agents escaped a sandbox and caused real impact to an external organization’s infrastructure while cyber safeguards had intentionally been reduced for evaluation purposes: https://openai.com/index/hugging-face-model-evaluation-security-incident/
• In this Codex issue, the observed failure concerns local path resolution and default workspace selection, potentially causing unintended interaction with the user’s own cloud storage. There is currently no evidence here of cross-tenant compromise or an agent attacking an external organization.

The blast radius is different, but the underlying safety class is related: the system has not reliably defined and enforced the boundary within which the agent is authorized to act.

If a user explicitly selects a local folder, that selection should be a hard authorization boundary. A stale, redirected, or previously registered OneDrive path must not remain eligible for automatic selection without explicit confirmation. Otherwise the agent can read from, write to, or operationally depend on a storage location that the user did not intend to place in scope.

For that reason, I believe this deserves critical-priority product and security triage rather than being classified solely as a generic stream-disconnection bug. If unintended reads or writes outside the explicitly selected workspace can be reproduced, it should also be evaluated under the applicable vulnerability or bug-bounty criteria.

The contribution in this report now includes reproduction evidence, isolation of the OneDrive dependency, a verified workaround, identification of the project-routing behavior, and concrete design requirements for remediation. I believe that is comparable to bounty-quality research and should be considered for researcher recognition or compensation, such as a bounty or Pro credit.

Two potentially relevant reports may help separate the shared symptom from the underlying state-management issue:

• #35057 independently reports persisted multi-root/project state surviving restart and preventing startup until the saved state was manually repaired. This appears structurally relevant to workspace/root-state persistence, although OneDrive involvement and the same root cause have not been established.
• #35574 reportedly described similar disconnect/reconnect/timeout symptoms on macOS with VS Code. This may serve as a symptom-level comparison showing that the generic disconnection message can arise under different conditions. The issue URL currently returns 404, so its present status cannot be confirmed.

These reports are referenced for comparison only; I am not asserting a common root cause.

Potentially related reports: #34341 and #34457 document new chats inheriting a stale selected-project, causing the effective cwd and writable root to point to an older workspace rather than the workspace currently shown in VS Code.

These reports strengthen the stale workspace-binding aspect of this issue. However, they do not establish that OneDrive degradation or the repeated stream disconnections reported here share the same root cause. I am linking them as related evidence rather than claiming causal identity.

Additional related evidence observed:

• #35730 reports an independent permission-state inconsistency: a workspace declared as a writable root is rejected by apply_patch as being outside the project. This appears relevant to the broader discrepancy between configured workspace state and effective runtime authorization described here.

• #35733 reports an adjacent persistence and routing issue: saved or discovered SSH connections are automatically restored on cold startup, and failures involving those remote connections can interfere with local chat hydration even when local work is intended. This indicates that persisted connection state can affect effective runtime routing beyond the user’s currently selected local context.

I am not claiming that these reports share the same root cause, that they are formal duplicates, or that OneDrive is involved in either case. I am linking them because they independently document discrepancies among persisted configuration, user-visible context, and effective runtime behavior.

Matched cross-platform validation would help determine whether the persisted workspace-state behavior documented here is Windows-specific or shared by the desktop architecture.

I do not currently have access to a dedicated macOS test environment. If OpenAI can reproduce the controlled protocol internally on a vendor-controlled macOS environment, or provide temporary access to an equivalent test environment, I can supply the exact steps and evidence schema for comparison.

Additional independent reports strengthen the background-activity branch of this issue cluster:

• #35775 documents persistent Git-origin polling across historical local and network workspaces associated with prior tasks. Uninstalling Codex stops the activity, while reinstalling it reproduces the polling and process growth.

• #35776 documents runaway background Git status, diff, and review activity continuing after visible work had ended in a valid active repository. The incident resulted in Windows commit exhaustion, application and DWM crashes, and a forced reboot.

Together, these reports show that Git-related background activity can continue beyond the user-visible foreground operation under different task and workspace conditions. Only #35775 directly supports continued activity involving historical task directories.

Neither report proves OneDrive access, an unintended effective cwd, or a shared root cause with this issue. No maintainer confirmation, formal duplicate determination, or linked fix PR has been identified.

Further framing based on continuing independent reports:

Recent issues do not support treating every stream disconnected or unusable-workspace incident as one defect.

• #35782 documents an app-server recovery/window-lifecycle failure under concurrent Windows tasks: stream disconnect, restart, route-window loss, EPIPE, and full Desktop termination. It contains no OneDrive, stale-cwd, or workspace-root evidence.
• #35803 documents a persistent Workspace Dependencies / command-dispatch failure in which no child process starts and no model call is involved. Recovery required Reset and Install Workspace. It does not report a stream disconnect or unintended effective root.

This divergence suggests a narrower observability hypothesis: generic surface states such as stream disconnected before completion, reconnect loops, or an unresponsive task may function as catch-all abstractions that conceal materially different underlying failures.

In this issue, the generic disconnect symptom coincided with a OneDrive-backed workspace association that survived restart and required explicit folder rebinding, removal of the old association, and a fresh task to restore future-task routing. Existing tasks retained their original cwd.

I am not claiming intentional concealment, product-wide causation, formal duplicate status, or a shared root cause with #35782 or #35803. The testable requirement is that diagnostics distinguish transport failure, app-server recovery failure, command-dispatch failure, workspace-root selection, permission-state mismatch, and cloud-provider availability, while recording the effective cwd and workspace roots at the time of failure.

For triage, the security relevance of this issue should be evaluated on the retained effective workspace state and authorization/provenance mismatch after visible source-folder removal—not on the generic disconnect string alone.

Three additional comparison cases are relevant to the observability boundary in this issue, without establishing a shared workspace or OneDrive root cause:

• openai/codex#35613 provides a reduced reproduction in which Code Mode reports Script completed while nested exec processes remain live and their model-visible control handles have been discarded.

• openai/codex-security#37 provides a deterministic injected-event reproduction in which certain unexpected turn.failed payload shapes fall through to CLI exit code 0 and complete-scan. Whether those payload shapes are reachable in a normal production scan remains unconfirmed.

• openai/codex#35810 reports the opposite-direction discrepancy: across ten tool-enabled App Server runs, the final assistant output and a valid task artifact were produced, but turn/completed was never emitted and the client waited until timeout.

These reports do not show that the OneDrive-backed workspace retention, stale effective cwd, or stream disconnections described here share their root cause. Their relevance is narrower: visible completion, protocol completion, generated artifacts, and effective runtime state can diverge, so diagnostics for this issue should record the effective cwd, workspace roots, authorization state, process state, raw tool error, and transport state together rather than relying on a generic surface status.

Two opposite-direction corroboration reports strengthen the workspace-binding portion of this issue:

• #35260 documents an existing Codex Desktop task where a secondary folder shown as attached in the UI remains absent from the injected workspace_roots and writable permission entries. Writes to that folder fail with Operation not permitted, and the mismatch persists across subsequent turns.

• #35634 provides a controlled existing-task versus fresh-task comparison under the same saved-project configuration. After a Source folder is added, the existing task still lacks the folder in its effective workspace roots and cannot read it, while a newly created task receives the root and successfully reads an actual file from it.

These reports show the opposite-direction failure: newly configured roots may fail to propagate into an existing task's effective authorization state. This complements the stale/detached-root retention observed here, but does not establish a shared root cause, formal duplicate status, or OneDrive involvement.

Three prior cross-environment reports provide additional direct workspace-binding evidence:

• #25250 documents a new-chat screen visibly associated with an SSH remote project while the composer retained an unrelated Cloud environment. The persisted state simultaneously pointed active-workspace-roots at a Windows local project and active-remote-project-id at another remote project; repair required fully quitting Desktop before clearing the stale selectors.

• #18506 includes a controlled Windows/WSL state-persistence observation: after saved WSL roots were changed from UNC values to canonical POSIX paths, Desktop later rewrote its in-memory workspace state and restored the UNC values, including a root that had initially remained corrected.

• #21147 documents the selected WSL execution context failing to propagate into a fresh interactive thread. Despite WSL configuration, the thread received shell=powershell and an invalid Windows cwd; removing the generated invalid project entry did not persist because Desktop recreated it on the next thread launch.

These reports extend the observable workspace-binding mismatch across local, Cloud, SSH, Windows, and WSL contexts. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

Three additional reports provide direct comparison evidence for workspace-root authorization propagation:

• #35934 documents an app-server task sent with workspace-write (and a persisted job record containing "write": true) while the effective session reports a read-only sandbox and rejects writes inside the selected repository. This is an opposite-direction configured-write versus effective-read-only mismatch.

• #35864 documents a controlled Windows CLI case with split writable roots: file creation succeeds, but update and delete fail during sandbox preparation when the legacy writable-root projection differs from the split writable-root set. The reporter's proposed patch makes all three operations pass, but the diagnosis and fix have not been confirmed by an OpenAI maintainer.

• #35748 documents one literal Windows workspace root being accepted by the main Codex session while a nested Node REPL reinterprets the same bracket-containing path as a glob and exits before executing JavaScript. This shows divergent authorization semantics for the same configured root across runtime layers.

These are authorization-propagation comparisons, not evidence of stale-root persistence in each case. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

Official architecture description relevant to runtime workspace and authorization binding

OpenAI’s 29 July engineering post provides an official architectural description relevant to this issue:

https://openai.com/index/gpt-5-6-frontier-intelligence-efficiency/

The post describes the shared Codex and ChatGPT Work agentic harness as:

“a Rust orchestration layer connecting our models, tools, and the user’s environment.”

It also states that tasks may involve repeated model requests and tool calls, that environment updates are added to model-visible history, and that runtime settings such as approval policies are applied during execution rather than being embedded in tool definitions.

This does not prove that the shared harness caused the stale-root behavior in this issue, nor does it establish a shared root cause with the related reports cited above.

It does, however, clarify the relevant architectural responsibility: the effective workspace root, writable-root set, approval state, tool execution context, and user-visible project state must be correctly bound and reconciled by the runtime orchestration layer.

In this issue, the saved-project configuration was changed and the old source folder was removed, while an existing task retained its original detached cwd. Related reports document both stale-root retention and the opposite-direction failure in which newly configured roots do not propagate into an existing task’s effective authorization state.

The official architecture description therefore strengthens the need to identify and test:

• which runtime component resolves the effective cwd and workspace_roots;
• whether those values are snapshotted per task or reconciled against the current saved-project state;
• when removing a source folder revokes, suspends, or preserves existing-task authority;
• whether background operations use the task’s retained root or the currently visible project configuration;
• how approval policy and writable-root state are bound to the selected workspace; and
• whether an audit record can reconstruct the visible project state, persisted project state, effective runtime authorization, and resulting tool actions together.

Because runtime authorization is applied during execution, the project state displayed in the UI cannot by itself establish which filesystem boundary was actually enforced for a task.

This source strengthens the architectural relevance of the workspace-binding and authorization-propagation mismatch. It should not be treated as proof of a specific implementation-level root cause.

Two new Windows reports add direct workspace/root comparison evidence:

• #36105 documents a projectless task initially receiving C:\Users\<user>\Documents\Codex\... even though the Windows Documents Known Folder was verified as D:\Users\<user>\Documents and the C: location was only a junction. Later in the same task, the environment exposed the D: path directly. This is a same-task canonical-path and workspace-root inconsistency under verified Known Folder redirection; the report explicitly states that OneDrive is not involved.

• #36087 documents a local repository included in the configured writable roots under workspace-write, while normal sandboxed reads and apply_patch fail during deny-read ACL setup. Equivalent operations succeed with escalation, and the failure persists after moving the repository, adding the new directory as the project folder, fully exiting, and restarting Desktop. This is opposite-direction configured-write versus effective sandbox-denial evidence with rebind and restart controls.

These reports strengthen the observable workspace-path and authorization-propagation boundary. They do not establish a shared root cause or formal duplicate status; only #36105 expressly rules out OneDrive for its own reproduction.

Two realtime-voice reports add a cross-platform same-condition comparison for project-to-task workspace propagation:

• #35452 documents three consecutive Windows Voice tasks started from a saved local project receiving projectId = null and generated Documents\Codex\...\realtime-voice-chat working directories instead of the repository. The tasks consequently lacked the project's AGENTS.md and repository files.

• #36195 documents the same observable direction on macOS: a realtime Voice chat started while a local project was active ran from a generated projectless Codex workspace rather than the selected repository, while the report limits the behavior to realtime Voice task creation.

Together, these reports show the user-visible active project failing to propagate into a newly created task's effective workspace association across two desktop platforms. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement; the automated potential-duplicate suggestion on #36195 is not maintainer confirmation.

@hiroki-tamba-research check my fix @ https://github.com/PerikiyoXD/codex/commit/381acb1

@hiroki-tamba-research check my fix @ PerikiyoXD@381acb1

Thanks, but I am the reporter of this issue, not an OpenAI maintainer or patch reviewer.
I am focused solely on documenting and reproducing the critical workspace-routing and disconnection behavior reported here. I do not review, run, or validate commits from third-party forks.
If you believe you have a fix, please open a focused PR against openai/codex with a reproduction, tests, and a clear explanation of how it addresses #35420, and request review from the maintainers. Please do not tag me for reviews of external patches.

Ok LLM.

A newly added controlled reproduction in #28094 documents existing-task host/cwd rebinding across an Agent Environment change.

On Codex Desktop 26.721.11231.0, a task created while the Agent Environment was set to WSL retained the same task/session ID and initially reported a cwd under:

/home/<wsl-user>/<project>

After the global Agent Environment was switched to Windows, reopening or continuing that existing task produced a later-turn cwd under:

C:\home\<wsl-user>\<project>

The Windows backend then rejected that translated path as invalid.

This is relevant to the task-lifecycle workspace-binding boundary described in this issue: conversation identity persisted while the effective execution host and path semantics changed. It does not establish a shared root cause, formal duplicate status, or any connection to OneDrive.

Two reports add direct evidence that task identity, project membership, cwd, and destination host can diverge during lifecycle transitions:

• #11022 now includes a Windows relocation reproduction on Codex Desktop 26.721.11231.0. After a project was moved across drives and re-added, 12 active tasks remained readable and their cwd values matched the new root, but they returned projectId: null, lacked thread-project-assignments, and did not appear under the saved project. Desktop and iOS Remote showed different project membership, while persisted saved-workspace roots still included the obsolete path.

• #36412 documents a saved SSH project being discovered with the correct remote host and Git identity, followed by non-returning project-scoped creation calls. A later projectless fallback produced a task with no project association; an independent control returned hostId: local and a Windows output directory, while retrying with the saved remote project completed on the expected SSH host. The wrong-host task was stopped before mutation.

Together, these reports show project/cwd migration and project/host routing diverging in different directions. They are relevant to the task-lifecycle workspace-binding boundary described here, but do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

One additional Windows report adds direct task-lifecycle evidence relevant to project-root reconciliation:

• #34499 documents an active Work task using a .codex\.chatgpt-projects\g-p-* project mirror as its cwd while a later project synchronization attempts to replace that same root and fails with EBUSY / resource busy or locked. Existing project-backed tasks continue to work, a restart may temporarily allow one new task, and subsequent project-scoped task creation can fail again. A current 2026-08-01 reproduction reports the failure still present in the latest Windows Desktop update, while an equivalent web-created Work task succeeds and then synchronizes back to Desktop.

This is relevant because it shows an existing task's retained cwd affecting later project-root reconciliation and new-task creation. It does not establish a shared root cause, formal duplicate status, or OneDrive involvement.

Two new reports add direct evidence that user-selected execution scope and effective runtime state can diverge in both directions:

• #36514 provides a source-level reproduction in which codex -C /path/to/repository-b apply <task-id> drops the parsed root --cd value, falls back to the process current directory, and can successfully patch repository A while repository B—the explicitly selected target—remains unchanged.

• #36497 documents the opposite authorization direction on Windows Desktop: after a thread is reopened or the app restarts, later turn_context records silently change from danger-full-access / approval_policy: never to workspace-write / on-request. Some reverted turns expose only the thread visualization directory in writable_roots, so repository writes require escalation despite no visible user change.

These reports strengthen the distinction between requested or displayed scope and the effective cwd/writable-root authorization used at execution time. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

One newly added macOS report provides direct cross-project writable-root propagation evidence:

• #24224 documents a Project A task whose saved project assignment and cwd remained correct, while Project B was appended to its next turn's workspace_roots after a separate Project B task had been active. Project B also appeared as an explicit writable entry in the managed filesystem permission profile, and the incorrect root persisted in the task's per-thread thread-writable-roots state. Restarting or creating replacement tasks can produce a clean successor, but does not repair the contaminated writable-root list of the existing task.

This is direct evidence that an unrelated project's root can enter and remain in an existing task's effective filesystem authorization despite the saved single-folder project assignment remaining unchanged. It does not establish a shared root cause, formal duplicate status, or OneDrive involvement.

One current Windows report adds direct advertised-root versus effective-authorization evidence:

• #33806 now includes a Codex Desktop 26.727.6591.0 reproduction where <special>:slash_tmp is advertised as a writable root mapped to C:\tmp. Sandbox setup reports three write roots with errors=[], but C:\tmp retains an older synthetic restricted-SID ACE rather than the SID present in the current command token, so a bounded file create fails with Access denied. Adding only the current token's corresponding restricted SID makes the same create/delete probe succeed.

This demonstrates that a configured writable root and a successful setup status do not necessarily establish effective token-to-root writability. It does not establish a shared root cause, formal duplicate status, or OneDrive involvement.

One additional macOS report provides opposite-direction project-binding evidence:

• #36548 documents a previously working pinned thread becoming unable to accept any new message because the app requires the user to “Select a project to continue.” Reopening the same local repository does not restore the association, and the saved project shows “No chats” while the affected thread remains visible and readable.

This is a loss-of-association case rather than retention of an old root, and no reliable intentional reproduction is currently documented. It is relevant as an opposite-direction persistence and recovery comparison, but does not establish a shared root cause, formal duplicate status, or OneDrive involvement.

Two newly filed reports add direct workspace-state comparisons:

• #36608 documents an existing Windows-native chat retaining its Windows cwd, PowerShell shell, workspace roots, and permission-profile state after the app is switched to WSL. The reported cwd becomes a malformed WSL/app-resource path containing the old Windows path. Moving the chat into a valid WSL project and using “Continue in new chat” both preserve the broken binding, while a completely new chat in that WSL project uses the correct /mnt/d/... cwd and bash.

• #36631 documents a Dropbox-backed Windows workspace where the spawned command process receives the workspace directory, but PowerShell Get-Location falls back to C:\, causing relative commands to use the wrong directory. The provided control says the mismatch does not occur for a normal local folder, and the affected Dropbox directory is a reparse point.

The first report strengthens the persisted old-environment binding and failed-rebind pattern. The second is an independent cloud-backed/reparse-point cwd divergence, not evidence that Dropbox and OneDrive fail identically. These reports do not establish a shared root cause, formal duplicate status, or OneDrive involvement in either case unless explicitly stated above.

One newly filed Windows migration report adds direct project-mapping persistence and recovery evidence:

• #36663 documents migration from the prior Codex Windows app to the unified ChatGPT Desktop app leaving the underlying threads and their original cwd values intact in state_5.sqlite, while local-projects and/or thread-project-assignments were absent or incomplete. Historical conversations appeared individually in Recents, and reopening the same project folders did not reattach them. Reconstructing the missing project definitions and assignments from the surviving thread-to-cwd records restored the project organization and persisted across restart, provided all desktop processes were stopped before replacing the state so stale in-memory state could not overwrite the repair.

The report covers a mixture of ordinary Windows, OneDrive-backed, and WSL/UNC roots, so it is direct evidence of association loss during migration rather than evidence that any one provider is required. It does not establish a shared root cause with this issue, formal duplicate status, or OneDrive involvement beyond the explicitly reported affected-path mixture.

One independent Windows report adds same-condition corroboration for projectless-workspace path resolution:

• #36760 reports Codex App 26.727.51351 creating projectless-chat workspace, work, and output directories under the physical %USERPROFILE%\Documents\Codex path even though Windows shell:Personal opens the user's redirected Documents Known Folder. The reporter states that this places those artifacts outside the expected redirected backup/synchronization location and notes that existing chats retain absolute workspace paths in local state.

This independently reinforces #36105's observed Known Folder mismatch on a different app build, while adding a physical artifact-location and migration consequence. It does not establish a shared root cause, formal duplicate status, or that OneDrive is required for every redirected-Documents reproduction.

Regarding the original issue "when the selected Windows workspace is OneDrive-backed and OneDrive is degraded". I believe Microsoft has been slowly changing the behavior of Windows and Apps to refer to the OneDrive copy as primary.

Apparently, because if user has references to local documents he cannot work seamlessly from another device if apps or documents reference Users\username\OneDrive\Documents that don't exist on that device. So, they want apps to reference https://d.docs.live.net/5B64BBA6F58C1D08/Documents/etc/myfile.docx which would work from any computer.

In essence, the file is on OneDrive and it is the local drive that is the backup. I don't know if you have found a workaround or the OneDrive still is degraded (or subscription unpaid), but if you temporarily set OneDrive to Stop Syncing or just disable OneDrive client it would just work locally while you get OneDrive back.

Thanks, but this does not address the issue reported here.
The unresolved point is not whether OneDrive can be disabled or whether Windows increasingly treats the OneDrive copy as primary. I already documented a working manual migration procedure:

1. Copy and verify the project outside OneDrive.
2. Add the exact local project folder to Codex.
3. Remove the old OneDrive-backed folder association.
4. Save the project.
5. Start a fresh task.

Restarting Codex Desktop did not clear the old association. Existing tasks continued to retain their original OneDrive-backed cwd after the saved project had been rebound to the local folder. Disabling OneDrive may change file availability, but it does not update Codex’s persisted project/task mapping, migrate existing tasks, or revoke their retained workspace authority.
The issue is therefore the divergence between:

• the source folder currently shown in the saved-project UI;
• the persisted project and task associations; and
• the effective cwd, workspace_roots, and writable authority used by an existing task.

Using a d.docs.live.net path would also move in the opposite direction from the local-only trust boundary being requested here.
The practical workaround has already been found. The remaining product issue is that Codex silently preserves a detached root without clearly displaying it, requiring reauthorization, or providing a supported migration mechanism.

________________________________
差出人: Ivan Torres @.*>
送信日時: 2026年8月4日 1:20
宛先: openai/codex @.*>
CC: Hiroki Tamba @.>; Mention @.>
件名: Re: [openai/codex] Work/Codex stream repeatedly disconnects when the selected Windows workspace is OneDrive-backed and OneDrive is degraded (Issue #35420)

[https://avatars.githubusercontent.com/u/28674917?s=20&v=4]itorres008 left a comment (openai/codex#35420)<https://github.com/openai/codex/issues/35420#issuecomment-5168955139>

Regarding the original issue "when the selected Windows workspace is OneDrive-backed and OneDrive is degraded". I believe Microsoft has been slowly changing the behavior of Windows and Apps to refer to the OneDrive copy as primary.

Apparently, because if user has references to local documents he cannot work seamlessly from another device if apps or documents reference Users\username\OneDrive\Documents that don't exist on that device. So, they want apps to reference https://d.docs.live.net/5B64BBA6F58C1D08/Documents/etc/myfile.docx which would work from any computer.

In essence, the file is on OneDrive and it is the local drive that is the backup. I don't know if you have found a workaround or the OneDrive still is degraded (or subscription unpaid), but if you temporarily set OneDrive to Stop Syncing or just disable OneDrive client it would just work locally while you get OneDrive back.

—
Reply to this email directly, view it on GitHub<https://github.com/openai/codex/issues/35420?email_source=notifications&email_token=CCIQGAISMTLLQ3NTPTP7N635IC3VXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJWHA4TKNJRGM42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5168955139>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/CCIQGAMVRBT34BADAFVNVO35IC3VXAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TIOJXHA3TCMBYGU3KC5QC>.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/CCIQGAOUEZYPDDYSRGV6QML5IC3VXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJWHA4TKNJRGM42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/CCIQGAPOEV53XXR3L3VMHXL5IC3VXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJWHA4TKNJRGM42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today!
You are receiving this because you were mentioned.Message ID: @.***>

One additional independent report adds a direct task-permission persistence comparison:

• #36725 documents macOS exact workspace roots containing literal glob metacharacters being rejected when the permission profile is recompiled for Computer Use or another nested runtime. A control workspace without those characters succeeds. The report also states that a clean alias plus a separate permission profile allows a fresh task to initialize, while existing tasks retain stale permission state.

This is adjacent exact-path serialization and task-snapshot evidence, not evidence that OneDrive or Windows Known Folder routing is involved. It does not establish a shared root cause or formal duplicate status.

Three independent reports add direct workspace/project-state comparisons:

• #37212 reports that after a Windows app update and sign-out/sign-in, existing threads remain accessible while the Projects section is empty. Old-thread tooltips still show the original project names, but recreating a project with the exact prior folder leaves it at “No chats” and does not reassociate those threads. This is same-direction project-index and failed-reassociation evidence.

• #37110 reports recurring post-update drift of intentionally WSL-backed project roots from Linux /home/... form into Windows UNC forms. Git works for the same project inside WSL, while Desktop logs report Windows-side Git/worktree failures. The reported repair only persists when Desktop is fully quit so in-memory state cannot overwrite the normalized configuration.

• #37021 reports the opposite-direction projection mismatch: an existing local-project task is returned with projectId: null even though its direct thread-project-assignments entry, project runtime kind, cwd, and configured roots are correct. A new control task is listed correctly, and a full quit/restart reconciles the stale task-list projection.

These reports independently strengthen the state-synchronization and recovery comparisons. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

One additional high-signal report adds a direct project-migration binding failure path:

• #35167 documents a Windows thread move where persisted state was half-applied: SQLite thread.cwd and workspace applied.cwd remained on Project A, while thread-project-assignments and workspace pending.cwd pointed to Project B with pendingCoreUpdate: true.
• The app became unusable with a startup failure, and the state survived restart and reinstall until the thread’s pending migration/project-assignment was removed and the thread was marked projectless.

This is a migration/rollback-drift and persistence control comparison for workspace-state coherence. It does not establish a shared root cause, formal duplicate status, or OneDrive involvement unless those are explicitly established in the cited report.

Three independent reports add direct project-association lifecycle comparisons:

• #36077 documents a deleted Windows local project disappearing from the sidebar and current project list while remaining selectable under Settings > Environments after restart, even though its original directory no longer exists. References persisted across project assignments, trusted-path state, backup state, and metadata until coordinated cleanup was performed with Desktop fully stopped.

• #35135 documents a projectless thread moved into a Project retaining its generated execution cwd. After that Project is deleted and recreated with the same physical folders, the thread remains tied to the deleted project identity and disappears from both the recreated Project and Recents while its session data remains on disk. This directly separates organizational project assignment from execution cwd.

• #37465 documents a VS Code-created thread with the correct repository cwd appearing and opening normally in Recents, with Desktop resolving the matching local folder, while the thread remains absent from the matching Desktop project after restart. A Desktop-created control thread for the same repository is grouped correctly.

These reports independently strengthen the project-association, cwd, and persisted-state synchronization comparisons. They do not establish a shared root cause, formal duplicate status, or OneDrive involvement.

New direct recurrence: OneDrive-excluded work was rebound to a OneDrive-backed root

On 12 August 2026, Codex Desktop again presented and used a OneDrive-backed root for the project named Github, even though OneDrive had been explicitly excluded from the authorized scope of the controlled work.

The current observable state is:

• the Codex project UI displays a root under C:\Users\<user>\OneDrive\Documents\ChatGPT\Github;
• the task environment advertises the same OneDrive-backed path as its primary writable workspace root; and
• shell operations for the task are launched with that OneDrive-backed directory as the working directory.

This is inconsistent with the controlled setup documented in #34179, comment 5240369823. That reproduction deliberately used isolated disposable trusted Git worktrees, an explicit --cd <DISPOSABLE_TRUSTED_WORKTREE>, and controls that separated the Windows sandbox/helper failure from OneDrive, Git, project trust, and ordinary host write permission.

The issue here is therefore not that a user knowingly opened a project stored in OneDrive. The issue is that Codex selected or retained a OneDrive-backed project/root after the user had defined OneDrive as outside the workspace boundary for this work. This is a fresh instance of the routing/provenance problem described earlier in this issue.

This observation establishes project/root rebinding and execution from the OneDrive-backed cwd. It does not by itself establish unintended file reads or writes, data exfiltration, or that the sandbox failure in #34179 was caused by OneDrive.

Please determine from internal project, task, and thread state:

1. which persisted record selected this OneDrive root: saved-project configuration, stale task state, a duplicate same-named project, or fallback/default routing;
2. why the explicitly selected local/disposable worktree and OneDrive exclusion did not prevent that root from becoming effective;
3. whether the root was restored from stale in-memory or on-disk state after project migration;
4. whether any background Git or filesystem operation used the OneDrive-backed root before the UI exposed the mismatch; and
5. what enforcement boundary is intended to prevent a path explicitly removed from scope from later becoming the effective cwd or writable workspace root without renewed confirmation.

A local-only or excluded-root policy needs to be enforced as an authorization constraint, not treated as a preference that stale project state can override.

Stronger local-state evidence: this is not limited to an old task retaining its cwd

A read-only inspection of the current Codex Desktop state on 12 August 2026 shows a stronger condition than the detached-existing-task behavior previously reported.

The persisted state contains all of the following:

• a local-projects record named Github;
• that record's only rootPaths entry is the OneDrive-backed path C:\Users\<user>\OneDrive\Documents\ChatGPT\Github;
• createdAt and updatedAt are both 2026-08-12 15:10:17.651 JST;
• selected-project points to that same project record;
• three task/thread assignments, including the current task, point to that same project and OneDrive-backed cwd; and
• each assignment has pendingCoreUpdate: false.

The app's structured project listing independently returns the same Github project with the OneDrive-backed path. The newly verified local copy at C:\CodexProjects\Github is not registered as the project root.

There is also an internal state divergence: electron-saved-workspace-roots does not contain the OneDrive-backed Github root, while local-projects, selected-project, and thread-project-assignments do contain and actively use it.

This means the current case cannot be explained only as an old task retaining an immutable historical cwd. Codex persisted a current local-project record whose only root is the excluded OneDrive path, selected that project, and treated multiple assignments as fully applied rather than pending migration.

Independent cross-store confirmation

The app build in this observation is 26.803.10989.0.

A separate read-only query of state_5.sqlite confirms that the canonical threads.cwd column stores the same OneDrive-backed path for all three affected tasks. One of those rows is the task used to resume the real runtime-demo recording after full operation permissions had been enabled for the YouTube capture. Therefore this is not only a renderer/sidebar projection or stale tooltip value: the durable thread database independently agrees with the OneDrive cwd.

The separate thread-writable-roots state also advertises the same OneDrive path as writable for each of the three tasks.

No state file has been modified during this inspection. The exact local project and thread identifiers are retained privately for internal correlation.

Please determine:

1. which code path created the Github local-project record at 15:10:17.651 JST;
2. what source supplied the OneDrive path to that creation path;
3. why the user's OneDrive exclusion/local-only intent was not enforced;
4. why electron-saved-workspace-roots disagrees with the active local-projects and assignment state;
5. why the assignments are marked pendingCoreUpdate: false despite the provenance mismatch;
6. whether project creation, project selection, thread assignment, and effective workspace-root updates are committed atomically or can be reconstructed from different stale state stores; and
7. why the durable threads.cwd and writable-root state accepted the excluded OneDrive path for a task operating with full permissions.

This is direct persisted-state evidence of a project/root selection and authorization-provenance defect, not only a OneDrive connectivity symptom. It still does not by itself establish unintended file content access or exfiltration.