Minor Changes

• #15026 6529f0c Thanks @petebacondarwin! - Allow containers to be attached to a Durable Object from its exports entry

  A container can now be linked to its Durable Object from the export side, using a new container field that names an entry in the containers array. As a result containers[].class_name is now optional — a container that is referenced this way only needs a name:

  {
    "name": "my-worker",
    "main": "worker.js",
    "compatibility_date": "2026-07-01",
    "containers": [
      { "name": "my-container", "image": "./Dockerfile", "max_instances": 1 }
    ],
    "exports": {
      "MyContainerDO": {
        "type": "durable-object",
        "storage": "sqlite",
        "container": "my-container"
      }
    }
  }

  The existing containers[].class_name direction keeps working and either direction may be used, but the two must agree: a container that names its Durable Object cannot also be claimed by a different one.

  container is only valid on live durable-object exports (created and expecting-transfer) and requires storage: "sqlite". Wrangler now also reports an error when:

  • a container reference names a container that does not exist
  • two Durable Object exports claim the same container
  • a container and a Durable Object export disagree about which one they are linked to
  • a container ends up linked to no Durable Object at all
  • two containers share a name
  • a container's class_name names a Durable Object whose storage is legacy-kv
  • two containers are attached to the same Durable Object

  That last case was previously accepted but could never work: workerd attaches a single container per Durable Object namespace, and in local development every container for a class builds into the same image tag, so one silently overwrote the other. If you have two containers on one class_name, give each its own Durable Object class.

Patch Changes

• #15211 bc5726b Thanks @nithin42! - Honor access.dev when running Workers with @cloudflare/vitest-pool-workers, so ctx.access.getIdentity() returns the configured identity just as it does with wrangler dev.

• #14999 ba54f0d Thanks @mittalpk! - Fix .env loading on Windows leaking stale, differently-cased duplicate keys

  On Windows, wrangler loads .env values through a case-insensitive Proxy wrapper so lookups like env.PATH and env.Path resolve to the same value, and this object is assigned directly to process.env. When a key was set again under a different casing (e.g. a value in .env.local overriding one from .env with different casing), the previous casing was never removed from the underlying object. env.PATH/env.Path still returned the correct, latest value, but anything that enumerates process.env — Object.keys, for...in, JSON.stringify, object spread, or a spawned subprocess inheriting the environment — would see both the stale and current key.

  Duplicate entries no longer appear, so environment variables passed to subprocesses and any code that lists the environment now see only the latest value for each variable.

• #15044 b7422b0 Thanks @stareezy-1! - Normalize structural CRLF line endings before sending D1 commands to the remote query API

  wrangler d1 migrations apply --remote and wrangler d1 execute --remote --command failed with incomplete input: SQLITE_ERROR when the SQL contained CRLF line endings inside a compound statement such as a CREATE TRIGGER ... BEGIN ... END; body. Structural line endings are now normalized to LF before the command is sent to the D1 query API, while CRLF inside quoted values and identifiers remains unchanged.

• #15046 186339c Thanks @erwinzhang7! - Fixes D1 SQL statements not handling lowercase ends correctly

  wrangler d1 execute and wrangler d1 migrations apply split a SQL file into statements before running them. A BEGIN or CASE block closed with a lowercase end was not recognised as closed, so every statement after it was folded into that block instead of being run on its own. SQLite accepts either case, so a file like this applied only the trigger and silently skipped the table:

  CREATE TRIGGER IF NOT EXISTS update_trigger AFTER UPDATE ON items
  begin
  	DELETE FROM updates WHERE item_id=old.id;
  end;
  CREATE TABLE after_the_trigger (id TEXT PRIMARY KEY);

  Files written with an uppercase END were unaffected. Both cases now behave the same.

• #15231 4f922dc Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  @cloudflare/workers-types	^5.20260811.1	^5.20260814.1
  workerd	1.20260811.1	1.20260814.1

• #15248 4d74b8d Thanks @dependabot! - Update dependencies of "miniflare", "wrangler"

  The following dependency versions have been updated:

  Dependency	From	To
  @cloudflare/workers-types	^5.20260814.1	^5.20260815.1
  workerd	1.20260814.1	1.20260815.1

• #15185 1f79ace Thanks @jamesopstad! - Resolve --latest to the newest compatibility date supported by the installed runtime

  wrangler deploy --latest and wrangler versions upload --latest resolved the compatibility date to the current date, and wrangler pages download config did the same for projects configured to always use the latest compatibility date. Both write that date into a configuration file for subsequent commands to use, so a date that the installed workerd did not yet support left the project unable to run wrangler dev.

  These now resolve to the latest compatibility date supported by this version of Wrangler, which is the release date of the workerd it ships with.

• #15151 49f73de Thanks @maximilliangrand! - Fix spurious Trailing comma jsonc(519) warnings for wrangler.jsonc in VS Code 1.131+

  Trailing commas in wrangler.jsonc files that reference Wrangler's JSON schema are no longer reported as errors by recent versions of VS Code. Wrangler always accepted these files; only the editor warning was wrong.

• #14983 7cee278 Thanks @kdelay! - Respect CLOUDFLARE_ACCOUNT_ID in wrangler pages project list, create and delete

  These three commands could target a previously used account even when CLOUDFLARE_ACCOUNT_ID was set, failing with Authentication error [code: 10000] in setups with more than one account. They now use the account named by CLOUDFLARE_ACCOUNT_ID, matching the rest of wrangler pages. When the variable is unset, the previously used account is still selected, as before.

• #15153 265256a Thanks @podonnell-dev! - Fix wrangler preview base-config commands showing an inherited script positional

• #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

  When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

  The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.

• [#15239](https://github.com/cloudflare/workers...

Patch Changes

• #15217 1447950 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  @angular/create	22.1.3	22.1.4

• #15218 6d71eeb Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  create-solid	0.8.1	0.10.0

• #15219 ee15a07 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  create-next-app	16.3.0	16.3.1

• #15220 1282749 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  create-vinext-app	1.0.0-beta.1	1.0.0-beta.2

• #15221 7af190a Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  create-analog	2.6.4	2.7.0

• #15222 afe5788 Thanks @dependabot! - Update dependencies of "create-cloudflare"

  The following dependency versions have been updated:

  Dependency	From	To
  create-vike	0.0.673	0.0.675

• #14953 05959fb Thanks @edmundhung! - Update the Hello World templates to use the latest version of @cloudflare/vitest-pool-workers.

• #15185 1f79ace Thanks @jamesopstad! - Use a fixed default compatibility date rather than the current date

  When no compatibility date was set, Wrangler, C3 and the Vitest pool all defaulted to the current date. workerd only accepts a compatibility date up to 7 days beyond its own release, so whenever a workerd release was delayed the default could get ahead of the runtime that had been installed, and local development would fail to start.

  The default is now fixed at the release date of the workerd version that ships with each release, which leaves a week of headroom and updates as workerd is upgraded. @cloudflare/vite-plugin previously inlined the date at which it was built. It now shares the same default.