outboundByHost / interceptHttps breaks when worker uses placement: targeted

[reuben-ki]

Describe the bug

When a Cloudflare Worker using @cloudflare/sandbox has placement: { mode: "targeted", region: "..." } set in wrangler.jsonc, the outboundByHost handler is never invoked for HTTPS traffic originating inside the container. Switching to placement: { mode: "smart" } (or removing the placement block entirely) fixes interception with no other code changes.

To Reproduce

1. Create a Sandbox subclass with interceptHttps = true and a static outboundByHost handler:

export class MySandbox extends Sandbox<Env> {
  interceptHttps = true
  defaultPort = 3000
}

MySandbox.outboundByHost = {
  'api.anthropic.com': () =>
    new Response('intercepted', {
      status: 200,
      headers: { 'x-test-intercepted': 'yes', 'content-type': 'text/plain' },
    }),
}

2. Add "placement": { "mode": "targeted", "region": "aws:eu-west-2" } to wrangler.jsonc.
3. Deploy and run sandbox.exec('curl -sS -i --max-time 5 https://api.anthropic.com/') from a worker handler.
4. Observe: x-test-intercepted header is absent from the curl output (outbound bypasses the handler entirely).
5. Remove the placement block (or change to "mode": "smart"), redeploy.
6. Observe: x-test-intercepted: yes is present — handler fires correctly.

Expected behavior

outboundByHost handlers should intercept container outbound HTTPS traffic regardless of the worker's placement mode.

Screenshots

With placement: { mode: "smart" } — interception works. The Cf-Placement response header shows the worker and container running in the same colo (local-CDG):

{ "intercepted": true, "stdoutHead": "HTTP/1.1 200 OK\r\nCf-Placement: local-CDG\r\n...X-Test-Intercepted: yes\r\n\r\nintercepted" }

With placement: { mode: "targeted", region: "aws:eu-west-2" } — handler never fires:

{ "intercepted": false, "stdoutHead": "" }

Version

• @cloudflare/sandbox: 0.9.2
• @cloudflare/containers: 0.3.3
• Wrangler: 4.84.0
• compatibility_date: 2026-04-22
• compatibility_flags: ["nodejs_compat"]

Additional context

The Cf-Placement: local-CDG header in the working case suggests that targeted placement pins the entry worker to a different colo from where the container and its ContainerProxy isolate run. The SDK's handler registry (outboundByHostRegistry) is per-isolate, so the ContainerProxy isolate in the container's colo never sees the handler registered by the entry worker's isolate.

Workaround: use placement: { mode: "smart" } instead of targeted.