Repository navigation
ChatGPT dots: previously working cloud-computer files unavailable; later Reboot test did not reproduce #49682
Description
What issue are you seeing?
Files for a previously working service on a dot's cloud computer could no longer be found later the same day. A previously open desktop terminal was also no longer present.
The service directory was under /workspace/shared/<service> (name redacted). A synthetic callback test succeeded in the morning, and the service was subsequently verified running. Later checks could not find that directory from either the execution environment or the cloud desktop.
This concerns the dot's own Linux cloud computer, accessed through the macOS desktop app, rather than a repository-backed Codex Cloud task. The available evidence does not establish whether files were deleted, the environment was replaced, a different environment was attached, or another lifecycle event occurred.
Approximate timeline, all UTC on September 30, 2026:
- 09:25–09:50: A synthetic callback succeeded and the service was verified running.
- Shortly before 16:00: First user-initiated Reboot.
- Around 16:00: Investigation found the earlier service directory and desktop terminal unavailable.
- Current-environment diagnostics showed a kernel boot time around 14:15 and a
/workspace/shareddirectory birth time around 14:20. - Around 16:50: A second, controlled Reboot test did not reproduce the disappearance.
The morning environment's hostname and boot identifier were not recorded, so there is no before/after identity comparison for the original incident. The current kernel boot time is not evidence of when the dot attached to that environment, and the directory birth time does not establish why the earlier files became unavailable. The relationship between the first Reboot and the original incident remains unknown.
What steps can reproduce the bug?
There is no reliable reproduction yet. The observed sequence was:
- Create and run a small bridge service under
/workspace/shared/<service>on the dot's cloud computer. - Verify a synthetic callback and working service.
- Return later and inspect the service directory and desktop.
- Find the earlier directory unavailable and the earlier terminal no longer present.
To test whether the Reboot control caused the loss, a later controlled test recorded six marker files and their SHA-256 hashes before and after Reboot:
- Execution side: temporary directory, shared directory, task scratch directory.
- Desktop side: temporary directory, home directory, user-local data directory.
All six marker hashes matched afterward. Four sampled preinstalled application-file hashes also matched. The observed hostname, kernel boot identifier, and overlay-mount identifier remained unchanged, and the desktop terminal remained present.
Therefore, this test does not support claiming that Reboot consistently wipes files. It also did not show a kernel reboot.
The execution and desktop surfaces had separate temporary/home namespaces. The missing service directory was checked under the shared path from both surfaces.
What is the expected behavior?
Previously created files should remain available within the supported persistence scope of the dot's cloud computer. If a lifecycle operation replaces an environment or discards particular storage, the product should make that scope clear and provide appropriate warning and recovery guidance.
The cloud computer documentation says the computer can keep state between periods of use. It does not establish durability guarantees for these individual directories or for running processes.
Additional information
Please help investigate:
- Which directories persist across idle periods, Reboot, reconnection, and environment replacement?
- What does the Reboot control restart, and when can it replace storage?
- Could an environment-association or lifecycle change explain previously working files becoming unavailable?
- Is there a supported recovery or snapshot mechanism for the earlier filesystem?
Root cause is unknown, and the controlled test did not reproduce the original incident. A stopped process alone would not explain a missing service directory.
This public report intentionally omits account and organization details, credentials, private endpoints, service identifiers, exact machine identifiers, and internal task IDs.
Activity
kim-haneol commentedon Oct 1, 2026
I believe I encountered the same or a closely related issue with a dot's cloud computer.
In my case, the computer had been working normally with an Obsidian vault synced to it and an active Google login in the cloud browser. Later it showed Offline. After I sent the dot another message, the computer changed to Starting and eventually came back online.
After that, both the synced Obsidian vault and the Google browser session were gone.
I did not manually use the Reboot control, so my observed lifecycle was specifically Offline → Starting rather than an explicit reboot.
The fact that both filesystem state and browser-session state disappeared at the same time made it look like the previous environment or its persistent state had not been restored.
This occurred on September 30, 2026 (KST).
Roland0511 commentedon Oct 1, 2026
Follow-up observations on October 1, 2026, compared with the September 30 baseline: after the cloud execution environment became available again, its observed hostname and kernel boot identifier had changed. The old terminal was not visible in the current desktop session.
Of the six test markers from the earlier experiment:
/workspace/sharedand the task scratch directory./tmp, plus the desktop/tmp, home, and user-local-data locations.This differs from the earlier controlled test using the Reboot action, after which all six markers remained and the observed identifiers were unchanged.
The trigger and exact transition time are unknown. These observations do not distinguish deletion from attachment to a different environment, establish persistence guarantees, or explain the original missing service under
/workspace/shared.Could you clarify which lifecycle transitions preserve these locations and whether recovery of the earlier environment is available?
Exact environment identifiers, marker filenames and hash values are omitted from this public follow-up.
Roland0511 commentedon Oct 1, 2026
Further observation on October 1, 2026 (UTC): newly rebuilt files became unavailable again within the same day.
After the earlier report, I rebuilt the source under
/workspace/shared/<service>and placed local recovery copies under/workspace/shared. By approximately 11:48 UTC, the source had also been backed up externally, downloaded again, verified against its file manifest, and tested successfully.At approximately 12:39 UTC:
/workspace/sharedwas still present. Its hash was not rechecked in this observation.The exact transition time and trigger are unknown. These observations do not establish whether this was rollback, attachment to a different environment, or another failure.
This affects newly written files and saved configuration, beyond whether a background process stays running. In this observed workflow, I cannot rely on the cloud computer retaining work state even across the same day. Rebuilding and repeating authentication is not a workable solution if the resulting state becomes unavailable again.
The official documentation says the cloud computer can keep its state between periods of use:
https://learn.chatgpt.com/docs/dots/computers-and-apps
Please investigate state saving/restoration or environment attachment, clarify which writes are durable and when, and whether the missing recent state can be recovered. The practical impact is lost work continuity and repeated setup/authentication.
No credential values, private repository details, exact host identifiers, or private logs are included in this report.
discko commentedon Oct 2, 2026
Consolidated report: environment changes and data loss, September 30–October 11, 2026
This concerns my dot’s own cloud computer.
Combining my earlier report with subsequent monitoring, I have recorded:
That is 12 distinct loss/regression events in total, or 11 excluding the temporary-file-only case. Repeated checks of the same unresolved absence are not counted as new losses.
Timeline
All dates and times below are UTC, in 2026. These are observation times. Environment changes were identified from hostname and, where recorded, kernel boot ID.
An empty loss cell means no new loss was recorded at that observation. It does not mean every file was checked or previously missing files had returned.
The last two rows do not represent recovery of shared files: the earlier absence continued, while the scratch monitoring file retained its latest verified contents.
How the observations were checked
The later monitoring uses three existing files named dot-persistence-test-20261001.txt under /workspace/shared/, /workspace/shared/downloads/ and the task scratch directory.
File contents are compared with observation history retained outside the execution environment. Records include the actual observation time, hostname, boot ID and uptime. The procedure preserves old contents before appending a new observation; later checks use fsync and full-content read-back verification.
The original policy skipped appending when an environment change was detected. This accounts for unchanged tails during the Oct 7 21:30–23:35 checks. From Oct 7 23:47:37 onward, a new observation was appended after preserving the old evidence, including on change-detection checks.
Missing files are not automatically recreated, and missing observation periods are not filled retrospectively. Checks that could not start, including Oct 7 20:29 and Oct 8 03:48, are not counted as environment changes or data losses. An unsuccessful manual reboot attempt on Sep 30 is also excluded.
Shared files have still not returned
At Oct 9 16:19:34, all three monitoring files passed append, fsync and read-back verification, each at 20,973 bytes.
At 17:36:43, both shared-path checks returned ENOENT. A separate path check confirmed that /workspace/shared itself was unavailable. Hostname and boot ID were unchanged, and uptime had increased. The scratch file continued to pass verification.
The observed transition from present to absent therefore falls within a 77-minute-9-second interval.
At Oct 10 06:30:25, /workspace/shared could again be opened, but its original monitoring file and downloads directory remained absent.
A targeted inventory at Oct 10 10:55:10 also found original tool/configuration paths, the local observation-journal copy and a previously confirmed quarantine directory unavailable. The independent journal in ChatGPT Library remained available. The quarantine directory’s disappearance is relevant; files deliberately moved into it earlier are not counted as new losses just because their original paths were empty.
At the latest check, Oct 11 09:47:08:
The broader tool/configuration inventory dates to Oct 10. Reinstalled tools and newly created files should not be treated as recovery of the original state.
Requested investigation and recovery support
Please correlate these observations with backend instance, mount, storage and lifecycle records, especially Oct 9 16:19:34–17:36:43.
An explicit checkpoint/persist tool would also help. After important operations, the user or agent should be able to request a checkpoint and receive its completion time, version identifier and persisted scope, with a clear status if saving is incomplete.
A separate network/proxy mismatch encountered during manual handoff is tracked in #53094: #53094
Given this situation, I am planning to reset my dot and will provide further updates depending on how things go afterward.
swqsldz commentedon Oct 2, 2026
Adding another observation from a dot’s cloud computer:
At approximately 00:46 UTC on October 2, 2026, /workspace/shared became inaccessible, while some processes still held open database handles. When the environment became available again around 01:26 UTC, the files were still missing from their original paths.
Matching files were later found under /workspace/.scratch-cleaning-*. Approximately 1.70 GB across 24,824 files was copied to a separate working directory and verified with per-file hashes.
The hostname and boot identifier remained stable during the later observation window. However, this does not establish whether the instance changed at the time of the original failure, and the cleanup trigger has not been identified.
Could the maintainers clarify the lifecycle of these cleanup directories, the supported persistence boundaries, and the recommended recovery procedure?
No source code, credentials, account identifiers, or exact machine identifiers are included in this report.
WaleyChAn commentedon Oct 2, 2026
Adding another observed case from my dot's Linux cloud computer. Recent saved source files disappeared, while older revisions and preview artifacts survived. I don't have a deterministic reproduction or know whether this has the same root cause as the reports above.
What happened
On October 1, 2026, roughly 18:14–19:14 UTC, work was interrupted and the execution environment showed
starting. After it became available again:.blendfiles and generator source from iterations V9–V21 were no longer accessible.The missing files included generator scripts and saved/frozen source copies, so this wasn't just an unsaved Blender session. A SHA-256 hash had been recorded for the complete V20 generator before the incident, but the corresponding file bytes haven't been recovered.
What we checked
Read-only recovery checks were run from both the cloud desktop's terminal and the code execution environment. Surviving project files matched by device, inode, size and SHA-256 across those surfaces. Their separate home/temp namespaces were also checked. No newer source archive, alternate accessible workspace/mount, or usable Blender autosave was found in the locations checked.
I also checked the recovery location mentioned in the previous comment: listing
/workspaceand searching it to depth 2 for.scratch-cleaning-*returned no matches and no errors from either surface.The repository only has an older tracked commit. The working model directories were untracked and weren't backed up to a remote, so Git can't restore these versions.
Later diagnostics, with limits
An October 2 check showed about 9.7 GiB visible RAM (8.4 GiB available), a 32 GiB disk with about 29 GiB free, and a current
oom_killcounter of 0. The current kernel boot time is October 2 at 04:54:50 UTC, after the incident. These readings can't establish resource use or rule out OOM at the time files disappeared. The relevant cgroup data wasn't exposed,dmesgaccess was denied, and no usable journal was available.Current overlay mount diagnostics include
fsync=volatile. I don't know whether the incident environment had the same configuration or whether this has any bearing on the failure.Questions for maintainers
The cloud computer documentation says the computer can keep its state between periods of use. Could you clarify:
The practical blocker is that I can't continue from the latest saved source. I can't tell from the accessible filesystem whether the missing data is permanently lost. Session/environment identifiers and private diagnostics can be provided through an official private support channel.
raulblanko commentedon Oct 2, 2026
Adding an independent report of repeated filesystem unavailability on a dot's own Linux cloud computer. This is the third observed incident in my account: two on September 30, 2026, and another on October 2. The affected environment is the general dot cloud computer, rather than a separately created, repository-backed Codex Cloud task.
New observations, all UTC on October 2, 2026:
The task that observed this incident did not delete files or remount storage. The trigger and exact time of the transition are unknown.
Recovery update
Following the useful lead in #49682 (comment), later read-only checks found files from the previously unavailable shared directory under /workspace/.scratch-cleaning-* in this affected environment. These include configuration files and project release files with metadata consistent with the expected files.
Integrity verification and recovery are still in progress. The directory discovery does not establish that every file or the latest version of every file has survived, and normal operation has not yet been confirmed restored. It does establish that at least some files remained available at another location, so this report should not be read as confirmed permanent deletion.
The checks do not establish why the original shared path disappeared, what created or moved content into this cleanup directory, or whether the earlier incidents had the same cause.
Impact
Tools installed under the shared directory and newer working files became inaccessible at their expected paths, blocking ongoing work and requiring recovery and setup. This affects saved files and installed tools, not only a running process. Some files elsewhere survived, and some of the unavailable shared content has now been located as described above.
Expected behavior and requested investigation
The cloud-computer documentation says the computer can keep state between periods of use: https://learn.chatgpt.com/docs/dots/computers-and-apps
Please investigate this recurrence alongside the reports above and clarify:
This incident was also appended to my existing private support conversation. The support interface confirmed escalation to a specialist at 18:03 UTC on October 2. A human response, engineering investigation, platform-side log preservation, and complete recovery have not yet been confirmed.
This public report intentionally omits account and environment identifiers, machine identifiers, private project names and paths, credentials, configuration contents, and private logs. There is no deterministic reproduction yet, and I am not asserting that all reports in this issue share the same cause.
DDDFXYqiming commentedon Oct 2, 2026
I hit another case on October 2, 2026, at around 21:21 UTC, while my dot was actively developing a game on its Linux cloud computer. Work had been continuing without an idle period.
The current project and recent artifacts disappeared. We checked again and could only find older files from October 1. Reported disk usage dropped from about 28 GB to 91 MB.
We recovered the last published checkpoint from GitHub and artifacts saved to ChatGPT Library. Some newer source had to be reconstructed and checked against hashes recorded before the loss. The raw test logs were not recovered, so we have been rerunning those tests.
We did not capture the old and new container identifiers. I can't tell whether this was a rollback, a different environment being attached, or another storage failure. The part I can confirm is that recent saved work became unavailable during active development, while older files remained.
Could maintainers check this time window and clarify when cloud-workspace writes become durable? Is there a supported way to recover a more recent snapshot after this happens?
WaleyChAn commentedon Oct 3, 2026
Quick follow-up to my earlier report: I've now observed at least two intervals where the available workspace state regressed. This is a count of observed state regressions; I don't know how many environment restarts or replacements occurred.
All times below are UTC, in 2026.
masterbranches were verified at the same newer commit (aab5540), with a clean local working tree. Local HEAD was still at that commit at 17:57. By 05:12 on October 3, local HEAD was back at the olderef64adacommit, while the remote still retainedaab5540.The second case is recoverable from GitHub, so I'm not reporting permanent source loss for that interval. It does show that the local checkout was presenting older state after newer state had been verified.
There's also a local CLI configuration symptom, with an important timing limit: the GitHub CLI was already unauthenticated at 14:24 on October 2, before the second interval. At 05:23 on October 3, its previously used local configuration directory was absent, and the default CLI had no authentication. The successful repository operations on October 2 used the separate GitHub connector, not that CLI. I therefore can't say that CLI authentication disappeared during this second interval. Reauthorization works now; token expiry or revocation has not been established. The absent local configuration could be related to the persistence problem, but I don't have evidence of a shared cause.
Could the team investigate this recurrence and clarify when working-directory writes and saved configuration become durably checkpointed, which lifecycle transitions can restore older state, and what supported recovery options exist for a newer workspace snapshot? The first incident's missing editable models/source are still the unresolved recovery concern.
harryshawk commentedon Oct 3, 2026
Additional authorized DOT file-persistence evidence, reported October 3, 2026. The following is the DOT's own RCA analysis:
Please include this evidence in the persistence/recovery investigation. The confirmed preservation gap does not establish why the directory disappeared, permanent deletion, or a shared cause with other incidents. No study contents or participant data are included.
6 remaining items
kcrazy commentedon Oct 4, 2026
Adding a new observation from October 4, 2026, around 08:22–08:30 UTC.
Several running command sessions on my dot’s cloud computer could no longer be resumed. The tool reported:
executor key changed during session recoveryPreviously accessible temporary files were also no longer visible. Shared files remained accessible, and some other sessions continued working. No reboot was requested.
The cause is unknown. This may involve an execution-environment change, but the evidence does not establish a full computer reset or permanent file deletion.
Please investigate this time window and clarify how running command sessions and temporary files are handled during environment changes. I do not know whether this shares a cause with the earlier reports.
dean1012 commentedon Oct 4, 2026
Further recurrence following the initial observation and previous recurrence.
Filesystem observations on dot's cloud computer:
These were discrete checks of the cloud desktop itself, not continuous monitoring. There is no tightly bounded last-good/first-bad interval. The separate cross-surface HOME-visibility mismatch in #50012 does not explain this same-surface disappearance.
Browser observations:
The cookie viewer's displayed list does not establish the cloud browser's live cookie values. The observations do not establish whether state was lost, incompletely restored, or invalidated by websites, or whether the filesystem and session symptoms share a cause. IP causation and a scheduled reset remain unconfirmed.
Repeated manual reauthentication interrupts authorized unattended tasks. Please clarify:
dean1012 commentedon Oct 4, 2026
Addendum to the latest observation: possible explanations for investigation, not confirmed root causes. No backend visibility or network capture distinguishes them.
More than one mechanism could be involved. Session invalidation alone would not explain missing files. Please distinguish lifecycle replacement, filesystem/profile restoration, and website-side session invalidation.
brianpetro commentedon Oct 4, 2026
Unfortunately this (bug?) is making "dot" unusable.
The cloud computer cleared overnight. Ok.
So then I set up the environment again today. Within an hour everything was gone again.
The dot was also open/running that entire time.
oneezy commentedon Oct 4, 2026
Dot’s Computer Test
I cloned development repositories into
/workspace/shared/dev. Later that day, the checkouts were unavailable. I found this issue while investigating. To check what persists, we placed marker files in six locations, updated the existing pnpm command, and installed Vite+.✅ Stayed
❌ Missing
/home/agent/Desktop/test-1/test-1.mdtest 1/home/agent/test-2/test-2.mdtest 2/workspace/test-3/test-3.mdtest 3/workspace/shared/test-4/test-4.mdtest 4/workspace/scratch/a85f59bdaeee/test-5/test-5.mdtest 5/tmp/test-6/test-6.mdtest 6/home/agent/.local/bin/pnpm11.19.0, then12.9.111.19.0fallback; launcher missing/workspace/shared/tooling/pnpm/bin/pnpm12.9.1binary12.9.1, same hash/home/agent/.local/bin/vp1.0.0/workspace/shared/tooling/vite-plus/bin/vp1.0.0binary1.0.0, same hashThe bundled pnpm stayed at
11.19.0. We activated12.9.1for the cloud user through home launchers backed by shared program files. The/tmpmarker was a temporary-storage control.Folder and file timeline
All times are CDT, 2026.
October 3, 6:45 PM
October 3, 6:51 PM
October 3, 8:00 PM
October 3, 9:38 PM
App timeline
October 4, 5:03 AM
pnpmandvpcommands returned12.9.1and1.0.0in fresh shells.October 4, 5:09 AM
October 4, 11:26 AM
All 7 home launchers were missing. Normal
pnpmused the11.19.0fallback;vpwas not found.This check was about 6 hours 23 minutes after activation.
The final check found the same marker results. Both shared programs still ran, and all 10 sampled installation hashes matched. Runtime identity changed. The exact loss time and provider trigger are unknown. We performed no repair or recreation before the final check.
What I need
I want a reliable, persistent development computer with full control over normal software installs and updates. What is the intended storage and permissions model, and is there a supported way to get admin access?
keshuoxiao-cmd commentedon Oct 6, 2026
Adding another affected-user report with a recurrence after a verified rebuild. This concerns a dot's own cloud computer. Private file names, account details, credentials, and environment identifiers are intentionally omitted.
All local times below are Beijing Time (UTC+8), in 2026; UTC equivalents are included for engineering correlation.
Verified rebuild, then recurrence
The missing-state observation was consistent between the command-line environment and the cloud computer's graphical file manager. At the latest check,
/workspace/sharedcontained only the basic directories plusdownloads; the rebuilt material and tooling were not present at their expected locations.I also checked for the recovery location reported by some users in this thread. No
/workspace/.scratch-cleaning-*candidate was found in the accessible environment.This is important because the affected state was not only old data from an earlier environment: it had been rebuilt, integrity-checked, observed intact again the following day, and then became unavailable again.
Other affected state
Other local state has also become unavailable across these incidents, including locally installed/configured tools and automation state. Browser authentication state has also been lost on the cloud computer at least once.
I am not claiming that the browser-session loss and filesystem loss necessarily have the same root cause; I only mention the correlation because both are persistence/lifecycle symptoms worth checking.
There was no known user-initiated deletion, reset, or intentional cleanup corresponding to this recurrence. From the user-visible environment I cannot distinguish permanent deletion, rollback to an older snapshot, attachment to a different environment, failed restore, or another storage/lifecycle event.
Requested investigation
Could the team please check the platform-side records for the above windows and clarify:
External copies of some source material remain available, but not all local indexes, synchronization state, automation/runtime state, or browser sessions had equivalent independent backups. I therefore cannot infer from external backups whether the missing cloud-computer state itself is recoverable.
s520145 commentedon Oct 7, 2026
I encountered a similar issue on October 6, 2026, at approximately 19:43 UTC.
Two project directories under /workspace/shared on my dot’s cloud computer became unavailable during active development. Both the execution shell and the cloud desktop Terminal confirmed the directories were missing. Reported usage on the 32 GiB filesystem dropped from roughly 28 GiB to 330 MiB.
The affected files include a local Git test branch with unpushed commits, original test logs, and the latest issue/remediation spreadsheet. An earlier spreadsheet export in Library and another project’s pushed source could be recovered, but the remaining local work is still unavailable.
I checked the accessible workspace and common temporary locations, including the .scratch-cleaning recovery location mentioned in this thread, but found no usable copy of the missing projects.
I don’t have a reliable reproduction or enough information to determine whether this was a filesystem reset, rollback, or attachment to a different environment. The files remain unavailable as of October 7.
Is there a supported way to recover the previous filesystem or check whether a snapshot still exists? I can provide account and environment details privately if needed.
Jiacheng-Liu commentedon Oct 8, 2026
On October 8, 2026, around 03:32 UTC, a long-running dot cloud research workspace restarted/reopened. Recent outputs reported complete before the restart were no longer available in the accessible workspace, while older project files remained.
Missing recent versions include generated datasets, figures/reports and analysis packages. Some earlier code and retained authoring text survived. Separately exported artifacts and original inputs also survived.
The older files appeared roughly two–three days old, but that is not a verified snapshot timestamp or a measure of how much code was lost. We cannot determine whether the missing files are permanently deleted or recoverable from a previous workspace volume/snapshot.
Could the team investigate workspace persistence and whether the previous state can be recovered without replacing the current reconstruction? A clear recovery path and warnings about unsaved-work durability would help.
Possibly related: #49869. Same cause is unconfirmed. Private diagnostic identifiers can be supplied securely if requested.
amanter-Zthen commentedon Oct 8, 2026
I am adding a concrete, timestamped report of repeated working-state unavailability on my dot's own cloud computer. This happened in an existing conversation, not a newly created cloud task. I would appreciate confirmation that this is the right place to investigate it, or a pointer to the responsible persistence/runtime team.
What was lost from the accessible environment
The original working project directory, its recovery/control files, an installed Lean 4.34.0 toolchain, and the local continuity journal became unavailable at their known paths. Externally archived results survived. Those backups allowed reconstruction, but did not preserve a ready-to-use working environment.
Earlier support-record history, not independently revalidated from its original raw logs for this public report: on October 7, the interface was recorded offline around 13:42 and online around 13:43; project-root ENOENT checks were recorded at 13:43:43–13:43:50, followed by Lean-path ENOENT checks around 13:51. These earlier records do not by themselves identify the underlying lifecycle or storage cause. After that interruption, the project and the selected Lean/mathlib installation had been restored by approximately 15:07 UTC. The support supplement records successful core positive/negative controls and a selected 2,069-module compiled closure. That installation was more than a downloaded installer. The later disappearance was captured by narrow file checks described below.
Most tightly bounded observed recurrence
All times are UTC (Beijing is UTC+8).
starting; an available environment context followed at 21:05:08. No manual restart/reboot or environment-start/wait operation was issued during that transition, according to the recorded observation. The actual trigger is unknown.[Errno 2] No such file or directory; the original local journal was also unavailable.This brackets the observed presence-to-absence transition to 81 minutes 59.539 seconds. The
startingnotice is not a proven reset time. ENOENT establishes named-path unavailability in the exposed filesystem; it does not identify the cause, prove physical deletion, or prove that the same underlying instance or mount survived.For reproducibility, the original four file commitments were:
/workspace/scratch/<redacted>/monitor-original/ANCHOR.json89decae012b8232732aab722c9406c848dc6fe2af4f2dfe7e4daddc67cb9ec42/workspace/scratch/<redacted>/project/CURRENT_RECOVERY.json3c322b3757dbd472b5844c98755ebb3de4f61498b77d4daf21601584629e9f19/workspace/scratch/<redacted>/toolchain/recovery-R2/CURRENT_RECOVERY_READY.jsonc716374fd0ce4fa233b60c6e44c748c8f8fc82e77d9cdcb9f133928af34ec4ba/workspace/scratch/<redacted>/toolchain/vendor/lean-4.34.0-linux/bin/leane8baaa71855a616dc351028f3ad2200051b0671f423a1696a100e809302d5550Recovery and practical impact
On October 8 at 00:24:48.960362, the exact project root was again confirmed unavailable, blocking the next authorized calculation. A narrowly authorized reconstruction from external archives was verified at 00:34:47: 129 archived payloads totaling 7,803,145 bytes, restored at the same project path. This was explicitly marked as a reconstructed instance. Lean and the old monitoring journal were not restored.
Further archived control dependencies had to be retrieved and revalidated. Our own static dependency check missed one dependency branch, causing an admission failure before scientific execution; I am not attributing that checking error to OpenAI. Work actually started at approximately 01:14:49, roughly 51 minutes after the new request arrived. That is elapsed workflow delay including restoration, checking and coordination, not measured CPU time or quota consumption, and not an amount wholly attributable to the platform.
There was also a separate 09:40 failure:
exec-server transport disconnected, before a process could be created. A targeted read-only check at 09:41:40.195981 succeeded and found the reconstructed project marker readable, with the already-missing Lean/old-monitor paths still unavailable. I am preserving this as a transient access failure, not counting it as a new data-loss incident.How the evidence is being made more precise
I now retain both an external versioned observation journal and a separately authorized new local monitoring journal. Checks record the actual execution time, separately from scheduled time; file existence, byte counts and hashes; lifecycle notices when visible; exact failures; and authorized reconstruction boundaries. The local log is hash-chained with exclusive locking, deduplication and flush/fsync/read-back. The external update uses a version guard. These two writes are not atomic, so their success is tracked separately.
Checks are deliberately limited to small known paths and project metadata, without running scientific work or scanning the whole filesystem. Missing observations stay unknown. A successful check after waking does not establish uninterrupted uptime, and periodic writes are not assumed to keep the environment alive.
The latest preserved snapshot contains 101 observations, through October 8, 12:51:06 UTC. The latest full check at 12:41:55 still found the reconstructed project/new monitor markers readable and the known Lean paths unavailable. There has been no new observed presence-to-absence transition since this new monitoring setup, so I am not claiming a newly narrowed reset interval yet. Future bounds will come from the last actual successful check and first actual failing check, rather than from a guessed restart time.
The private original journal snapshot is 501,093 bytes, SHA-256
4d25fd02e3839457a875429944f8e3f97341769edebac72b681ef1ac2eaf32b0. Public evidence excerpts are privacy-redacted transcriptions with stable path aliases; this hash commits to the original bytes but does not by itself make the private source independently verifiable. Private research source, account identifiers, credentials and signed URLs are excluded.Investigation requested
Please correlate the October 7 19:44–21:07 UTC interval with backend instance, mount, storage and lifecycle records, and clarify:
I have already submitted the recurrence and recovery-impact details through the existing Help conversation. I do not yet have a confirmed new case number for this recurrence; that is not proof that no internal ticket exists. The original cause remains unknown, and I am asking for investigation rather than asserting deliberate deletion.
leftbankvines commentedon Oct 8, 2026
Adding another occurrence on October 8, 2026, involving a dot’s general cloud computer opened from its profile, not a separate Codex Cloud coding task.
On October 7, my dot created two project folders under /workspace/shared/projects, wrote and updated documents, and committed them to local Git repositories. I inspected the files myself in the cloud computer interface. The final work was verified around 00:17–00:20 UTC on October 8.
Later that morning, the entire projects folder was absent in both the interface and filesystem checks. I did not request a reset, reboot, or deletion.
The investigation found:
This resembles the newer-state loss with older-state survival reported here. An older saved state being restored is a plausible explanation, but we cannot establish the cause without platform-side records.
We recovered fourteen documents from recorded authoring text and edits, plus an original attachment from Library. Several recovered Git blob prefixes match earlier recorded diffs. The original repositories and Git history remain unavailable.
I have escalated this to Support.
jstrick79 commentedon Oct 9, 2026
I am experiencing the same issues, I too have my dot creating backups to my library/space. All work is paused until this issue is resolved.
List of events of the past day:
Event 1
Verified observation UTC: 2026-10-09T04:07:45.542070Z
Verified observation Eastern: 2026-10-09 12:07:45 AM EDT
Kernel boot time UTC: 2026-10-09T03:53:23Z
Kernel boot time Eastern: 2026-10-08 11:53:23 PM EDT
Kernel boot ID: f2813485-666c-4c5f-9501-7155ee59cd04
Sampled kernel uptime seconds: 862.42
Previous relative checkpoint location absent: research_preservation_20261009
Fresh recovery root under the working directory: recovery_event_20261009T040607Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_3a293453c2548191a707c80c6f11790d
Available space bytes: 28608831488 (84.716%)
Available inodes: 2085628 (99.45%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 2
Verified observation UTC: 2026-10-09T05:21:26.923250Z
Verified observation Eastern: 2026-10-09 01:21:26 AM EDT
Kernel boot time UTC: 2026-10-09T05:15:06Z
Kernel boot time Eastern: 2026-10-09 01:15:06 AM EDT
Kernel boot ID: 4c594dde-2b77-44c5-96b9-434a5c7fe474
Sampled kernel uptime seconds: 380.29
Previous relative checkpoint location absent: recovery_event_20261009T040607Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T052027Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_3afda941ac088191b9e0219b66a3f870
Available space bytes: 28615675904 (84.736%)
Available inodes: 2085646 (99.451%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 3
Verified observation UTC: 2026-10-09T06:27:42.634498Z
Verified observation Eastern: 2026-10-09 02:27:42 AM EDT
Kernel boot time UTC: 2026-10-09T06:21:24Z
Kernel boot time Eastern: 2026-10-09 02:21:24 AM EDT
Kernel boot ID: 8d80e231-3dce-4367-ba61-9afc6adb3838
Sampled kernel uptime seconds: 378.6
Previous relative checkpoint location absent: recovery_event_20261009T052027Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T062639Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_8fa1073c1e5481919012f022ec86191b
Available space bytes: 28665163776 (84.883%)
Available inodes: 2085692 (99.454%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 4
Verified observation UTC: 2026-10-09T07:46:14.555776Z
Verified observation Eastern: 2026-10-09 03:46:14 AM EDT
Kernel boot time UTC: 2026-10-09T07:39:57Z
Kernel boot time Eastern: 2026-10-09 03:39:57 AM EDT
Kernel boot ID: 65468adb-fde5-45ca-99d6-977f7c2faa37
Sampled kernel uptime seconds: 376.97
Previous relative checkpoint location absent: recovery_event_20261009T062639Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T074509Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_6c5fc129370c8191b96570e9f2e5a0ae
Available space bytes: 28615684096 (84.737%)
Available inodes: 2085654 (99.452%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 5
Verified observation UTC: 2026-10-09T08:47:54.184661Z
Verified observation Eastern: 2026-10-09 04:47:54 AM EDT
Kernel boot time UTC: 2026-10-09T08:42:16Z
Kernel boot time Eastern: 2026-10-09 04:42:16 AM EDT
Kernel boot ID: 1383c838-1fda-477a-ac3a-22d0d227c28c
Sampled kernel uptime seconds: 337.65
Previous relative checkpoint location absent: recovery_event_20261009T074509Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T084650Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_e7bf9aaddbd881918c49fcb2feae315f
Available space bytes: 28615614464 (84.736%)
Available inodes: 2085647 (99.451%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 6
Verified observation UTC: 2026-10-09T10:12:55.838327Z
Verified observation Eastern: 2026-10-09 06:12:55 AM EDT
Kernel boot time UTC: 2026-10-09T10:05:26Z
Kernel boot time Eastern: 2026-10-09 06:05:26 AM EDT
Kernel boot ID: 6e550d00-a485-4a8e-86d2-a0814152acf8
Sampled kernel uptime seconds: 449.14
Previous relative checkpoint location absent: recovery_event_20261009T084650Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T101151Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_21ccfb144d4c8191b629293f4b6dc82f
Available space bytes: 28615585792 (84.736%)
Available inodes: 2085644 (99.451%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
Event 7
Verified observation UTC: 2026-10-09T12:10:34.409883Z
Verified observation Eastern: 2026-10-09 08:10:34 AM EDT
Kernel boot time UTC: 2026-10-09T12:04:38Z
Kernel boot time Eastern: 2026-10-09 08:04:38 AM EDT
Kernel boot ID: 8d97400f-0c04-4515-b9c2-127c61683e00
Sampled kernel uptime seconds: 355.98
Previous relative checkpoint location absent: recovery_event_20261009T101151Z/retrieved
Fresh recovery root under the working directory: recovery_event_20261009T120918Z
Downloaded files subdirectory: retrieved
Restored payload subdirectory: restored
Library evidence record version 0: libfile_0bd46210424c8191af143507bb440711
Available space bytes: 28611293184 (84.724%)
Available inodes: 2085644 (99.451%)
Result: seven packages restored; 842 payloads independently rehashed; no partial restore.
leftbankvines commentedon Oct 9, 2026
Following up on my October 8 report: the rebuilt working files became unavailable again on October 9, 2026. All times below are UTC.
We have preserved the current environment without restoring over the missing paths and updated our existing Support case. Could engineering investigate the recurrence and clarify the supported persistence scope and lifecycle of the dot’s general cloud computer? Backups protect the documents, but repeated disappearance of the working environment still interrupts ongoing work.
amanter-Zthen commentedon Oct 10, 2026
Following up on my earlier report here: a restored Lean executable became unavailable again on October 10, 2026. All times below are UTC and refer to actual checks, not backend lifecycle-event timestamps.
Please investigate backend workspace lifecycle, instance association, mount and persistent-storage events in the 11:50:59–12:02:15 UTC interval, and clarify the supported persistence and recovery behavior for the dot's own cloud computer. The cause remains UNKNOWN. Successful backup retrieval protects those archived results but does not resolve recurring loss of the usable working environment.
Jiacheng-Liu commentedon Oct 10, 2026
Another occurrence on October 10, 2026: recent working files became unavailable in my dot cloud workspace, while older project files remained.
Timeline, in UTC:
We restored some files from one partially uploaded checkpoint, with matching hashes. Some additional files were subsequently recovered or reconstructed. A newer report and HTML reader had not yet been exported, and their original files were not found in the available workspace or backups, so they had to be rebuilt. Some recent code and annotation work also required reconstruction.
The preview-limit interruption preceded the discovery, but we have not established that it caused the missing files. We also cannot tell whether the earlier filesystem state still exists server-side. This is not a claim of confirmed permanent deletion.
Could the team investigate:
The practical impact is repeated reconstruction and uncertainty about which working files survive. Private diagnostic identifiers and timestamped file/hash manifests can be provided through an appropriate support channel.
WaleyChAn commentedon Oct 15, 2026
This happened again today. I’d been working with my dot on a project for nearly two days. Now the recent project files are missing from its cloud workspace, and even the GitHub CLI login is gone. An older GitHub backup and some preview images survived, but I still don’t know if the recent work can be recovered.
I really want dots to get better, and I’ve reported this before, but I haven’t received a meaningful response. It’s hard to trust it with longer projects when the work can become inaccessible like this.
Could someone from the team please acknowledge this and help us understand what happened, whether recovery is possible, and how to avoid it happening again?