[Dot][Cloud computer] Computer unavailable, native connection refused and browser Target closed #50130

Summary

My dot's cloud computer suddenly became inaccessible. The computer panel shows a blue screen with “컴퓨터를 사용할 수 없음” (“Computer unavailable”). I can still message the dot, but cannot access its cloud desktop.

Environment

• Product: ChatGPT dot / dot's cloud computer
• Client: ChatGPT desktop app on Windows (corrected after confirming the actual client with the reporter)
• Plan: ChatGPT Pro
• First observed during this session: October 2, 2026, approximately 09:17 KST (00:17 UTC)
• Exact Windows and ChatGPT desktop-app versions: not recorded

Observed behavior

1. The cloud desktop had been accessible earlier in the same session.
2. The panel then changed to “Computer unavailable”.
3. Later, loading briefly displayed the desktop, then it became unavailable again.
4. Native computer-control calls returned: failed to connect native pipe: Connection refused (os error 111).
5. Browser discovery returned: Protocol error (Target.setDiscoverTargets): Target closed.
6. Resetting the control-tool session and attempting fresh state discovery did not restore access. This was NOT a reboot of the cloud computer.
7. No usable cloud-computer restart control was available in the observed interface or exposed tools.

Impact

This blocks a time-sensitive workflow that needs the existing cloud desktop and applications. The current status of applications that had been running cannot be verified through the unavailable desktop. This report does not claim that all background tasks have stopped or that files are lost.

Expected behavior

The existing cloud computer should remain accessible, or the interface should explain why it is unavailable and provide a supported recovery path that preserves existing files and work.

Additional context

The OpenAI status page showed fully operational when checked at approximately 09:42 KST on October 2. I understand aggregate status does not rule out an individual environment problem.

Potentially related, but different symptoms: #49802 (macOS takeover controls) and #49869 (read-only cloud workspace). I do not know whether these share a cause.

Please investigate cloud-computer availability and advise how to recover the existing environment safely. A screenshot of the unavailable panel is available. Account identifiers, private conversation/task identifiers, project details, credentials, and raw logs are intentionally omitted from this public report.