[BUG] Tool Stream Closes Unexpectedly During Operations

Resolved 💬 5 comments Opened Oct 20, 2025 by chris-kreidl Closed Jan 8, 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 Report: Tool Stream Closes Unexpectedly During Operations

Description

Claude Code tools (Edit, Bash) intermittently fail with "Stream closed" errors during active operations, regardless of user activity. The errors are unpredictable and occur during both quick and long-running operations.

Environment

  • Platform: macOS (Darwin 24.5.0)
  • Claude Code Version: VSCode Extension (CLAUDE_CODE_ENTRYPOINT=claude-vscode)
  • Session Duration: 2+ hours
  • Frequency: 4+ occurrences in a single session
  • Repository: Next.js 15 project with TypeScript, Prisma ORM

What Should Happen?

Expected Behavior

Tools should either:

  1. Complete successfully, or
  2. Fail with a clear, actionable error message (e.g., "File locked by IDE", "Operation timeout after 30s")

Error Messages/Logs

### Error Messages

Tool permission request failed: Error: Stream closed

Steps to Reproduce

Reproduction

Not reliably reproducible - appears to be non-deterministic based on internal state, network conditions, or resource constraints.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.14 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

Detailed Occurrences from Session (2025-10-20)

Occurrence 1: Edit Tool on components/lib/katana.ts
  • Operation: Updating getMaterialsFromKatana() function
  • Context: Attempted to replace ~35 lines of code with parallel pagination implementation
  • First attempt: Failed with "Stream closed"
  • Second attempt: Also failed with "Stream closed"
  • User state: Actively monitoring, in the Claude Code tab
Occurrence 2: Bash Tool with Heredoc
  • Operation: Writing migration SQL file using cat with heredoc
  • Command: cat > /path/to/migration.sql << 'EOF'
  • Context: Creating a database migration file (~60 lines)
  • Result: "Stream closed" immediately
  • User state: Actively engaged, no tab switching
Occurrence 3: Edit Tool on lib/schemas/common.ts (First Attempt)
  • Operation: Adding JSDoc documentation (replacing 2 lines with ~25 lines)
  • Context: Improving TypeScript documentation
  • Result: "Stream closed"
  • User state: File was open in IDE at time of edit
Occurrence 4: Edit Tool on lib/schemas/common.ts (Second Attempt)
  • Operation: Same edit, different approach
  • Context: Retry after first failure
  • Result: "Stream closed" again
  • Resolution: User manually added documentation, Claude committed successfully

Operations That Worked Successfully

For comparison, these operations worked without issues:

  • ✅ Edit: Updated getProductsFromKatana() (~50 lines replaced)
  • ✅ Edit: Updated getPriceList() (~35 lines replaced)
  • ✅ Bash: Multiple git status, grep, find commands
  • ✅ Read: All file read operations
  • ✅ Bash: Running npx prisma migrate dev (10+ second operation)
  • ✅ Edit: Updated prisma/schema.prisma (5 line replacement)

Pattern Analysis

Does NOT correlate with:

  • User switching away from tab (tested explicitly - timeout occurred while user actively watching)
  • File size (both small and medium files affected)
  • Operation type (Edit and Bash both affected)
  • Time of day or session duration

MAY correlate with:

  • Multi-line string replacements (heredocs, large JSDoc blocks)
  • Files currently open in IDE (occurrence #3)
  • Random timing/network conditions

Impact

  • Workflow disruption: Required fallback to manual edits and user-executed commits
  • Lost context: Need to reconstruct state after failures
  • Uncertainty: Cannot predict which operations will fail
  • Workarounds needed: Breaking up large edits, having user handle commits

Suggested Investigation Areas

  1. Stream timeout settings: Are there configurable timeouts that could be adjusted?
  2. File locks: Does IDE having file open cause stream issues?
  3. Operation size limits: Is there a character/line limit that triggers closure?
  4. Network resilience: Could transient network issues cause silent stream closure?
  5. Connection pooling: Are there concurrent operation limits?

Workarounds Currently Using

  1. Provide user with exact commands to run instead of executing via Bash
  2. Break large edits into smaller chunks
  3. Ask user to close files in IDE before editing
  4. Retry operations when safe to do so

Additional Context

This occurred during productive work completing 5 GitHub issues successfully, so the overall system works well despite these intermittent failures. The unpredictability is the main issue - similar operations sometimes work, sometimes fail.

View original on GitHub ↗

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