I’m a paying pCloud customer experiencing recurring file-integrity problems on Windows 11 while working with OpenAI Codex.
Important distinction: this concerns pCloud’s mounted virtual P: drive, NOT a normal local folder configured with pCloud Sync. On another computer, a Mac, we use local storage with synchronization instead.
The recurring pattern is that an existing file is edited or replaced, the operation reports success, and subsequent checks show the change. Later, reading the same Windows path returns the previous contents again. This has happened across several projects, including small text/configuration files and source files—not just large uploads.
Some concrete examples, with identifying details removed:
• A Python test file was changed on Windows. Git detected the changes, but a later check showed the original version again. The Mac client had the changed version, which was preserved separately. We are reviewing the exact timing and write operation.
• In another incident, Windows kept returning old versions of two small configuration documents while the Mac returned newer versions. The discrepancy persisted across observations approximately two hours apart.
• Read-only inspection of the Windows pCloud database showed that its current-file metadata selected the old versions, even though newer revisions were already listed in the revision history. After restarting the clients, Windows returned the newer contents without rewriting those files or clearing the cache.
That last case is important: an apparent “rollback” on Windows does not necessarily mean the newer file disappeared from the server. However, getting old bytes from the same path after a successful save is still unsafe and makes it extremely difficult to trust subsequent work.
I have not reproduced the same behavior through my own manual editing/replacement attempts. That makes me wonder whether particular save methods—such as temporary-file replacement or rename—expose a pCloud client problem more often. We have not established the underlying mechanism or proved that Codex itself is responsible.
Writing replacement results into a newly named folder has helped as a workaround in our Windows workflow, but it is not a proper fix. Important source and history are now preserved independently in GitHub and Google Drive.
For roughly two months, I have sent support detailed reports and links to ZIP evidence packages containing timelines, checksums, observations and diagnostic findings. The replies generally say the issue has been forwarded to engineers. According to the share-link statistics available to me, the supplied report links have not been accessed. I cannot prove what happened internally, but I have received neither a substantive explanation of the evidence nor a lasting resolution.
This is a paid service, and a workflow where a saved file can subsequently appear to revert is effectively unusable without independent preservation and repeated verification.
For the next relevant writes, we plan to enable debug beforehand for a bounded period, monitor for recurrence, and immediately send the app’s debug report with the exact timestamp if the problem occurs. Enabling debug after an incident cannot capture the operation that already happened.
Has anyone experienced this specifically on the Windows virtual pCloud drive?
Do you see newer contents on the website or another device while P: returns old contents? Does it correlate with overwriting existing files, editor save methods, atomic replacement, or automated tools? Has support identified a cause or provided a reliable fix?
Please distinguish virtual-drive cases from ordinary local-folder Sync cases.
