[BUG] Cloud Sessions Require External Message to Initialize on Windows Desktop

Resolved 💬 3 comments Opened Dec 4, 2025 by BorderlessBits Closed Feb 5, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Bug Report: Cloud Sessions Not Initializing Properly on Windows Desktop

Summary

Cloud sessions created from Claude Desktop for Windows fail to stream responses back to the initiating device, but work correctly when another device sends a message to "wake up" the session. After this initial activation, the session functions normally on the Windows desktop.

Environment

  • Claude Desktop Version: 1.0.1405
  • Operating System: Windows 11 Pro (Build 10.0.26200)
  • Hardware: AMD Ryzen 9 5900X, 32GB RAM
  • Network: Starlink ISP (CGNAT environment, bridge mode enabled)
  • Network Adapter: Realtek Ethernet with custom offloading settings

Actual Behavior

  • Cloud session creates successfully (session_id generated, visible across devices)
  • Initial prompt from PC receives no streaming response
  • Session appears "stuck" in an unsubscribed state
  • Sending a message from another device "activates" the session
  • After activation, PC functions normally for all subsequent messages

System Configuration Details

Network Adapter Settings (Potentially Relevant)

The following TCP offloading features were disabled on the primary Ethernet adapter:

  • IPv4 Checksum Offload: Disabled
  • TCP Checksum Offload (IPv4): Disabled
  • UDP Checksum Offload (IPv4): Disabled
  • Large Send Offload V2 (IPv4): Disabled
  • Interrupt Moderation: Disabled
  • Flow Control: Disabled

Note: These settings were re-enabled during troubleshooting. Issue persisted intermittently after re-enablement and system restart.

Firewall Configuration

Custom Windows Firewall rules were created for:

  • Claude Desktop (Inbound/Outbound)
  • Claude Code binary (Inbound/Outbound)

Network Environment

  • ISP: Starlink with CGNAT (Carrier-Grade NAT)
  • Router Mode: Bridge mode enabled
  • IPv6: Disabled system-wide
  • DNS: Cloudflare (1.1.1.1)

Troubleshooting Performed

Initial Diagnosis

  1. Cloudflare Turnstile Issues (Resolved)
  • Initial logs showed CORS errors with Cloudflare Turnstile
  • Fixed by disabling MalwareBytes Web Protection
  • Fixed by changing DNS to 1.1.1.1
  1. Firewall Blocking (Resolved)
  • No firewall rules existed for Claude
  • Created bidirectional rules for Claude.exe and claude-code binary
  • Confirmed rules active and allowing traffic
  1. IPv6 Conflicts (Resolved)
  • Disabled IPv6 system-wide (Starlink IPv6 implementation issues)
  • Verified IPv4-only resolution and connectivity
  1. Network Adapter Configuration (Partially Resolved)
  • Re-enabled TCP offloading features
  • Restarted system to apply changes
  • Issue became intermittent but not fully resolved
  1. VPN Testing (Inconclusive)
  • Tested with multiple VPN providers (Cloudflare WARP, VPN Unlimited)
  • VPN did not resolve the issue
  • Ruled out CGNAT as primary cause (mobile device on same network works)

Key Findings

Critical Discovery: Mobile device on the same Starlink network can create and use cloud sessions without any issues. This indicates:

  • Network connectivity is sufficient
  • CGNAT is not the primary cause
  • Issue is specific to Windows desktop client behavior

Session State Observation:

  • OAuth authentication succeeds
  • Session is created on cloud infrastructure
  • WebSocket/SSE connection appears to establish
  • But streaming subscription is not properly initialized
  • Sending message from another device "flushes" or activates the subscription

Observed Pattern

  1. Session creation succeeds
  2. "Starting Claude Code..." appears
  3. No error messages in UI
  4. Session visible across devices
  5. Streaming fails silently until activated by another device

Workaround

Temporary Solution:

  1. Create cloud session on Windows PC
  2. Open session on mobile device (or any other device)
  3. Send any message (e.g., "test") from the mobile device
  4. Session becomes active on PC and works normally thereafter

Frequency

  • Intermittent issue (not 100% reproducible)
  • Occurred in approximately 30% of session creation attempts during testing
  • More frequent after initial Claude restart or long idle periods
  • Less frequent after "warm-up" (several successful activations)

Additional Notes

What Works

  • ✅ Local sessions work perfectly without any issues
  • ✅ OAuth authentication succeeds consistently
  • ✅ Session synchronization across devices works
  • ✅ After "activation", all features work normally (MCP, filesystem, etc.)
  • ✅ Mobile device on same network has no issues

What Doesn't Work

  • ❌ Initial streaming response from cloud session on Windows PC
  • ❌ Consistent/reliable session initialization without intervention

Suspected Root Cause

The behavior suggests a client-side streaming subscription initialization bug where:

  1. WebSocket/SSE connection establishes successfully
  2. But the client doesn't properly subscribe to or listen for server events
  3. An external message triggers proper subscription initialization
  4. Once initialized, everything works as expected

This could be related to:

  • Event listener registration timing
  • WebSocket upgrade handshake edge case
  • TCP window scaling with specific network adapter configurations
  • Race condition in session initialization code

Recommended Investigation

  1. Review streaming connection initialization code in Windows client
  2. Check event listener/subscription setup during session creation
  3. Examine differences between mobile and desktop client initialization
  4. Test with network packet captures to verify streaming connection state
  5. Add debug logging around streaming subscription initialization

Impact

Severity: Medium

  • Workaround exists (use another device to activate)
  • Does not affect local sessions
  • Does not cause data loss
  • Impacts user experience and workflow

Affected Users:

  • Windows users with specific network configurations
  • Particularly those with modified TCP offloading settings
  • Potentially affects CGNAT environments (though mobile works fine)

Contact Information

Available for follow-up testing or additional log collection if needed.

---

Report Generated: December 4, 2025
Debug Logs: Available upon request (multiple log collections performed during troubleshooting)

What Should Happen?

Cloud sessions should initialize properly and stream responses immediately to the device that created the session, without requiring intervention from another device.

Error Messages/Logs

### From main.log (OAuth Success)

2025-12-04 14:18:34 [info] using oauth config {
  redirectUri: 'https://console.anthropic.com/oauth/code/callback',
2025-12-04 14:18:34 [info] tyring to load oauth token cache
2025-12-04 14:18:34 [info] performing fresh oauth exchange


### From claude_ai-web.log (Network Errors)

2025-12-04 14:15:49 [error] [COMPLETION] Request failed TypeError: network error
2025-12-04 14:15:49 [error] [COMPLETION] Non-API stream error TypeError: network error
2025-12-04 14:15:49 [error] Uncaught (in promise) TypeError: network error

Steps to Reproduce

  1. Open Claude Desktop on Windows PC
  2. Click "New Cloud Session"
  3. Enter a prompt and submit
  4. Observe: Session is created (visible on other devices), but no response streams back to PC
  5. Open same session on another device (e.g., mobile phone)
  6. Send any message from the other device (e.g., "test")
  7. Observe: Response streams to both devices, PC session now works normally

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.54

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

I have additional detailed logs if needed.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗