Sites deployment falsely reports nodejs_compat flag after it was removed

Open 💬 2 comments Opened Aug 4, 2026 by scrancj

Product surface

ChatGPT Sites deployment from the Codex desktop app.

Summary

A valid saved Sites version cannot be deployed because the publishing service reports that nodejs_compat is explicitly present and has become the default as of 2026-08-04. The packaged worker metadata does not contain that flag.

Steps to reproduce

  1. Build an existing vinext Sites project successfully.
  2. Remove compatibility_flags: ["nodejs_compat"] from the local Cloudflare configuration.
  3. Confirm the packaged dist/server/wrangler.json contains:
  • "compatibility_date":"2026-05-15"
  • "compatibility_flags":[]
  1. Save the Sites version successfully.
  2. Deploy the saved version to the existing public Site.

Actual result

Every deployment fails with:

The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore.

This still occurs even though the source configuration and packaged worker metadata both have the flag removed.

Expected result

The saved version should deploy when the packaged compatibility flag list is empty. If the platform now enables Node.js compatibility by default, the deployment pipeline should not re-add the obsolete explicit flag before validation.

Reproducibility

Repeated across multiple clean saved versions and deployment attempts.

Sites project: appgprj_6a6faaebb32481919588a648559cdc46
Saved version: appgprj_6a6faaebb32481919588a648559cdc46~appgver_18b4d31844408191a9420a115f7af7ae
Example failed deployments:

  • appgdep_6a712f3967208191911b2b93dfe9561a
  • appgdep_6a713f7dbdb48191a9a3b88424233c8b
  • appgdep_6a713fcda9808191bc8f11604b61142c

The existing live Site remains available; only the new saved version is blocked from publishing. No credentials, logs, customer source material, or secret environment values are included in this report.

View original on GitHub ↗

2 Comments

wmioch · 24 days ago

My codex is reporting the same issue - it cannot update the deployed sites at all

wmioch · 24 days ago

I reproduced this with a completely new, independent owner-only Site, not merely an update to my existing application.

The probe had no D1/R2 bindings or application-specific code. The current bundled Sites starter initially contained compatibility_flags: ["nodejs_compat"] and failed with the reported error. I then removed that flag, rebuilt, and confirmed the generated dist/server/wrangler.json contained:

"compatibility_date":"2026-05-15"
"compatibility_flags":[]

A newly saved version still failed with the identical error:

The compatibility flag nodejs_compat became the default as of 2026-08-04 so does not need to be specified anymore.

The probe generated no Worker error events, indicating failure before the Worker is deployed or invoked. It also had env_set_revision=0, ruling out environment variables and bindings.

Clean probe project: appgprj_6a71402836408191a22ef2567fa85def
Saved version: appgprj_6a71402836408191a22ef2567fa85def~appgver_4ec1119d6f28819185dd7f0facb26542
Failed deployment: appgdep_6a7141570d8c8191a459167a9719c75f

This suggests the publishing backend is reintroducing the flag after consuming the submitted archive. It affects both existing and newly created Sites and both public and owner-only deployment paths.