API Error 400 - Frequent tool use concurrency issues with Remote SSH

Resolved 💬 4 comments Opened Jan 26, 2026 by palonsorodriguez Closed Jan 26, 2026

Problem

Experiencing frequent API errors during active sessions:

API Error: 400 due to tool use concurrency issues

Symptoms

  • Error occurs every 10-30 seconds during typical workflows
  • Completely blocks execution
  • Requires manually typing "continue" to resume
  • Can happen 20-30+ times in a single session
  • Severely impacts usability for multi-step tasks

Environment

  • VS Code: 1.108.2
  • OS: Ubuntu 24.04.3 LTS
  • Claude Code Extension: anthropic.claude-code@2.1.19
  • Connection Type: Remote SSH to Ubuntu server
  • Workflow: Multi-step operations (file operations, commands, searches)

Root Cause Observation

The extension appears to make parallel tool calls for efficiency:

<function_calls>
  <invoke name="Tool1">...</invoke>
  <invoke name="Tool2">...</invoke>
  <invoke name="Tool3">...</invoke>
</function_calls>

When multiple tools execute simultaneously (especially over Remote SSH), API returns 400 concurrency errors.

When It Occurs

Most commonly during:

  • Multiple file read/write operations
  • Sequential command executions
  • Parallel data gathering operations
  • Any workflow requiring 3+ tool invocations

Impact on User Experience

  • Productivity: Sessions requiring 30 minutes can extend to hours
  • Interruption: Constant manual intervention breaks flow
  • Frustration: Makes complex multi-step tasks nearly unusable

Workaround

Instructing Claude at session start to use sequential calls:

Use sequential tool calls only. Make ONE tool call per message to avoid API 400 errors.

Result: Zero 400 errors but ~20-30% slower execution.

Analysis

Current Behavior (Parallel Calls):

  • ✅ Optimized for speed
  • ❌ Frequently fails with 400 errors
  • ❌ Poor user experience

Workaround (Sequential Calls):

  • ✅ 100% reliable
  • ✅ Predictable progress
  • ❌ Slower performance
  • ✅ Much better overall UX

Suggestion

Consider:

  1. Making sequential calls the default (or user-configurable)
  2. Implementing better error recovery for 400 concurrency errors
  3. Rate limiting or queuing parallel tool calls to prevent API overwhelm
  4. Providing user control over concurrency level

The parallel optimization appears to cause more problems than it solves in Remote SSH scenarios.

Expected Behavior

Tool calls should execute reliably without frequent API errors, even if slightly slower.

Actual Behavior

Parallel tool calls trigger frequent 400 errors requiring manual recovery.

View original on GitHub ↗

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