[BUG] Extended thinking uninterruptible - Esc and Ctrl+C don't work

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?

Bug Description

Extended thinking loop ran for ~1h 40m and could not be interrupted with Esc or Ctrl+C. During this time, Claude repeatedly displayed messages hinting that thinking would be done soon
(phrases like "getting close" or "just need a bit more time"), but this continued in a loop for the entire duration. The only way to stop it was to force-kill the entire session with
multiple Ctrl+C presses.

## Environment

• Platform: macOS 26.4.1 (Darwin kernel 25.4.0)
• Claude Code Version: CLI
• Shell: zsh
• Date: April 26, 2026

## What Happened

1. Asked Claude to solve a combinatorics problem (the football pool problem)
2. Claude entered extended thinking mode
3. Claude displayed messages indicating thinking would complete soon
4. These "almost done" messages repeated for approximately 1 hour 40 minutes
5. Pressed Esc → no effect, thinking continued
6. Pressed Ctrl+C → no effect, thinking continued
7. Had to press Ctrl+C multiple times to force-kill the entire session
8. Lost all context and work from that session

## Expected Behavior

• Esc should interrupt thinking immediately and return control
• Single Ctrl+C should interrupt thinking and return control
• If thinking will take a long time, Claude should either:
• Provide accurate time estimates, or
• Return partial results and ask to continue, or
• Recognize when no progress is being made and stop
• Users should never be locked out of control for extended periods

## Diagnostic Information

• Session ID: eda42a6e-7898-4eb6-9b87-3ad068e57456
• Last message before getting stuck: "Can you share your results so far and stop thinking? This seems to go nowhere and I have no way of understanding how much longer you will need"
• Timestamp: 1777222253197
• Session transcript available at: ~/.claude/projects/-Users-christofer-ohlsson/eda42a6e-7898-4eb6-9b87-3ad068e57456.jsonl

## Impact
This is a critical UX bug because:

• Users have no way to recover from runaway thinking
• Standard interrupt mechanisms (Esc, Ctrl+C) don't work
• Repeated "almost done" messages create false expectations and frustration
• Forces users to kill the entire session and lose work
• No visibility into actual progress or ability to get partial results

## Additional Notes
The combinatorics problem likely triggered a deep reasoning cycle that got stuck in a loop. Complex math/logic problems may be a trigger, but the control mechanisms should work
regardless of problem complexity. The repeated reassuring messages suggest the system believed it was making progress when it may have been stuck.

What Should Happen?

Two things: When Claude is hinting that it is almost done thinking, it should not keep going for another 30 or so minutes (maybe more, do not remember exactly).

And pressing ctrl+c should be able to stop the request without ending the session.

Error Messages/Logs

Steps to Reproduce

This was the prompt I used:

For the following question, I do not want you to search online for solutions. I want you to use your own powers to see if you can either solve the problem, or at least produce a novel
and interesting intermediary result. Don't be afraid to attempt techniques that are not typically associated with this problem.

The problem I am interested in is sometimes referred to as "the football pool problem". It is a combinatorical problem that I will attempt to explain from my layman's perspective:

For an alphabet of size a, we want a set of codes, each of length n, such that every codeword of length n is at most m Hamming distance away from any code in this set.

Let's focus on alphabet size 3 and length 13. Let us name the "letters" of our alphabet {0, 1, 2}. As such, a valid codeword is any string of length exactly 13, which only consists of
characters 0, 1, or 2.

Let us briefly consider the problem where m = 8. It is then trivial to see that the solution is 3. Consider this set of codes: {0000000000000, 1111111111111, 2222222222222} (13 zeroes,
13 ones, 13 twos). For 3 to indeed be the solution to the m = 8 case, two things should be true:

1. No possible codeword over this alphabet and length differs by more than 8 from any of the three supplied codes.
2. No shorter solution is possible.

The second case is trivial to show. If the size of our set of codes is smaller than the size of the alphabet, there always exists at least one option for every position in the string
that does not match one of our codes. We can thus construct a codeword that is 13 steps away from either code.

The first case is also rather easy to prove. Given that we have 13 characters over an alphabet of size 3, the most commonly chosen character from this alphabet appears at least 5 times
(3 * 4 is 12). Thus, one of the codes in our set matches in at least 5 spots (the difference is at most 8).

Now, let's focus on the case where m = 3.

I want you to attempt to find a result in the following order:

1. Establish lower and upper bounds for the answer, in lieu of finding the exact answer. I know of some previously established bounds found in the litterature, so I will know if you are

completely off base. But again, do not look for already existing proofs or bounds (other than possibly for inspiration, if you are already aware of them).

1. Find an exact answer to this case.
2. Find a general solution for all values of m, given a = 3 and n = 13.
3. Find a general solution for all values of m and n, given a = 3.
4. Find a general solution across all variables.

Clearly, things gets harder with every step. Getting to 2. would be a huge milestone. But really, we could even deem this endeavour a success if we improve some currently known bounds
on 1.

Are things clear? Remember, think and craft, do not search.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.119

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_