[FEATURE] Include context about API errors in subsequent turns so Claude knows its previous response failed.

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude's response is interrupted by an API error (e.g., 500 Internal Server Error), the user sees the error in
their terminal, but Claude receives no indication that this occurred. On the next turn, Claude only sees the
conversation history and the user's new message - with no signal that the previous response failed.

This creates confusing interactions where:

1. The user asks "why did you get a 500 error?"
2. Claude responds "I don't see any 500 error" - because it genuinely can't see it
3. The user has to explain what happened, wasting time and causing frustration

Claude appears unaware or dismissive when it's actually just blind to the failure.

Proposed Solution

When an API error interrupts Claude's response, include a system-level indicator in the next turn's context, such as:

[System: Your previous response was interrupted by an API error (500). The user may have seen a partial response
ending at: "...last visible text..."]

This would allow Claude to:

• Acknowledge the error appropriately
• Understand why the user might be confused or asking about errors
• Resume or retry the interrupted task without the user having to re-explain

Alternative Solutions

Currently, the only workaround is for the user to manually explain to Claude that an API error occurred, which:

• Wastes conversation turns
• Requires the user to understand what happened
• Creates friction in the interaction

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

1. User asks Claude to create a PR with multiple steps (commit, push, open PR)
2. Claude runs 3 parallel bash commands successfully
3. While generating the response about results, a 500 API error occurs
4. User sees: tool results followed by "API Error: 500 Internal server error"
5. User asks: "why are you getting a 500?"
6. Claude responds: "I don't see a 500 error in my output" - because it genuinely can't
7. User has to paste the error output and explain what they saw
8. With this feature, Claude would instead say: "I see my previous response was interrupted by an API error. Let me

continue with the PR creation."

Additional Context

Additional Context

This issue was encountered during a real session using Claude Code CLI (Opus 4.5). The interaction required multiple
back-and-forth messages to clarify what happened, when a simple system indicator would have allowed Claude to respond
appropriately on the first try.

This seems like a relatively small change (adding context to the next turn after a failure) that would meaningfully
improve UX when API errors occur.