You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched existing issues and this hasn't been reported yet
This is a single bug report (please file separate reports for different bugs)
I am using the latest version of Claude Code
What's Wrong?
Claude Code session terminates unexpectedly mid-turn with no user-facing error message. The session was in the middle of an agentic loop (multiple sequential Bash tool calls) when it silently exited. The only evidence of the failure is visible in the .jsonl transcript file, where the final entries show:
"stop_reason": "stop_sequence"
"content": "API Error: Out of memory"
No error dialog, no warning, no graceful shutdown — the session just disappears.
What Should Happen?
Claude Code should catch the API Error: Out of memory response from Bedrock and surface it to the user with a meaningful message (e.g., "The session ran out of memory — try /compact to reduce context size and resume"). Silently exiting leaves the user with no indication of what happened or how to recover.
Error Messages/Logs
# From ~/.claude/projects/<project>/0a80a98a-2efd-473d-8988-80fe42db6e92.jsonl (tail)
{"type":"assistant","message":{"role":"assistant","stop_reason":"stop_sequence","content":"API Error: Out of memory"}}
{"type":"system","subtype":"turn_duration",...}
{"type":"last-prompt",...}
{"type":"permission-mode",...}
No Stop hook fired, confirming the exit was not a clean/graceful shutdown.
Steps to Reproduce
Start a Claude Code session on AWS Bedrock with a multi-step agentic task
Run a long sequence of tool calls (15+ turns) that accumulate significant context (~280KB transcript)
Observe: session exits silently mid-turn with no error shown to the user
Check the .jsonl transcript at ~/.claude/projects/<project>/<session-id>.jsonl — the final entry will show stop_reason: stop_sequence and content: API Error: Out of memory
Claude Model
Sonnet (default) — us.anthropic.claude-sonnet-4-6
Is this a regression?
I don't know
Claude Code Version
2.1.116 (Claude Code)
Platform
AWS Bedrock
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
Session ID:0a80a98a-2efd-473d-8988-80fe42db6e92
Transcript size at exit: 284KB
Region:us-west-2
A prior session in the same project (e49fb48f) was 1.2MB and completed normally — the OOM occurred in a smaller subsequent session, suggesting it may be request-size related rather than cumulative transcript size
Session logging hooks (SessionStart / Stop) were added after this incident; the missing Stop hook entry confirmed the exit was ungraceful
Preflight Checklist
What's Wrong?
Claude Code session terminates unexpectedly mid-turn with no user-facing error message. The session was in the middle of an agentic loop (multiple sequential Bash tool calls) when it silently exited. The only evidence of the failure is visible in the
.jsonltranscript file, where the final entries show:No error dialog, no warning, no graceful shutdown — the session just disappears.
What Should Happen?
Claude Code should catch the
API Error: Out of memoryresponse from Bedrock and surface it to the user with a meaningful message (e.g., "The session ran out of memory — try/compactto reduce context size and resume"). Silently exiting leaves the user with no indication of what happened or how to recover.Error Messages/Logs
No
Stophook fired, confirming the exit was not a clean/graceful shutdown.Steps to Reproduce
.jsonltranscript at~/.claude/projects/<project>/<session-id>.jsonl— the final entry will showstop_reason: stop_sequenceandcontent: API Error: Out of memoryClaude Model
Sonnet (default) —
us.anthropic.claude-sonnet-4-6Is this a regression?
I don't know
Claude Code Version
2.1.116 (Claude Code)
Platform
AWS Bedrock
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
0a80a98a-2efd-473d-8988-80fe42db6e92us-west-2e49fb48f) was 1.2MB and completed normally — the OOM occurred in a smaller subsequent session, suggesting it may be request-size related rather than cumulative transcript sizeSessionStart/Stop) were added after this incident; the missingStophook entry confirmed the exit was ungraceful