CLAUDE_CODE_SSE_PORT set → every API call fails with ConnectionRefused in VS Code extension (Windows)

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 0 comments · opened Sep 3, 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?

(Feedback ID from in-app report: 37645eb3-c633-46ed-b99c-38dfe8063383)

BUG: VS Code extension panel permanently fails with ConnectionRefused
whenever CLAUDE_CODE_SSE_PORT is set, while the standalone CLI works
fine without it.

Environment: Claude Code VS Code extension v2.1.259, Windows 10,
only Windows Defender active (no 3rd-party AV/firewall).

Symptom: Every /v1/messages request from the extension panel fails
immediately: "[ERROR] API error (attempt N/11): undefined Connection
error", surfacing in the UI as "API Error: Connection refused — a
firewall or proxy may be blocking it (ConnectionRefused)", debug
detail "code=ConnectionRefused, message=Unable to connect. Is the
computer able to access the url?". Happens on every single message,
100% reproducible, exhausting all 11 retries.

Reproduction:

  1. Open VS Code, extension injects CLAUDE_CODE_SSE_PORT into the

spawned claude.exe child process env (observed with two different
values across a full VS Code restart: 54370, then 22346 — not a
stale leftover, happens on a freshly spawned process every time).

  1. Send any message in the panel -> fails as above every time.
  2. In parallel, in a plain terminal: claude with

CLAUDE_CODE_SSE_PORT still set in the shell env -> same failure.

  1. Remove-Item Env:\CLAUDE_CODE_SSE_PORT in that same shell, then

claude again -> connects and works perfectly, every time.

Ruled out as the cause (all confirmed clean on this machine):

  • No proxy env vars, no ANTHROPIC_BASE_URL/Bedrock/Vertex override.
  • curl.exe -v https://api.anthropic.com and a raw

node -e "require('https').get(...)" both succeed cleanly.

  • Only Windows Defender present; Protection History shows nothing

blocked/flagged.

  • netsh interface ipv4 show excludedportrange protocol=tcp shows

only 50000-50059 excluded — unrelated to the SSE ports used.

  • Loopback networking itself works: a self-contained Node script

(http server on 127.0.0.1:<random port> + client in the same
process) connects successfully.

So the failure is specific to something the CLI does when
CLAUDE_CODE_SSE_PORT is present — looks like a failed/refused
connection attempt to the local IDE companion channel is blocking
or poisoning the real Anthropic API calls too, instead of just
disabling the optional IDE-streaming feature gracefully.

Possibly related: anthropics/claude-code#42141 (CLAUDE_CODE_SSE_PORT
going stale breaks /ide detection on Windows) — but that issue is
about /ide silently failing, this one breaks the core chat API
entirely. Closed as "not planned" there, but the underlying
SSE-port fragility on Windows appears unresolved.

Workaround: none for the VS Code panel itself. The standalone CLI
works fine as long as CLAUDE_CODE_SSE_PORT is unset in that shell.

What Should Happen?

The VS Code extension panel should connect to the Anthropic API and
respond normally — exactly like the standalone claude CLI does on
this same machine when CLAUDE_CODE_SSE_PORT is not set in the
environment.

Error Messages/Logs

[ERROR] API error (attempt 11/11): undefined Connection error.
[ERROR] Error in API request: Connection error.
[ERROR] Connection error details: code=ConnectionRefused, message=Unable to connect. Is the computer able to access the url?
[ERROR] API connection_error after retries: Connection error.

UI: API Error: Connection refused — a firewall or proxy may be blocking it (ConnectionRefused)

Steps to Reproduce

  1. Open VS Code with the Claude Code extension (v2.1.259) on Windows.
  2. Open the Claude Code panel and send any message (e.g. "ciao").
  3. Every request fails immediately with "API Error: Connection refused —

a firewall or proxy may be blocking it (ConnectionRefused)" after
exhausting 11 retries.

  1. In a separate terminal, with CLAUDE_CODE_SSE_PORT still set in the

shell env (as injected by VS Code), run claude -> same failure.

  1. In that same terminal: Remove-Item Env:\CLAUDE_CODE_SSE_PORT,

then run claude again -> connects and works normally, every time.

  1. Reproduced with two different port values (54370, then 22346)

across a full VS Code restart — not a one-off stale value.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.259

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Ruled out as the cause (all confirmed clean on this machine):

  • No proxy env vars, no ANTHROPIC_BASE_URL/Bedrock/Vertex override.
  • curl.exe -v https://api.anthropic.com and a raw

node -e "require('https').get(...)" both succeed cleanly.

  • Only Windows Defender present; Protection History shows nothing

blocked/flagged.

  • netsh interface ipv4 show excludedportrange protocol=tcp shows

only 50000-50059 excluded — unrelated to the SSE ports used.

  • Loopback networking itself works: a self-contained Node script

(http server on 127.0.0.1:<random port> + client in the same
process) connects successfully.

So the failure is specific to something the CLI does when
CLAUDE_CODE_SSE_PORT is present — a failed/refused connection to the
local IDE companion channel seems to block or poison the real
Anthropic API calls too, instead of gracefully disabling the
optional IDE-streaming feature.

Possibly related: anthropics/claude-code#42141 (CLAUDE_CODE_SSE_PORT
going stale breaks /ide detection on Windows) — but that issue is
about /ide silently failing, this one breaks the core chat API
entirely. Closed as "not planned" there.

In-app feedback ID already submitted: 37645eb3-c633-46ed-b99c-38dfe8063383

Workaround: none for the VS Code panel. The standalone CLI works
fine as long as CLAUDE_CODE_SSE_PORT is unset in that shell.

View original on GitHub ↗