[FEATURE] Fullscreen TUI Ctrl+R only searches the last 100 prompts — restore classic renderer's full-history exact search

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Ctrl+R behaves very differently depending on which renderer is active, and the fullscreen version searches almost none of my history.

In the classic renderer it works the way Unix users expect: it streams the whole of ~/.claude/history.jsonl, matches on exact substring, and repeated Ctrl+R walks back to successively older matches. In the fullscreen renderer it instead preloads a fixed slice of the 100 most recent unique prompts, filters that in-memory list, and appends subsequence-fuzzy matches below the exact ones.

Two consequences, both of which cost me real time daily:

1. Almost nothing is searchable. The cap is on entry count, not time, so how far back it reaches depends entirely on how heavily you use Claude Code. Measured against my own history on v2.1.220:

| Renderer | Reach | Coverage |
| --- | --- | --- |
| Classic Ctrl+R | 305 days | 100% (5,127 unique prompts) |
| Fullscreen Ctrl+R | 22.8 hours | 2.0% |

Because the preload is keyed on search scope rather than on the query, typing never goes back to the file — I am always filtering ≤100 rows no matter what I type. Cycling scope with Ctrl+S doesn't help either: the default is already everywhere, and the cap applies to all three scopes.

2. Fuzzy matches drown out exact ones. Searching Break up cool-downs returns rows like /execute-with-angular Thoroughly and thoughtfully implement this, because the query matches as a subsequence. Exact matches do sort first, but everything below them is noise.

What makes this especially confusing is that nothing surfaces it. There is no setting or environment variable for either behavior, and the fullscreen docs don't mention that history search changes at all — so the symptom just reads as "search is broken." Since fullscreen is the default for anyone who started using Claude Code on or after May 6 2026, those users have never seen the unbounded behavior and have no reason to suspect a renderer setting is involved.

Proposed Solution

Make fullscreen Ctrl+R match the classic renderer:

1. Search all of history.jsonl, not a fixed prefix. Either drop the entry cap for the search picker, or keep a small preload for instant first paint and fall back to a full streaming scan as soon as the user types a query the preloaded slice can't satisfy.

1. Make exact substring the primary matcher and fuzzy opt-in. Exact matching is what Ctrl+R means to anyone coming from a shell. If fuzzy stays, a toggle inside the picker — alongside the existing Ctrl+S scope cycle — would be ideal, or a settings key such as historySearch.fuzzy: false.

The cost of lifting the cap appears negligible. I replicated the picker's scan in Node against my own ~9,970-line history: 31 ms to read, parse, and build the row objects for all 5,127 unique prompts, holding roughly 8.2 MB of strings — and the result is already cached per scope, so it happens once per session.

For orientation in the current build (v2.1.220, minified names): the cap is the n.size>=mHo comparison in the scoped history generator, where mHo = 100; the fuzzy fallback is the nHS(...) subsequence helper called in the picker's filter memo. Worth noting that mHo is also read by up-arrow paging and by prompt counting, so changing the comparison rather than the constant would confine the change to reverse search.

Alternative Solutions

Everything I've tried, and why each falls short:

• /tui default — restores correct search, but gives up fullscreen entirely. That's exactly the tradeoff I'm trying to avoid: I want the flicker-free renderer and working history search.
• Ctrl+S scope cycling — no help. Scopes are session / project / everywhere, the default is already everywhere, and the cap applies to all three.
• Rebinding keys — no help; the limit lives in the picker, not the binding.
• A shell helper over history.jsonl — what I use today: rg -F -i as a literal prefilter, jq to re-verify against .display, then copy the chosen prompt to the clipboard. Correct and fast (~13 ms typical), but it means leaving the TUI to do something that used to work inside it.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

A real one from today.

1. Ten months ago I worked through a set of Prisma migration errors in a different project, and I want the prompt I used, because I'm about to hit the same class of problem again.
2. I press Ctrl+R and type Prisma migration.
3. Today: no result. That prompt is from 2025-10-04, far outside the ~100-prompt window, so the picker can't see it — and nothing indicates a limit was applied. It simply looks like I never wrote it.
4. What I expect: the row 10mo ago We should resolve these Prisma migration schema issues and TypeScript…, exactly as the classic renderer returns it.
5. What I do instead: drop out to a shell and grep history.jsonl by hand.

My prompt history is one of the more valuable artifacts Claude Code produces — 305 days of accumulated, refined instructions — and right now 98% of it is unreachable from inside the app.

Additional Context

Reproducible on unmodified v2.1.220, with a synthetic history containing no personal data.

Setup: a history.jsonl with 130 generic prompts from the last two days plus one distinctive entry timestamped ~10 months back, loaded via CLAUDE_CONFIG_DIR so nothing from a real profile is involved. Searching Prisma finds the old entry in the classic renderer and finds nothing in fullscreen — same binary, same file, same query, only the renderer differs.

Minimal repro against any existing install:

1. Make sure history.jsonl holds more than 100 unique prompts newer than the one you intend to find.
2. In fullscreen, press Ctrl+R and search a distinctive string from the older prompt — no result, and no indication a limit was applied.
3. Run /tui default, press Ctrl+R, search the same string — found immediately.

Classic renderer — Ctrl+R, query Prisma: found immediately!

<img width="824" height="571" alt="Image" src="https://github.com/user-attachments/assets/64a06187-fdad-4647-90ee-70e22a13e28f" />

Fullscreen renderer — Ctrl+R, query Prisma: no result!

<img width="824" height="571" alt="Image" src="https://github.com/user-attachments/assets/7879e882-3c33-4e14-bd20-5da02b33e221" />

Verified with a controlled A/B on v2.1.220 (macOS 26.5, arm64).

To confirm the two values above are the actual cause, I changed them in a local copy of the binary and drove the real TUI over a PTY with an identical query in each case — same terminal, same history file, same query Linear, which exists in my history twice, both from 2026-04-09.

Stock:

0h   /execute-with-python Thoroughly and thoughtfully implement this
18h  /execute-with-python Thoroughly and thoughtfully implement this

Nothing older than a day, and both rows are subsequence matches rather than real ones. The April prompts are absent entirely.

With the cap comparison and the fuzzy fallback disabled:

3mo ago  Create three new user stories in Linear
3mo ago  No need to make the Linear tasks too…

Both genuine matches, no fuzzy noise. A second query for Prisma migration returned the 10-month-old row from the use case above.

To be clear, I'm not proposing binary patching as a solution — it's only how I isolated the cause. The relevant finding is that the two behaviors are independent, and each is a single-value change with no side effects I could observe.

Docs gap: https://code.claude.com/docs/en/fullscreen carefully documents what changes in fullscreen (scrollback, mouse, Ctrl+O transcript search) but never mentions history search changing. Even if the cap is intentional, documenting it would stop people concluding the feature is broken.

Environment: Claude Code v2.1.220 · macOS 26.5 (Darwin 25.5.0) · arm64 · tui: "fullscreen" · history.jsonl ≈ 9,970 entries / 5,127 unique / 305 days.

Related but distinct: #8053, #40369, #26830 request better prompt-history search in general; none mentions the renderer split or the 100-entry cap.

Thank you for your consideration!