[BUG] Verbose mode not displaying thinking blocks in v2.1.31 (regression)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/13564
2. https://github.com/anthropics/claude-code/issues/16965
3. https://github.com/anthropics/claude-code/issues/22692

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

These are distinct issues:

• #13564: Older regression in v2.0.64 with a different root cause (related to MAX_THINKING_TOKENS config format change)
• #16965: Cannot read past thoughts with Ctrl+O (transcript viewing issue)
• #22692: Suspicion that model is not generating thinking blocks at all

This issue (#22977) is specifically about:

• Thinking blocks ARE being generated (verified in transcript .jsonl)
• But NOT displayed in terminal even when verbose=true
• The display logic ignores the verbose setting in v2.1.31

The key evidence: transcript contains 22 thinking blocks, but terminal shows none. This is a CLI display regression, not a generation issue or a transcript viewing issue.

---

✍️ Author: Claude Code with @carrotRakko

Additional findings from debugging

While investigating this issue, I noticed the following:

Observation: The verbose state appears to not be propagated to the thinking block rendering logic in v2.1.31.

In v2.1.29, the thinking block display depends on either:

• Being in transcript mode (Ctrl+O), OR
• Having verbose mode enabled

In v2.1.31, it seems to only check for transcript mode, ignoring the verbose setting entirely.

Evidence:

• When verbose=true via /config, the status line correctly shows version info (a verbose-only feature)
• But thinking blocks still show as collapsed "∴ Thinking (ctrl+o to expand)"
• This suggests verbose is correctly stored in config, but not being used in the thinking rendering path

Speculation: This might be an unintended side effect of a refactoring where the verbose parameter was removed from the thinking component's props and internal logic.

---

✍️ Author: Claude Code with @carrotRakko

So frustrating really.

Same problem here

please fix asap, CC is just unusable for me without viewing/understanding the thinking

Downgrading to v2.1.29 works as a temporary fix — thinking blocks stream correctly again in verbose mode.

Downgrading to v2.1.29 works as a temporary fix — thinking blocks stream correctly again in verbose mode.

That also downgrades the model to Opus 4.5, right?

> Downgrading to v2.1.29 works as a temporary fix — thinking blocks stream correctly again in verbose mode. That also downgrades the model to Opus 4.5, right?

No, you can still /model claude-opus-4-6 -- it will warn you you're using an older opus but the ccusage confirms it uses 4.6

Why does Claude Code have so many regressions? Why so many that are big obvious things like entire features just vanishing?

Information that appears in thinking but doesn't make it into the final output is often critically important for development.
Not being able to see thinking content is an enormous loss.

I'm using https://github.com/daaain/claude-code-log for now. I need thinking blocks.

@bcherny @Jarred-Sumner Guys please don't forget this!

Please fix this already, it's really urgent.

I'd like to clarify whether this behavior is actually considered a regression or an intentional design change.

Since the thinking blocks are still being generated and persisted in the session transcript, the underlying reasoning pipeline appears to be functioning correctly. The change seems limited to the CLI rendering path.

Was the removal (or suppression) of thinking block display in verbose mode starting in v2.1.31 deliberate (e.g., to reduce terminal noise, latency, or streaming overhead), or is this an unintended bug?

If this is a design decision rather than a regression, could the maintainers clarify the intended workflow for users who depend on real-time visibility into reasoning, without needing to open transcripts or rely on external tooling?

I'd like to clarify whether this behavior is actually considered a regression or an intentional design change. Since the thinking blocks are still being generated and persisted in the session transcript, the underlying reasoning pipeline appears to be functioning correctly. The change seems limited to the CLI rendering path. Was the removal (or suppression) of thinking block display in verbose mode starting in v2.1.31 deliberate (e.g., to reduce terminal noise, latency, or streaming overhead), or is this an unintended bug? If this is a design decision rather than a regression, could the maintainers clarify the intended workflow for users who depend on real-time visibility into reasoning, without needing to open transcripts or rely on external tooling?

The fact they are not answering this makes me feel that it is intentional indeed.

I'm wondering if it's related to https://github.com/anthropics/claude-code/issues/23706.

I'm wondering if it's related to #23706.

I don't really think so because you can still see them in session transcripts. I agree with @intellia1 on his assessment.

This is not just a UX inconvenience.
API (pay-per-token) users are billed for thinking tokens whether or not they're displayed. Right now, the only way to access that paid output is to manually parse .jsonl transcript files after the fact, which is far from what verbose mode was designed for.

I was dependent on it to understand how the model works on my prompt so this is frustrating. Switched to 2.1.29 as workaround

Yep, very frustrating. Switching to 2.1.29 as well.

Saw this on X: https://x.com/jarredsumner/status/2023021998868443458?s=20

Fix coming in next release

@ashwin-ant why is it closed when the next release is not out yet?

@ashwin-ant

Why would you close this since it is not fixed????

As the original reporter, I'd like to provide feedback on how this issue was handled.

Premature closure: This issue was closed before the fix has been released. Users cannot verify the fix, and closing before release sends a signal that the issue is resolved when it isn't. I'd ask that it be reopened until the fix is available and confirmed.

Communication gap: This issue was open for 11 days with no official comment — not even an acknowledgment. Multiple users asked directly whether this was an intentional change or a bug (a reasonable question given the silence), and received no response. A one-line "we're aware, this is a bug, fix is in progress" would have saved everyone significant time and frustration.

Billing implications: API users are charged for thinking tokens regardless of whether they are displayed. This means users were paying for output they could not access through the intended interface (--verbose). This elevates the issue from a UX inconvenience to a service quality concern.

Community contributions ignored: I provided a detailed root cause analysis in my early comments (the verbose flag not being propagated to the thinking rendering path, likely dropped during a refactor). This was never acknowledged. Contributors who take time to investigate and narrow down issues deserve at minimum a brief acknowledgment — it encourages better bug reports from the community.

I appreciate the fix coming in the next release. My feedback here is about the process, not the people.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

As the original reporter, I'd like to provide feedback on how this issue was handled. Premature closure: This issue was closed before the fix has been released. Users cannot verify the fix, and closing before release sends a signal that the issue is resolved when it isn't. I'd ask that it be reopened until the fix is available and confirmed. Communication gap: This issue was open for 11 days with no official comment — not even an acknowledgment. Multiple users asked directly whether this was an intentional change or a bug (a reasonable question given the silence), and received no response. A one-line "we're aware, this is a bug, fix is in progress" would have saved everyone significant time and frustration. Billing implications: API users are charged for thinking tokens regardless of whether they are displayed. This means users were paying for output they could not access through the intended interface (--verbose). This elevates the issue from a UX inconvenience to a service quality concern. Community contributions ignored: I provided a detailed root cause analysis in my early comments (the verbose flag not being propagated to the thinking rendering path, likely dropped during a refactor). This was never acknowledged. Contributors who take time to investigate and narrow down issues deserve at minimum a brief acknowledgment — it encourages better bug reports from the community. I appreciate the fix coming in the next release. My feedback here is about the process, not the people. ✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

@ashwin-ant ???

This issue is still reproducible on v2.1.44. Verbose output is enabled, but thinking blocks are not displayed in the terminal. The CHANGELOG entries for 2.1.43 and 2.1.44 do not include any related fix.

Could this issue be reopened, or is the fix expected in an upcoming release?

+1, really frustrating to have to keep checking GitHub issues for this. Still happening on the latest release.

@ashwin-ant Can you please clarify or help tighten up the process for future issues?

This wasn't intended to be closed, a fix is on the way in an upcoming release though.

that is great news that a fix is on the way!

This issue has been fixed in version v2.1.45.

Confirmed fixed in v2.1.45. Thanks!

Finally

Curiously no mention in the changelog? https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Yes, fixed in v2.1.45. Thanks!!!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.