Workers Builds 'fix Worker name' PR ignores documented exemptions (custom deploy command, environments naming, --experimental-autoconfig=false)

[ElijahLynn]

What is the problem?

Workers Builds' automatic "fix Worker name" PR bot (cloudflare-workers-and-pages[bot], changelog) repeatedly opens a PR retitling the top-level wrangler.jsonc/wrangler.toml name field to match the connected (anchor) Worker — even when that mismatch is intentional (e.g. one repo with a top-level config for a Worker deployed only via a separate, disconnected deploy path, and an env.* block for the Worker Workers Builds actually deploys).

We tested every documented and CLI-level mitigation we could find, and none of them stop the PR:

1. Custom deploy command — the docs state a config PR "is only generated when your deploy command is npx wrangler deploy." We use pnpm exec wrangler deploy -c dist/server/wrangler.json (functionally equivalent, but not that literal string) — a PR was still opened.
2. <name>-<env> Wrangler-environments naming — docs document an exception where a dashboard Worker my-worker-staging can deploy from config name = my-worker + [env.staging]. We renamed our top-level config to match this shape exactly (top-level please-corp + env.dev → dashboard Worker please-corp-dev) — a PR was still opened.
3. --experimental-autoconfig=false — wrangler deploy --help shows this flag defaults to true in wrangler 4.100.0. We appended it to the deploy command — a PR was still opened.

Across all three tests, PR creation consistently landed ~71–75 seconds into every ~3–4 minute build, well before the deploy step runs. This strongly suggests the name-fix generator is a server-side check that runs early in the build pipeline (post-clone, pre-deploy) — meaning none of the wrangler CLI flags or deploy-command shapes documented as exemptions can actually reach it.

Full evidence and timestamps: #11667 (comment)

What is the expected behavior?

Either:

• The documented exemptions (custom deploy command, environments naming) should actually suppress the PR, as the docs state, or
• There should be an explicit account/Worker-level toggle to disable this specific PR-bot behavior, independent of autoconfig and independent of branch-build settings.

How can we reproduce it?

1. Connect a Worker foo-dev to a repo via Workers Builds, with the git connection anchored to foo-dev.
2. In the repo's Wrangler config, set the top-level name to something that does NOT match foo-dev (e.g. because a separate, disconnected Worker foo-prod uses that top-level name for its own deploy path), while an env.dev block sets name: "foo-dev".
3. Push to the watched branch. Observe the bot opens a PR renaming the top-level name to foo-dev.
4. Try any of: a custom (non-npx wrangler deploy) deploy command, restructuring the config to the <name>-<env> exception shape, or --experimental-autoconfig=false. Push again. The PR still gets opened.

Workaround

We ended up blocking the bot's branch (update_worker_name_to_*) from being created at all via a GitHub repository ruleset (requires a paid GitHub plan for private repos), and additionally auto-close any PR that does get through via a scoped GitHub Action. Neither of these should be necessary — an account-level toggle would be much simpler.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #14748

Summary

Workers Builds' automatic "fix Worker name" PR bot (cloudflare-workers-and-pages[bot]) keeps opening PRs to rename the top-level config name even when the mismatch is intentional, and none of the documented mitigations (custom deploy command, <name>-<env> naming, --experimental-autoconfig=false) stop it.

Classification

• Type: Bug
• Component: Workers Builds (server-side CI/CD; may be internal — not the Wrangler CLI in this repo)
• Severity: Medium
• Has Reproduction: Partial (detailed steps and three tested mitigations described; no clonable repro repo)
• Quality: Complete

Findings

• Created: 2026-07-17
• Author: ElijahLynn
• Version: wrangler 4.100.0 (mentioned in body)
• Labels: none
• Comments: 0

Analysis

• The reporter provides a high-quality, well-researched bug report: they cite the relevant changelog/docs, list three distinct documented and CLI-level mitigations they tested, and note each one failed.
• The reporter's own timing analysis (PR creation lands ~71–75s into every ~3–4 minute build, well before the deploy step runs) strongly suggests the name-fix PR generator is a server-side check in Workers Builds, not behavior in the Wrangler CLI shipped from this repo. The --experimental-autoconfig=false wrangler flag having no effect reinforces this.
• Because the offending logic appears to run server-side in Workers Builds, a code fix likely does not live in workers-sdk. Workers Builds is largely internal/not part of this open-source repo, so this may need routing to the Workers Builds team rather than being actionable here.
• The issue is brand new (created today, no comments, no labels), so it has not yet been triaged by a maintainer. It is not stale, not spam, not a duplicate (no references), and not user error — the reporter followed documented guidance that did not work.
• Note: the pre-fetched context.json body was truncated mid-sentence by tooling constraints, so the final portion of the report (likely additional detail / an explicit ask) could not be read. Recommendation is based on the substantial content that was available.

Recommendation

Status: KEEP OPEN

Reasoning: This is a legitimate, well-documented bug where the documented mitigations for the Workers Builds name-fix PR bot do not work. The behavior appears to originate server-side in Workers Builds rather than in the Wrangler CLI, so the fix likely lives outside this repo, but the report is valuable and should not be closed.

Action: Route to the Workers Builds team for investigation (the name-fix PR generator appears to be a server-side check that ignores --experimental-autoconfig=false and the documented <name>-<env> exception). Confirm whether documented mitigations are expected to work; if the logic is not in workers-sdk, transfer or cross-file with the Workers Builds team. Ask the reporter for their build/account identifiers if needed to reproduce server-side.

Suggested Labels: workers-builds

Suggested Comment

Thanks for the detailed writeup — the timing analysis and the three mitigations you tried are really helpful. The "fix Worker name" PR is generated by Workers Builds, and from what you're describing (the PR being created ~71–75s in, before the deploy step, and --experimental-autoconfig=false having no effect) this does look like a server-side check rather than something in the Wrangler CLI. I'm going to route this to the Workers Builds team to investigate why the documented mitigations (custom deploy command and the <name>-<env> environments exception) aren't preventing the PR in your setup. In the meantime, could you share the affected Worker/build so we can reproduce on our side?

Structured summary (JSON)

{
  "issueNumber": 14748,
  "title": "Workers Builds \"fix Worker name\" PR bot repeatedly opens PRs and documented mitigations don't stop it",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/14748",
  "recommendation": "KEEP OPEN",
  "difficulty": "hard",
  "reasoning": "Well-documented bug where the name-fix PR bot ignores every documented and CLI-level mitigation; timing analysis indicates a server-side Workers Builds check rather than Wrangler CLI behavior, so the fix likely lives outside this repo.",
  "suggestedAction": "Route to the Workers Builds team to investigate why the documented mitigations and --experimental-autoconfig=false don't stop the server-side name-fix PR; request the affected Worker/build to reproduce.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["workers-builds"]
}