Remote proxy session startup returns generic Error before RPC for two active private Workers

## What versions & operating system are you using?

- Wrangler: 4.120.1
- Miniflare: 5.20260804.0-alpha
- Node.js: v22.22.3
- OS: macOS 26.5 (Darwin)
- Architecture: arm64
- API: maybeStartOrUpdateRemoteProxySession

These versions are retained from the completed investigation. No diagnostic rerun or version change was made for this report.

## Minimal reproduction

A public minimal reproduction repository is not currently available. The affected configurations are private. This report provides sanitized observations and requests the supported next diagnostic step; it does not claim a confirmed SDK defect or replace a reproducible case.

## Observed behavior

Session creation fails for two present, active private Workers through the same SDK, account, and session-start harness, before application RPC or application authentication.

| Target role | Entrypoint | Duration | Result |
| --- | --- | --- | --- |
| Private Control Worker | Named WorkerEntrypoint | Approximately 869 ms | Generic Error; session not created |
| Known-active private Evidence Worker | Default deny-all entrypoint | Approximately 616 ms | Generic Error; session not created |

Both Workers were confirmed present/active during the investigation. The Evidence target is known-active, not a previously successful remote-session target. It is a deny-all bootstrap, not evidence of a working publisher capability.

Neither attempt reached the 45-second hard timeout. Neither returned a usable session handle, session ID, useful error code, HTTP status, or cause. No usable request identifier was exposed. One diagnostic attempt was made per target; retries are now stopped.

Expected behavior: a supported configuration should create a usable session, or return an actionable error identifying an unsupported configuration, login/scope issue, or provisioning failure. Application RPC should not be required merely to establish a session.

## Sanitized description of completed attempts

1. Use the installed API with a local configuration selecting a remote service binding to a private active Worker.
2. Supply the required config path selector according to the installed API. No explicit authentication hook is injected.
3. Attempt session establishment once under a bounded timeout, without invoking application RPC.
4. Observe the generic Error and missing session handle.
5. In the already-completed comparison, select the separate known-active deny-all Worker through the same SDK/account/harness. Observe the same startup failure.

These steps describe prior attempts, not new runs. Actual resource names, local paths, identifiers, and credentials are intentionally omitted; this is not a runnable reproduction with account access.

## Contract and local isolation evidence

Installed SDK typings/source were checked directly, including required and optional session inputs. Offline configuration parsing and account/target/entrypoint mapping checks passed.

The connection handle is treated as opaque, not assumed to be a string, and is not dumped or serialized. The known-hanging getBindings() path is not used.

Local workerd RPC, synthetic authentication/intent handling, direct synthetic storage-write instrumentation, timeout handling, cleanup, terminal restoration, and leak tests pass. Rejected synthetic requests generate zero local writes; an expected positive synthetic local write confirms that the counter works.

Those local tests do not establish that Cloudflare remote-session provisioning works. Local session substitutes do not validate the failing remote service, and the synthetic positive write was not a Production approval.

The non-interactive child uses a restricted environment without explicit API-token injection. Whether SDK-managed Cloudflare login credentials are usable inside that process remains unconfirmed. This uncertainty concerns session establishment, not application Operator authentication.

## Available error evidence

- Error class: generic Error.
- Useful error code: unavailable.
- HTTP status: unavailable.
- Cause: unavailable.
- Session/request identifier: unavailable.
- Both failures occurred before the configured timeout.

Raw SDK logs are not attached because they could contain sensitive metadata. Exact attempt timestamps and correlation details are retained for an appropriate private support channel.

## Impact and safety

For these two failed session-start attempts:

- Application RPC / publish calls: 0.
- Operator secret input/use: 0.
- Signed intents created/submitted: 0.
- Application R2 operations/writes: 0.
- Production application/configuration mutations: 0.

SDK-internal provisioning activity is not independently observable from the generic Error. We are not claiming that no upstream provisioning request occurred.

No public/debug route, privilege expansion, diagnostic redeployment, credential rotation, or stateful approval was introduced as a workaround. There is no already-approved deployed in-account caller for the named publisher.

The shared SDK/account/session path remains an investigation category, not a confirmed root cause. This is not evidence of a Control/Evidence artifact defect, an Operator credential failure, an R2 failure, or a confirmed Cloudflare outage.

## Questions

1. Is there an account-level restriction or outage affecting remote proxy / edge-preview session creation?
2. Is maybeStartOrUpdateRemoteProxySession affected by a known issue in Wrangler 4.120.1?
3. Is this remote-session mode supported for this account/configuration?
4. Can Cloudflare retrieve server-side diagnostic/error identifiers for these failed session-start attempts?
5. What is the supported method to validate a non-public WorkerEntrypoint RPC when no deployed in-account caller exists, without relying on this remote-session path?

## Disclosure boundary

No account IDs, deployment/version IDs, actual Worker resource names, local filesystem paths, secrets, authentication headers, raw signed intents, PII, or customer/business payloads are included. Sensitive correlation details are reserved for private support.

Start with maybeStartOrUpdateRemoteProxySession and the installed SDK typings/source, then trace how remote session startup errors are surfaced before application RPC. The report has no runnable reproduction or named source files, so confirm the failure with a reproducible case and make the result expose an actionable diagnostic or supported-configuration outcome.

Written by the indexing model from the issue text.