Dot cloud workspace became read-only for hours; replacement workspace unavailable and newer unpublished work disappeared #49869

Summary

A Dot cloud workspace that had previously been writable became read-only during a long-running project. After that point, the Dot could no longer save changes, merge new work, or create a new writable cloud workspace. The read-only state persisted for roughly six hours of monitoring.

Previously published/exported artifacts remained available, but some newer unpublished working directories/source material were no longer visible after re-entering the Dot later.

This report intentionally avoids assigning a root cause. I do not know whether the behavior was caused by workspace lifecycle, permissions, service state, limits, recovery/rollback, or another mechanism.

Environment

• Product: ChatGPT Dots / Dot cloud workspace
• Client observed from: ChatGPT for Android
• Android 16
• ChatGPT 1.2026.265 / build 2626541 (previously reported build; exact installed build was not independently rechecked at every observation)
• Timezone: UTC+08:00
• Personal Pro account with Dots enabled

Timeline / observed behavior

Around 08:59 UTC+8

The Dot reported that the current cloud workspace had become read-only.

Observed effects:

• it could still inspect the existing project;
• write-recovery attempts did not succeed;
• it could not continue saving modifications or merge/publish new changes;
• there was no source-code error explaining the failure;
• already published versions and previously exported/offline copies remained available.

I then asked whether it could create a new workspace. It reported that it could check for an independent writable cloud environment, but a new writable workspace was not available.

Around 12:44 UTC+8

After several hours, the workspace was still read-only.

On re-entry, some unpublished working content/directories that had existed before were no longer visible. Examples mentioned by the Dot included newer river work, additional monument/scene work, and sky/subtitle-related source changes.

Already published/deployed versions and copies previously saved to the file library remained available.

Around 12:55 UTC+8

The Dot rechecked the workspace and still found it read-only.

It also reported:

• no second writable cloud environment was available;
• no direct user-facing control to restart/switch the Dot cloud computer was available;
• it could continue auditing existing artifacts, but not resume normal writing;
• if the missing unpublished source could not be recovered, that work would need to be reconstructed.

The failure was monitored for roughly six hours in total. Screenshots document at least about four continuous hours of the failure (08:59 through 12:55 UTC+8).

Expected behavior

A writable Dot cloud workspace should remain writable while an active project is being worked on, unless the product clearly explains that the environment has expired, reached a limit, or been intentionally closed.

If the environment can no longer accept writes, I would expect:

• a clear reason/status message;
• preservation of unpublished working files;
• a supported way to recover or recreate a writable workspace;
• a user-visible recovery/restart path if appropriate.

Actual behavior

• Existing writable workspace became read-only.
• Write attempts did not recover.
• Creating/connecting to a new writable Dot cloud workspace also failed.
• State remained read-only for hours.
• Some newer unpublished working directories/source material later became unavailable, while published/exported artifacts remained intact.
• No user-facing recovery/restart control was available.

Data-safety impact

This blocked continued development and created a risk of losing unexported/unpublished work. I had separate published/exported copies, so the entire project was not lost, but newer unexported source changes may need to be recreated if they cannot be recovered server-side.

I am deliberately not claiming confirmed permanent data loss, because I cannot see the platform’s internal snapshots/recovery state.

Reproduction limits

I do not have a clean deterministic reproduction from a fresh Dot/workspace. This is an observed failure from a long-running Dot cloud project.

I have screenshots and can provide session/task identifiers privately if an OpenAI engineer needs them. I am not posting private project/session identifiers publicly.

Additional note

This issue is separate from another Dot/Codex routing issue I reported privately. I am filing this as a standalone cloud-workspace reliability / persistence issue so the two behaviors are not conflated.