agent hallucinated a binding name not in wrangler.toml, deploy validation failed

TL;DR

The agent wrote code against a binding name it imagined (or remembered from another project), and wrangler's validation rejected the deploy because the config defines no such binding. The fix is a closed loop: the agent reads the binding list from wrangler.toml, writes code using exactly those names, and a pre-deploy check diffs code references against config.

The query

agent hallucinated a binding name not in wrangler.toml, deploy validation failed

Use this when

• Deploy validation fails naming an unknown binding.
• The code references a binding absent from wrangler.toml.
• The name looks plausible but belongs to another project.

Not for

• Bindings defined in config but failing at runtime (config value problem).
• 'binding is not defined' at runtime with correct config (code path problem).
• Validation passing but the binding pointing at the wrong resource (value problem).

Steps

Step 1: List the bindings the config actually defines

Read every binding section in wrangler.toml: kvnamespaces, r2buckets, d1databases, durableobjects, queues, vars, and secrets.

Expected result: the authoritative name list. Everything the code may reference is on it; everything else is forbidden.

Step 2: Diff code references against the list

Search the code for env dot something accesses and compare each against the config list.

Expected result: the hallucinated names stand out. They are the only references with no config entry.

Step 3: Fix the code to use real bindings

Replace hallucinated names with the actual binding names, or add the genuinely-needed binding to wrangler.toml (creating the underlying resource first).

Expected result: every env access resolves to a defined binding. The choice between 'fix code' and 'add binding' is deliberate per case.

Step 4: Add a pre-deploy binding check

Before deploy, the agent extracts env accesses from the code and verifies each exists in wrangler.toml. Fail the run on mismatch, before wrangler does.

Expected result: hallucinations are caught in seconds locally instead of as deploy rejections.

Step 5: Redeploy

Expected result: validation passes. The worker runs with real bindings.

Why it happens

Binding names are project-specific strings with no type checking across the code/config boundary. Agents autocomplete from training data (other projects' binding names) rather than from the project's config. Validation catches it at deploy, but the feedback loop is slow and the agent may 'fix' it by renaming the wrong side.

Edge cases

• Vars and secrets share the env namespace with bindings. The check must cover all of them.
• Preview vs production bindings can differ (preview_id). The check should validate the target environment's set.
• Dynamically constructed binding names (env[name]) defeat static checks. Forbid the pattern or require an allowlist.
• A binding can be defined in wrangler.toml but point at a deleted resource. That passes validation and fails at runtime; check resource existence too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VsewcnFpz8KGlJLDeSZfAw