# Bug: "Unable to connect" error persists until model is toggled

Resolved 💬 3 comments Opened May 12, 2026 by esaehrig Closed May 16, 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: "Unable to connect" error persists until model is toggled

Environment

  • Claude Code: VSCode Extension (Windows)
  • OS: Windows 11 Enterprise 10.0.26200
  • Models affected: claude-opus-4-6[1m], claude-opus-4-6
  • Shell: bash (Git Bash)

Description

Claude Code intermittently enters a state where all API requests fail with:

API Error: Unable to connect. Is the computer able to access the url?

The error persists across multiple retry attempts on the same model. Switching to a different model (e.g., from claude-opus-4-6[1m] to claude-opus-4-6) and then switching back resolves the issue. The API endpoint is reachable from the machine (confirmed via curl), so the problem appears to be in the extension's HTTP client or connection pool, not network connectivity.

Steps to Reproduce

  1. Open Claude Code in VSCode on Windows 11
  2. Use model claude-opus-4-6[1m] (or claude-opus-4-6)
  3. Send a message — works normally
  4. At some point (timing unclear), subsequent messages fail with "Unable to connect"
  5. Retrying on the same model continues to fail
  6. Switch model via /model claude-opus-4-6 — also fails
  7. Switch back via /model claude-opus-4-6[1m] — connection is restored and messages succeed again

Expected Behavior

Messages should continue to be sent successfully, or if a transient connection failure occurs, the next retry should succeed without requiring a model toggle.

Actual Behavior

The extension gets stuck in a "Unable to connect" state. The only workaround is toggling the model away and back, which presumably resets the underlying HTTP connection or session state.

Workaround

Run /model <any-other-model> followed by /model <original-model> to reset the connection.

Screenshots

![Bug reproduction showing the sequence of failures and recovery after model toggle](screenshot.png)

Additional Context

  • The failure is not model-specific — both claude-opus-4-6 and claude-opus-4-6[1m] individually failed, but toggling between them fixed it.
  • Network connectivity to api.anthropic.com was confirmed working via curl -v during the failure window.
  • This suggests the issue is in client-side connection/session management (e.g., stale connection pool, expired keep-alive, or TLS session reuse failure) rather than an API-side outage.

What Should Happen?

The error persists across multiple retry attempts on the same model. Switching to a different model (e.g., from claude-opus-4-6[1m] to claude-opus-4-6) and then switching back resolves the issue. The API endpoint is reachable from the machine (confirmed via curl), so the problem appears to be in the extension's HTTP client or connection pool, not network connectivity.

Error Messages/Logs

API Error: Unable to connect. Is the computer able to access the url?

Steps to Reproduce

  1. Open Claude Code in VSCode on Windows 11
  2. Use model claude-opus-4-6[1m] (or claude-opus-4-6)
  3. Send a message — works normally
  4. At some point (timing unclear), subsequent messages fail with "Unable to connect"
  5. Retrying on the same model continues to fail
  6. Switch model via /model claude-opus-4-6 — also fails
  7. Switch back via /model claude-opus-4-6[1m] — connection is restored and messages succeed again

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.6 1 m

Claude Code Version

Claude code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

  • The failure is not model-specific — both claude-opus-4-6 and claude-opus-4-6[1m] individually failed, but toggling between them fixed it.
  • Network connectivity to api.anthropic.com was confirmed working via curl -v during the failure window.
  • This suggests the issue is in client-side connection/session management (e.g., stale connection pool, expired keep-alive, or TLS session reuse failure) rather than an API-side outage.

View original on GitHub ↗

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