[FEATURE] Claude Code on Windows silently fails to start - no error message when http_proxy cannot be parsed as URL
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
When the Windows user environment variable http_proxy is set without the http:// scheme
(e.g., host:port instead of http://host:port), Claude Code on Windows silently fails to
start. The process hangs indefinitely with no output and no error message.
This affects both:
- Windows PowerShell CLI: only
claude --versionreturns normally; all other commands hang - Claude Desktop Code tab: input is accepted but no response ever comes
Internally, the error "host:port" cannot be parsed as a URL occurs but is never surfaced
to the user, making diagnosis extremely difficult. It took several hours to identify the root cause.
Note: WSL-based Claude Code CLI was unaffected throughout, as WSL does not inherit
Windows user environment variables. This further obscured the root cause during diagnosis.
Proposed Solution
When reading proxy environment variables at startup, if URL parsing fails, immediately display
a clear error message instead of hanging silently. For example:
Error: "host:port" cannot be parsed as a URL.
Please set http_proxy in the format: http://host:port
Alternative Solutions
Workaround: clear or correct the http_proxy environment variable.
# If no proxy is needed
[System.Environment]::SetEnvironmentVariable("http_proxy", "", "User")
# Or fix the format
[System.Environment]::SetEnvironmentVariable("http_proxy", "http://host:port", "User")
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
- Windows user has http_proxy set in invalid format (host:port without http://)
- Opens PowerShell and runs
claude - Process hangs indefinitely with no output
- With this feature, Claude Code would immediately show:
Error: "host:port" cannot be parsed as a URL.
Please set http_proxy in the format: http://host:port
- User fixes the environment variable and Claude Code starts normally
Additional Context
This issue was discovered after Claude Desktop v1.11847.5 (2026-06-09), which fixed
shell-exported environment variables not reaching Claude Code sessions.
Before this fix:
- Windows PowerShell CLI: silently hung (invalid http_proxy was read but cause was unknown)
- Desktop Code tab: worked (http_proxy was not passed to claude.exe)
After this fix:
- Windows PowerShell CLI: still hangs (same root cause)
- Desktop Code tab: now also hangs (http_proxy is now correctly passed to claude.exe)
The Desktop Code tab regression triggered a deep investigation, which finally revealed
that the invalid http_proxy format was the root cause affecting both environments.
Had Claude Code displayed a clear error message on startup, this would have been diagnosed
in minutes rather than hours.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗