Issue Review: cloudflare/workers-sdk#11098

Summary

Wrangler should surface Access-related errors (e.g., cloudflared installation requirement) when using remote bindings, instead of showing generic error messages.

Findings

• Created: 2025-10-25
• Updated: 2026-01-12
• Version: 4.42-4.45 (reported) → 4.60.0 (current)
• Component: wrangler (remote bindings)
• Labels: bug
• Comments: 2

Key Evidence

• Maintainer confirmed: @petebacondarwin acknowledged the issue on 2025-10-27, agreeing that errors from the "remote binding proxy worker" should be surfaced to users
• Detailed reproduction provided: @AndreasMadsen on 2026-01-12 provided exact reproduction steps using vitest-pool-workers with a vectorize remote binding and no cloudflared installed
• Code location identified: Error is swallowed at packages/wrangler/src/api/remoteBindings/start-remote-proxy-session.ts:74-80 where maybeError contains useful details (UserError about cloudflared installation) but only a generic message is thrown
• Related but not fixing PRs:
  • PR #11018 (2025-10-20): Improved error handling for startWorker failures but not the maybeError path
  • PR #11383 (2025-11-28): Ensured wrangler crashes instead of hanging but doesn't surface actual error details
• Not mentioned in changelog: Issue #11098 is not referenced in the wrangler changelog

Code Analysis

Current code at the error location:

if (maybeError && maybeError.error) {
  throw new Error(
    "Failed to start the remote proxy session. There is likely additional logging output above.",
    {
      cause: maybeError.error,
    }
  );
}

The maybeError.error contains the useful UserError message (e.g., "To use Wrangler with Cloudflare Access, please install cloudflared...") but this is only attached as cause and not displayed to the user.

Recommendation

Status: KEEP OPEN

Reasoning: This is a confirmed, valid bug with clear reproduction steps and an identified code location. A maintainer has acknowledged the issue, and a community member recently (2026-01-12) confirmed it's still reproducible with the current version. The related PRs (#11018, #11383) improved error handling but did not address the specific error surfacing issue identified here.

Action: Keep issue open for a fix. The fix should extract and display the actual error message from maybeError.error.cause (the UserError) rather than just using it as a nested cause.