[BUG] Tasks Downgrade and Terminal Crashes

Resolved 💬 3 comments Opened Feb 3, 2026 by RealSmileyGnome Closed Feb 7, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Tasks downgrade to Haiku despite Sonnet selected. Terminal crashes Windows system with high writ ration. Was working 24 hrs ago flawlessly nonstop for days. Unusable now. I removed all agents and have clean fresh claude figuring the superpowers was issue. -99% difference.

What Should Happen?

Claude should be able to write without me saying "Do NOT use Tasks." and clearing convo after every input. It should be able to do more complex tasks such as review codebase without crashing windows system (like it has before with no issues).

Error Messages/Logs

Steps to Reproduce

Claude Code: Tasks force Haiku despite Sonnet selected + Windows terminal crash

Environment

  • Claude Code version: 2.1.17
  • OS: Windows 10/11
  • Plan: Max ($200/month)
  • Model selected: claude-sonnet-4-5-20250929 (via /model)

Bug 1: Tasks/subagents always use Haiku regardless of model selection

Even after selecting Sonnet via /model, all Tasks and Explore subagents run on Haiku. This is confirmed in debug logs — Haiku appears dozens of times, Sonnet zero times:

2026-02-03T16:47:51.618Z [DEBUG] Tool search disabled for model 'claude-haiku-4-5-20251001': model does not support tool_reference blocks. This feature is only available on Claude Sonnet 4+, Opus 4+, and newer models.

This message repeats 15+ times per session. Haiku produces significantly worse code — it hallucinates attribute names, dictionary keys, and function signatures instead of reading the actual source files first.

Was working fine 24 hours ago — Tasks used Sonnet as expected on the Max plan.

Bug 2: Windows terminal crash — screen buffer explodes to 2395 rows

During Task execution on Windows, the virtual screen balloons from normal size to 2395 rows, causing 242,000+ character writes per render pass that crash the terminal:

2026-02-03T17:03:29.857Z [DEBUG] High write ratio: blit=8109, write=242341 (96.8% writes), screen=2395x120
2026-02-03T17:03:31.099Z [DEBUG] High write ratio: blit=19510, write=242300 (92.5% writes), screen=2395x120
2026-02-03T17:03:32.175Z [DEBUG] High write ratio: blit=19510, write=242300 (92.5% writes), screen=2395x120

Normal screen size is 26x120. It jumps to 2395x120 during Task execution. Session crashes or freezes every time.

Earlier in the same session, the 100% write ratio bug also appears:

2026-02-03T16:45:53.343Z [DEBUG] High write ratio: blit=0, write=1079 (100.0% writes), screen=26x120

Bug 3: Corrupted JSONL session files with null bytes

Session .jsonl files get corrupted with null bytes (\^@), causing JSON parse errors on startup:

JSON parse errors in:
- C:\Users\..\.claude\projects\c--tradingbot\be7812ac-4609-477e-b3d0-be5f34389793.jsonl
- C:\Users\..\.claude\projects\c--tradingbot\686b24c6-6ed5-4625-b6bf-cc70e467cab2.jsonl

Debug log files themselves also end with 2048+ null bytes, suggesting a systemic write corruption issue, possibly from the terminal crashes.

Bug 4: MaxFileReadTokenExceededError with no graceful fallback

2026-02-03T16:47:58.709Z [ERROR] MaxFileReadTokenExceededError: File content (31238 tokens) exceeds maximum allowed tokens (25000).

This repeats 4+ times per session. The Haiku subagents repeatedly try to read the full file instead of using offset/limit, even after the error.

Additional errors

2026-02-03T16:48:13.390Z [DEBUG] Execution timeout: 10000ms
2026-02-03T16:51:47.963Z [ERROR] Error in non-streaming fallback: Request was aborted.

Impact

  • Paying $200/month for Max plan, getting Haiku-quality output on all Tasks
  • Cannot run any complex refactoring — terminal crashes every time
  • Session files corrupt on crash, requiring manual deletion
  • Was working perfectly 24 hours ago with the same setup
  • Current workaround: /clear after every single prompt, tell Claude "Do NOT use Tasks", keep prompts very short. This is unsustainable.

Steps to reproduce

  1. Open Claude Code on Windows with Max plan
  2. Select Sonnet via /model
  3. Ask it to refactor a large file (e.g. split a 2000+ line Python file)
  4. Observe: Tasks spawn using Haiku, terminal screen explodes to 2395 rows, session crashes
  5. On restart, .jsonl files are corrupted

Expected behavior

  • Tasks should use the model selected via /model (Sonnet on Max plan)
  • Terminal should not crash during normal Task execution
  • Session files should not corrupt on crash

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v2.1.19

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

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