Issue Review: cloudflare/workers-sdk#9789

Summary

wrangler dev --ip crashes with TCP_NODELAY error or hangs with network errors on macOS when Firewall is enabled, preventing local network development.

Findings

• Created: 2025-06-28
• Updated: 2025-06-28
• Version: 4.22.0 → 4.60.0 (current)
• Component: wrangler (dev server / workerd)
• Labels: bug
• Comments: 1

Key Evidence

• Distinct from #4763: The previously fixed issue #4763 (closed 2024-02-08, fix: PR #4830) was about --ip 0.0.0.0 not being accessible from other devices. This new issue is about crashes/hangs when macOS Firewall is enabled, even with workerd allowed.

• Two specific failure modes reported:

  1. --ip 192.168.x.x with Firewall up: Repeated "Network connection lost" errors, CLI appears to hang
  2. --ip 0.0.0.0 with workerd allowed in Firewall: Fatal crash with setsocketopt(IPPROTO_TCP, TCP_NODELAY): Invalid argument

• TCP_NODELAY crash is in workerd: The stack trace shows kj/async-io-unix.c++:1365 which is in the workerd/kj networking code, not wrangler itself. This is a low-level socket option failure.

• No fix found:

  • No merged PRs reference issue #9789
  • No changelog entries for TCP_NODELAY or firewall-related fixes
  • No similar issues found in workerd repo

• Reporter comment: Confirmed they tried the fix from #4763 but it didn't work for their case.

• Related issue #6899: Shows similar macOS networking issues with wrangler dev, suggesting ongoing platform-specific socket handling challenges.

Recommendation

Status: KEEP OPEN

Reasoning: This is a valid, well-documented bug report with clear reproduction steps, error messages, and log files. The TCP_NODELAY crash appears to be a genuine bug in workerd's socket handling on macOS when dealing with firewall-related network restrictions. The issue is recent (less than 1 month old) and affects local network development workflows.

Action: Keep open for investigation. The TCP_NODELAY error may need to be addressed in workerd rather than wrangler. Consider adding needs-triage or workerd label to route to appropriate team.

Suggested Comment

Thank you for the detailed bug report with reproduction steps and log files. This appears to be a valid issue with how workerd handles socket options on macOS when the firewall restricts network access.

The TCP_NODELAY crash in particular seems to be occurring at the workerd level rather than wrangler. We'll investigate and may need to coordinate with the workerd team on a fix.

In the meantime, the workaround of disabling the macOS Firewall (as you noted) or using a port forwarding tool like socat should allow local network development.