Windows desktop Sites: deploying a saved source-only version repeatedly fails to fetch saved source

Summary

Publishing an existing owner-private Site from the Windows desktop app through the native Sites connector repeatedly fails with:

We couldn't fetch the saved Site source. Retry publishing the Site.

The source-only version was successfully saved and can be retrieved. The previous successfully deployed version was also source-only. This is not an unsaved candidate left by a failed archive upload.

Environment

• Windows desktop app, local project, native Sites connector.
• Exact desktop app/bundled Codex version: not yet verified (no CLI version is being substituted).
• Observed on September 16–17, 2026, Pacific/Auckland; failure timestamps recorded in UTC.

Steps to reproduce

1. Build and test the existing local project.
2. Push the exact source commit to the Sites-provided source repository.
3. Successfully save the source-only version using save_site_version.
4. Deploy that saved version using deploy_private_site_version.
5. Poll get_deployment_status until terminal.

Expected

The saved source can be fetched and deployed, or an actionable diagnostic explains why it cannot be fetched. Owner-private access should remain unchanged.

Actual

Multiple independent deployment attempts return a deployment ID, enter building, then end in failed with the source-fetch message above. Another attempt returned:

Cloudflare Sandbox Worker request failed: status=500 body=Error proxying request to container: Container port connection closed unexpectedly.

A separate full-build archive upload path also failed twice after roughly 60 seconds (archive approximately 222 MB). This may be a separate issue.

Checks already performed

• Local build and TypeScript checks passed.
• 10 main-project tests and 4 related notification-relay tests passed.
• .openai/hosting.json is present and points to the intended project.
• Fresh source credentials plus git ls-remote confirmed the remote branch HEAD exactly matches the saved source commit.
• get_site_version confirmed the saved version; archive_storage is null.
• Repeated private deployment attempts have not resolved the failure.
• Local Git history has 82 commits and approximately 1.20 GiB of packed objects; this is a possible factor, not a confirmed cause. The previous successful source revision had 80 commits. No history rewriting was attempted.

Support and privacy

A desktop feedback report was successfully submitted, and a detailed report with project/version/deployment IDs and UTC timestamps was provided in the authenticated OpenAI Help Center conversation. That AI support conversation recommended this issue route but did not confirm human escalation.

This public report intentionally omits the private Site URL, project and deployment identifiers, feedback/session identifier, credentials, and conversation logs. Please advise on a private channel to correlate the existing feedback report and inspect server-side source-fetch/build diagnostics. If this repository is not the correct owner for the Sites connector/backend, please identify the appropriate reporting channel. No change to Site access or removal of course assets is requested.

Start by reviewing .openai/hosting.json and the save_site_version, deploy_private_site_version, and get_deployment_status entry points, then reproduce the saved source-only deployment using the documented steps. Use the existing project and deployment IDs to determine whether source fetching or the separate archive path fails; done means a confirmed root cause with an actionable diagnostic or a successful private deployment.