[Dots / Cloud tasks] All-day recurring disconnects disrupt development from morning into next day; investigation and compensation review requested #54024

Customer impact and request for compensation review (updated 2026-10-14 16:12 UTC / October 15 01:12 KST)

I am explicitly requesting a substantive investigation, a reliable recovery path, and a fair compensation review for the prolonged disruption.

From the morning of October 14 through the early hours of October 15, 2026 (Korea Standard Time), I have been unable to carry my intended development workflow forward reliably to completion. This is my report of the experienced impact, not a claim that every individual command failed throughout the entire period. The repeated interruptions, stalled asset transfers, uncertain execution states, and need to repeatedly check and restart work have consumed the working day and extended into the next morning.

The problem is the repeated loss of a dependable working environment itself. Occasional successful commits or isolated tests do not resolve that problem or make the interrupted end-to-end workflow complete. I should not have to spend an entire day repeatedly asking whether delegated tasks are really executing, manually relaying files or instructions, or separating a misleading running indicator from actual progress.

Expanded chronology and evidence

The following earlier entries are timestamped conversation/work reports retained during the day, rather than newly recovered raw server logs. Times are UTC, with KST in parentheses. The recent notification/read sequence is preserved further below.

The earliest explicit cloud-disconnection report located here is 05:09:49 UTC. Recurrence through at least 16:04 UTC spans approximately 10 hours 54 minutes. This is a span of repeated incidents, NOT a measured continuous outage duration. The broader reported disruption runs from morning into the following early morning; the 00:37 browser/control issue and 03:18 asset-access issue document earlier operational problems.

Concrete workflow consequences

• Actual map-asset acquisition and integration were blocked for substantial periods, so synthetic/build checks could not substitute for actual rendering checks.
• The user had to repeatedly request status, supply task replies, relay instructions and compare local/archive access.
• Photo search metadata did not translate into the required usable downloaded image sets during repeated failed transfers.
• End-to-end completion was still outstanding at the time of this complaint: complete map language/font coverage, full subway integration including live API verification, and the required photo workflow were not all finished.
• There WERE partial code, data, and test results. Not every outstanding feature is proven to have been blocked solely by disconnections; data availability, authorization boundaries and coordination also affected individual steps. Nevertheless the repeated execution/connectivity failures independently prevented reliable sustained work.

Latest comparison test

A separate fresh-cloud diagnostic reported successful source reading, temporary-file writing, immediate rereading, and a second reread approximately 39 seconds later, starting at 16:09:47 UTC. It did not reproduce the failure in that short interval, so it does not prove a lasting fix. After that diagnostic completed, another environment-disconnected notification arrived around 16:11:43 UTC. This post-completion notification is recorded as such and must not be misrepresented as a failed diagnostic command.

Requested resolution and compensation

1. Investigate the affected managed execution and control paths using service-side logs. Explain the repeated disconnections, whether notifications are expected lifecycle events or abnormal failures, and why a task may remain marked running with no useful error while its environment is reported disconnected.
2. Provide a supported recovery procedure that preserves existing files and work, and explain how the user can verify actual recovery rather than mere request acceptance.
3. Review whether failed or stalled attempts consumed usage allowance or charges. Where they did, restore the affected allowance or credit it appropriately.
4. Review a proportionate subscription refund, service credit, or equivalent compensation for the prolonged period in which the intended service could not be used reliably. Please provide a written decision and the basis for it. I am not inventing a monetary loss or asserting an already approved refund amount.
5. Route this to the appropriate support/billing team if GitHub cannot process account-specific compensation. Please identify a private channel for any required account, task or request identifiers. I will not publish credentials, private source, signed download URLs, or billing details here.

I am asking for an evidence-based response and meaningful remediation, not another generic instruction to retry. Please acknowledge the duration and practical impact, including the repeated burden of recovery and the still-incomplete end-to-end work.

Observed problem

On 2026-10-14, repeated environment disconnection notifications affected separate delegated cloud coding tasks. This makes ongoing work unreliable and hard to supervise. Chat and connected-app task reads remained usable. The client used for the observations below was ChatGPT on Android; exact app and managed-executor versions were not exposed.

Recent observed timeline (UTC)

• Approximately 15:59–16:01: a map task emitted an environment-disconnected notification. A task read at 16:01:45 still reported inProgress, with error: null.
• At approximately 16:02: a follow-up to that task was admitted as steered; a separate subway task was admitted as started.
• By approximately 16:04:37: the subway task also emitted an environment-disconnected notification. At 16:04:45, its recorded turn still reported inProgress, error: null.
• At approximately 16:06:39: the subway turn emitted a completed notification. Its result, read at 16:07:50, reported a newly saved change and 12 offline checks. This is important: the disconnection event did not establish that all execution stopped or that files were lost. The new artifact has not yet been independently audited in this diagnostic pass.
• The parent environment also cycled through a starting context and returned to an available context around 16:06–16:07.

The exact disconnection onset times are approximate notification receipt times, not server log timestamps. Private task/environment identifiers and project contents are omitted.

Expected behavior

Stable executor connectivity, and clear distinction between: an actual stopped executor, temporary transport disconnect, task recovery, and a completed task. A running status or accepted follow-up should not be the only available signal when connectivity is failing repeatedly. Please provide a supported non-destructive recovery path and actionable diagnostics.

What is / is not established

• Repeated notifications across more than one cloud task are directly observed.
• Root cause, shared backend cause, and any relationship to earlier external download failures are NOT established.
• No data loss is claimed. No credentials, proxy/VPN/security settings, environment deletion, or production deployment were changed during this diagnosis.
• https://status.openai.com/ showed fully operational when checked around 16:07 UTC; aggregate status does not exclude an individual environment issue.
• At the initial filing, a separate minimal fresh-cloud read/write diagnostic was pending. Its later limited success and post-completion disconnection notification are documented in the update above; this is not evidence of lasting recovery.

Related reports

Possibly related symptoms, not a claim of identical root cause:

• [Dots] Cloud computer unusable: exec-server disconnected, capability query failed, no usable execution environment #52531
• Managed cloud executor handshake fails while runtime status reports running/connected; later recovers with files intact #51028
• [Dots] Cloud executor stops responding and cannot resume after file-transfer timeout #52509

Please investigate repeated executor disconnections and status/notification consistency, and advise what sanitized diagnostic information is needed through a private support channel.