[BUG] Automatic Interruptions

confirmed same here. just spend thousands of tokens troubleshooting this with claude to discover it was the upgrade to .78. Reversion to .77 resolved the issue.

Same problem here

Same problem here, I opened a ticket, but who knows if i will get an answer

I tried reinstall cluade
restart zhrsc
restart computer
cleanup settings
anything still getting interrupted

Thats very annoying .... one way im by passing that is CTRL C twice close the chat window session - resume the same session and say continue

anyone else could solve, its being very annoying

will 2.1.80 solve the issue?

Debug data: Interruptions happen AFTER tool completion, not during

I instrumented Claude Code with PreToolUse/PostToolUse hooks to log every
tool call start and end. Key finding: tools complete successfully, but
Claude's response generation stalls/interrupts after receiving tool
results.

### Setup

• Claude Code v2.1.80
• macOS 15.0.1 (arm64, Apple Silicon)
• 32GB RAM
• Multiple sessions running concurrently

### Hook methodology
Registered PreToolUse and PostToolUse hooks in ~/.claude/settings.json that
log timestamps, tool names, input sizes, and session IDs to a file.
A "Pre" without a matching "Post" = interrupted tool. But more importantly,
sequences where all tools complete yet the response never renders = the real
bug.

### Findings

36 tool starts, 34 tool completions — but more interruptions than 2
unmatched calls suggest.

Pattern observed:

1. Claude sends parallel Write calls → all 5 complete successfully (Pre+Post

paired)

1. Claude begins generating text response after tools →

interrupted/stalls

1. User must Ctrl+C twice, restart, and say "continue"

Example from logs:
17:02:42 | PreToolUse | Write | input_bytes=609 ← completed
17:02:42 | PostToolUse | Write ← ✓
17:02:45 | PreToolUse | Write | input_bytes=793 ← completed
17:02:45 | PostToolUse | Write ← ✓
17:02:50 | PreToolUse | Write | input_bytes=1542 ← completed
17:02:50 | PostToolUse | Write ← ✓
17:03:06 | PreToolUse | Write | input_bytes=1821 ← completed
17:03:06 | PostToolUse | Write ← ✓
-- response generation begins, then STALLS. User interrupts. --
17:03:24 | PreToolUse | Bash ← from OTHER session, no Post (also
interrupted)

### Key insight
The interruption is NOT in tool execution — it's in the response
streaming phase after tools return. This suggests the issue is in how
the client handles the API response stream after tool results are assembled
back into context, not in the tool subprocess layer.

### Reproduction

• Happens across all projects, not project-specific
• More likely with parallel tool calls or large tool outputs
• Running multiple Claude Code sessions increases frequency
• Happens on every ~2nd-3rd prompt with multi-tool workflows

### Environment

• macOS 15.0.1, Apple Silicon (arm64), 32GB RAM
• Claude Code v2.1.80
• Node v18.20.3
• Issue started ~March 18-19, 2026

I have the same issue, but traced it with Claude itself while working on Claude Code. It was confirmed that issue happens because of Claude fault. (Read below).

SSE stream closed by api.anthropic.com mid-task causing "connection interrupted" errors

Summary

Claude Code regularly interrupts mid-task with "connection was interrupted" message. After extensive debugging, the root cause is confirmed: api.anthropic.com (Cloudflare, 160.79.104.10) sends a TCP FIN (CLOSE-WAIT) to close the SSE stream while Claude Code is actively running a task — specifically during the "thinking" phase between tool calls when the stream goes quiet.

Environment

• Claude Code version: latest (as of March 2026)
• OS: Ubuntu 24 (VPS, Hostinger)
• Terminal: tmux + Mosh
• Connection: outbound HTTPS to api.anthropic.com:443, IPv4 (160.79.104.10)
• Auth: claude.ai subscription (OAuth token, not API key)

Steps to Reproduce

1. Start Claude Code on a Linux VPS
2. Give it a multi-step task involving several tool calls (file reads, bash commands)
3. Wait during a longer "thinking" pause between tool calls (~1-2 minutes of stream inactivity)
4. Claude Code prints "connection was interrupted" and stops

Evidence

Socket monitoring with ss -tnpi captured the exact moment of failure. The connection transitions to CLOSE-WAIT, which means the remote side (api.anthropic.com) sent TCP FIN — not a local timeout, not a firewall, not the OS.

=== 13:40:30 ===
ESTAB      45.93.138.237:54840 → 160.79.104.10:443   (claude fd=34)
CLOSE-WAIT 45.93.138.237:54874 → 160.79.104.10:443   (claude fd=33)  ← FIN received from server
CLOSE-WAIT 45.93.138.237:54860 → 160.79.104.10:443   (claude fd=31)  ← FIN received from server

The following was ruled out through systematic debugging:

• ❌ External signals (strace showed no SIGINT/SIGTERM/SIGHUP)
• ❌ Memory pressure (250–500MB RSS, well within limits)
• ❌ Context window exhaustion (session files ~124KB)
• ❌ Local firewall (UFW OUTPUT policy is ACCEPT)
• ❌ OS-level TCP timeout (keepalives set to 10s, VPS network confirmed clean by Hostinger)
• ❌ IPv6 instability (reproduced after forcing IPv4 via /etc/gai.conf)
• ✅ Confirmed: TCP FIN from 160.79.104.10:443 (api.anthropic.com / Cloudflare)

Expected Behavior

The SSE stream should remain open for the duration of a task. If Claude Code is actively processing (thinking between tool calls), the server should not close the connection.

Actual Behavior

Cloudflare/api.anthropic.com closes the SSE stream after a period of inactivity (no data flowing from origin to client), even when Claude Code is mid-task. This appears to be a Cloudflare idle stream timeout affecting Server-Sent Events.

Impact

• Tasks that require longer thinking pauses (multi-file analysis, complex reasoning) reliably fail
• claude --resume is the only workaround, but it also fails if the resumed task hits the same timeout
• Makes Claude Code unreliable for any non-trivial task on VPS/remote environments

Suggested Fix

• Send periodic SSE keepalive comments (: ping\n\n) from the server side every 30–60 seconds to prevent Cloudflare from treating the stream as idle
• Or increase/disable the Cloudflare idle timeout for the /v1/messages SSE endpoint

3rd day here guys, - reinstall - downgrade - nothing fixed
other then interrupted
a lot of tools got like forever running

Adding log to support evidence

ss_log.txt

Interesting pattern I discovered: tasks complete successfully when Claude asks frequent permission prompts (simple "Yes" each time), but fail with "Interrupted" on tasks where permissions are remembered ("Yes, remember for project"). The only difference is stream activity — permission prompts keep the SSE stream alive by generating bidirectional traffic. When permissions are pre-approved, Claude thinks silently for extended periods with no stream activity, and the connection dies.
This suggests the fix could be as simple as sending periodic SSE keepalive comments (: ping\n\n) from the server every 60-90 seconds during idle thinking periods, rather than letting the stream go completely silent.
Environment: Ubuntu 24.04, single Claude Code instance, IPv4 only (forced via gai.conf), tcp_keepalive_time=10. Issue started around March 13 and was not present before.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.