Fresh project sessions rapidly accumulate hidden tool-result context and then fail with ECONNRESET
Preflight Checklist
- [x] I have searched existing issues for similar reports.
- [x] This is a single bug report.
- [x] I am using the latest version of Claude Code available to me.
- [x] This report does not contain private source code or secrets.
What's Wrong?
Claude Code project sessions can become unstable even when started as a fresh session. In my case, a fresh project session quickly accumulated a large hidden context/tool-result footprint and then began failing with ECONNRESET, while a minimal non-persistent Claude Code request from the same terminal/account/network succeeded immediately.
This made the failure look like a VPN/proxy/network problem, but the evidence points to Claude Code session/context handling.
Observed environment:
- Claude Code version:
2.1.177 (Claude Code) - Model: Sonnet 4.6
- OS: macOS
- Shell/terminal: zsh / Terminal.app
- Project type: frontend project with large CSS/Astro files
Minimal request succeeds from the same machine/account/proxy:
claude -p 'Reply OK' --model sonnet --effort low --no-session-persistence --output-format json
Result:
success, result: OK
duration_api_ms: ~3008
ttft_ms: ~2677
But fresh interactive project sessions fail after normal coding/tool use.
Examples from recent fresh session JSONL files:
~/.claude/projects/.../a10d6770-*.jsonl
size: 1.9MB
entries: hundreds
largest persisted user/tool-result line: ~700KB
cache_read_input_tokens later in the session: ~48k-50k
~/.claude/projects/.../ecbe50f6-*.jsonl
size: 268KB
largest persisted user/tool-result line: ~68KB
cache_read_input_tokens later in the session: ~56k-57k
~/.claude/projects/.../e0a8ebf2-*.jsonl
size: 307KB
largest persisted user/tool-result line: ~107KB
cache_read_input_tokens later in the session: ~65k-66k
Tool activity that preceded the failures included normal project operations such as:
Read src/styles/global.css
Read src/pages/index.astro
Read src/pages/theater.astro
Bash git diff --stat
Bash grep/rg style searches
The project has a large stylesheet:
src/styles/global.css: ~6,465 lines, ~149KB
src/pages/index.astro: ~1,040 lines, ~69KB
Even when I explicitly started a new project session, used /clear, and instructed Claude not to rely on old context, the session still became large quickly and hit the same failure mode.
The visible UI made this confusing:
- The user only sent a small number of prompts.
- The context/token indicator did not make it obvious that large hidden tool results were being retained.
/compactalso got stuck at 95% for ~20 minutes in a related session.- A fresh minimal non-persistent CLI request kept succeeding, so the base API/network path was healthy.
What Should Happen?
Fresh project sessions should not become unstable after ordinary tool use on moderately large source files. Claude Code should make the hidden context/tool-result footprint visible and should protect the user before sending oversized or fragile requests.
Expected behavior:
- A fresh session should not carry hidden state from prior sessions unless explicitly resumed.
/clearshould either remove enough hidden context/tool results to make the next turn safe, or clearly say what is still retained.- Large
Read/tool results should be summarized, capped, or excluded from future context by default unless the user explicitly opts in. - The context indicator should account for persisted tool results and cache-read footprint, not just the visible conversation.
- If requests repeatedly fail with
ECONNRESETafter context growth, Claude Code should surface a context/session warning instead of retrying the same oversized request. /compactshould not hang indefinitely near completion; if compaction cannot complete, it should fail with a clear recovery path.
Steps to Reproduce
This is not perfectly deterministic, but the pattern is reproducible on a frontend project with large CSS/Astro files:
- Start Claude Code in a project with a large stylesheet and page file:
``bash``
cd /path/to/frontend-project
claude --model sonnet --effort medium --no-chrome
- Ask Claude to inspect current changes and continue UI work.
- Claude runs normal tools such as
git status,git diff --stat,Read src/styles/global.css, andRead src/pages/index.astro. - After several tool calls, the session JSONL grows quickly, including large persisted tool-result lines.
- Follow-up turns begin hanging/retrying or fail with:
``textverbose: true
API Error: Unable to connect to API (ECONNRESET)
The socket connection was closed unexpectedly. For more information, pass in the second argument to fetch()``
- Run a minimal non-persistent request from the same terminal/account/network:
``bash``
claude -p 'Reply OK' --model sonnet --effort low --no-session-persistence --output-format json
- The minimal request succeeds quickly, suggesting the failure is tied to the project session/context rather than a general network outage.
Related Issues
Related but not identical:
- #68231: large
Readtool result injected into context, causing repeatedECONNRESET - #5674: persistent
ECONNRESETreports - #45224: SSE keep-alive/heartbeat during long tool execution
- #58554: JSONL/session-chain issues around
ECONNRESET
This report is broader than a single oversized Read: even fresh project sessions can quickly accumulate large hidden context/tool-result state, making normal follow-up turns fragile while minimal non-persistent requests continue to work.
Error Messages/Logs
API Error: Unable to connect to API (ECONNRESET)
The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch()
Related compact behavior:
Compacting conversation... stuck around 95% for ~20 minutes
Additional Information
From a user perspective, this is especially costly because the symptom looks like a network/VPN/proxy issue. In this case I spent significant time debugging network settings before isolating that:
- minimal
--no-session-persistencerequests work; - failures correlate with project session context growth;
- large tool results are persisted in JSONL;
- the visible message count is much smaller than the actual hidden session payload.
Please consider adding guardrails around large tool results, clearer context accounting, and a recovery hint when ECONNRESET correlates with oversized session context.
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗