Claude Desktop gets permanently stuck routing all traffic through a dead 127.0.0.1:8080 proxy after using mitmproxy, surviving app restart and full reboot

Status Fixed / completed
Maintainer reply None cached
Activity 1 comment · opened Aug 21, 2026 · closed Aug 21, 2026

Environment

  • Claude Desktop version: was 1.32885.1.0, bug persists after auto-update to 1.34493.1.0
  • OS: Windows 11 Pro (MSIX install)
  • Electron 42.9.2

What happened
On 2026-08-20 I ran mitmproxy on 127.0.0.1:8080 for unrelated network debugging.
Since then, Claude Desktop hangs on every launch — main window, growthbook,
telemetry, and the auto-updater all fail with net::ERR_PROXY_CONNECTION_FAILED.
Chromium's network service process repeatedly attempts SynSent connections to
127.0.0.1:8080 (confirmed via netstat), even though nothing listens there anymore.

Log evidence (main.log, only occurrence ever):
2026-08-20 15:45:55 [info] [CCD] Resolved system proxy for Code sessions: http://127.0.0.1:8080
2026-08-20 15:45:55 [info] [bridge-ws] Using system proxy http://127.0.0.1:8080 for wss://bridge.claudeusercontent.com/...

Ruled out (all clean)

  • Windows system proxy: WinHTTP (netsh winhttp show proxy = Direct), IE/WinINET

simple registry values AND binary DefaultConnectionSettings/SavedLegacySettings
blobs, all named VPN/RAS connection blobs

  • No VPN connected
  • No HTTP_PROXY/HTTPS_PROXY env vars (user or machine)
  • Claude's own config.json / Preferences / Local State / IndexedDB — searched at

raw byte level for "8080", nothing found

  • Full PC reboot — bug persists, ruling out any Windows service-level cache

(e.g. WinHttpAutoProxySvc)

  • No proxy-related command-line flags on any Claude process

Workaround
Running a dumb local pass-through TCP relay on 127.0.0.1:8080 makes the app
work immediately (connections go from stuck SynSent to Established). This
strongly suggests Claude Desktop itself has hardcoded/cached logic that keeps
retrying a proxy it detected once (likely meant only to support local dev
proxies like mitmproxy/Charles/Fiddler for the "Code sessions" / CCD bridge
feature), and this detection never expires or gets reset — not even across a
full reboot.

Expected behavior
Claude Desktop should re-resolve the system proxy on each launch (or at least
periodically), not permanently cache a one-time detection, and a stale/dead
proxy should not block ALL app traffic (main UI, telemetry, updater) — only
whatever feature actually needs it.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗