Fresh project sessions rapidly accumulate hidden tool-result context and then fail with ECONNRESET

Open 💬 6 comments Opened Jun 14, 2026 by RainyBlossom

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.
  • /compact also 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:

  1. A fresh session should not carry hidden state from prior sessions unless explicitly resumed.
  2. /clear should either remove enough hidden context/tool results to make the next turn safe, or clearly say what is still retained.
  3. Large Read/tool results should be summarized, capped, or excluded from future context by default unless the user explicitly opts in.
  4. The context indicator should account for persisted tool results and cache-read footprint, not just the visible conversation.
  5. If requests repeatedly fail with ECONNRESET after context growth, Claude Code should surface a context/session warning instead of retrying the same oversized request.
  6. /compact should 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:

  1. 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
``

  1. Ask Claude to inspect current changes and continue UI work.
  2. Claude runs normal tools such as git status, git diff --stat, Read src/styles/global.css, and Read src/pages/index.astro.
  3. After several tool calls, the session JSONL grows quickly, including large persisted tool-result lines.
  4. Follow-up turns begin hanging/retrying or fail with:

``text
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()
``

  1. 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
``

  1. 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 Read tool result injected into context, causing repeated ECONNRESET
  • #5674: persistent ECONNRESET reports
  • #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-persistence requests 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.

View original on GitHub ↗

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