#7286·workerd

[Miniflare] Cross-worker Durable Object proxy drops ctx.id.name for IDs created with idFromName()

Author: HemeraOneCreated Sep 3, 2026Updated Sep 9, 2026

What versions & operating system are you using?

  • Wrangler: 4.127.1
  • Miniflare: 5.20260828.0-alpha
  • workerd: 1.20260828.1
  • Node.js: 24.18.0
  • OS: Linux x86_64, kernel 5.15
  • compatibility date: 2026-08-01

Please provide a link to a minimal reproduction

https://github.com/HemeraOne/miniflare-cross-worker-do-name-repro

Describe the Bug

When a Durable Object is addressed through a cross-worker script_name binding in local development, the calling Worker creates the ID using idFromName("demo"), and id.name is correctly "demo". Inside the target Durable Object, however, ctx.id.name is undefined.

The reproduction runs the target and caller as separate wrangler dev processes so the binding uses the local dev registry proxy.

Steps:

  1. Clone the reproduction and run npm install.
  2. Run npm run dev:target in one terminal.
  3. Run npm run dev:caller in another terminal.
  4. Run curl http://localhost:8787.

Observed response:

json
{
  "callerName": "demo",
  "targetIdentity": {
    "id": "b1ccfce0b5e6b4bbf20bf9b3deab56d6fde0a93191910bee462c390e7f925ff3",
    "name": null
  }
}

Expected: targetIdentity.name is "demo", matching callerName.

The Durable Object ID documentation states that ctx.id.name is available when the caller uses idFromName() or getByName():

https://developers.cloudflare.com/durable-objects/api/id/#name

The current proxy implementation appears to forward only the hexadecimal ID to getActor():

https://github.com/cloudflare/workers-sdk/blob/main/packages/miniflare/src/workers/core/dev-registry-proxy-shared.worker.ts#L214-L220

This passes this.ctx.id.toString() across the process boundary. Reconstructing the target actor from that value appears to lose the logical name, consistent with the documented behavior of idFromString().

The discrepancy breaks libraries that correctly rely on native ctx.id.name for named Durable Objects. For example, Agents SDK 0.22 reports that it cannot determine the Durable Object name even though the caller used getAgentByName(), which addresses the object through idFromName().

Relevant error logs

The raw Durable Object reproduction returns name: null as shown above. With Agents SDK 0.22 this surfaces as:

Agent could not determine its Durable Object name. Address it with idFromName() or getByName().