[FEATURE] No indication of WHICH file for READ tool

Agreed. This "dumbing down" of tool usage output might be ok for vibe coding but it's a disaster for complex pair programing. Toggling in and out of verbose mode with Ctrl+O isn't a solution - I don't want the extra friction or the extra output that verbose mode includes. It's not just file reads - things like search patterns are hidden now too.

Issues like the one below keep happening now because I can't see what Claude is exploring or reading. In this example, it lost track track of the monorepo sub dir it was working in after compaction. With 2.1.19 and below I could tell when it's looking at the wrong files or going off course and interrupt + guide it.

It feels like they're trying to appeal to the lowest common denominator instead of serious developers. At least provide a config option to let us choose.

2.1.20

<img width="945" height="218" alt="Image" src="https://github.com/user-attachments/assets/98f188cd-3b90-416d-b0de-51cab6d64683" />

2.1.19

<img width="1773" height="1390" alt="Image" src="https://github.com/user-attachments/assets/7b01d05d-17ef-4967-80a9-f8281ccf69b6" />

Agreed. Claude code is not yet smart enough for us to not see more details on its workings. e.g. when asked to read a large file with instructions, it might decide to read 100 lines and call it a day and pretend that it's all knowing now.
Please, provide a config to restore the previous logging detail level. Current experience is pretty bad for me at least.

Please change it back

This is the first change that has seriously frustrated me as a power user. Feels like a regression and degrades my experience. Fine if this read/search groups are optional but I would personally prefer to be able to disable this so I can follow agent actions.

Bring it back please! I hate this "vibe coding" feature! We are not vibe coders!

Please at least allow us to control it! It's very frustrating and a worse user experience!

My primary use case: When Claude is exploring a codebase or gathering context, I need to see which files it's reading in real-time so I can interrupt (Ctrl+C or Escape) if it starts going in the wrong direction. For example:

• Claude might start reading files in a legacy directory I don't want it to reference
• Claude might be pulling context from test fixtures instead of actual implementation
• Claude might be reading vendored/third-party code when I want it to focus on my source code

With the current collapsed view, by the time I see "Read 15 files", Claude has already consumed context I didn't want, and I've wasted tokens and potentially received suggestions based on irrelevant code.

This a very annoying and wasteful UX change, please make it configurable or return it back to what it was.

Couldn't agree more. Complex paired development requires this. The verbose method allows me to easily surface when CC does something it shouldn't do, which triggers me to adjust behavioral instructions. Now, I just can't tell which is leading me to ask CC what it just read or searched for, and that just leads to confusion for both.

From a UI perspective, it is super clean. From a usability perspective it is a dramatically negative change. There should absolutely be an option to switch this behavior on/off.

Hey all, thanks for the feedback. This isn't a vibe coding feature, it's a way to simplify the UI so you can focus on what matters, diffs and bash/mcp outputs. Models a year ago weren't good enough for this, but with Opus 4.5 we felt this helps focus on what matters.

For folks that don't love it:

1. Try using it for a few days. We've been using this internally at Anthropic for about a month now, and found that it took people a few days to mentally switch over to the new UI. Once they did, it "clicked" and they appreciated the reduced noise and focus on the tools that actually do need their attention.
2. If you still don't like it, opt out by enabling verbose mode in /config or by passing in the --verbose flag

With all due respect I think you guys at Anthropic may be over-indexing on your own experiences working in codebases that are (likely) fresher and of course have 100% internal adoption of AI tooling. I'm working in 2 situations with claude primarily:

• At work, where I have a huge enterprise codebase that has many legacy components with similar-sounding names. Embarassing I know! Sometimes I forget to prompt that this query is related to the "new new" version of some such backend endpoint, and not merely the new one, and definitely not the original legacy version. Yes, I try to avoid these situations where possible and put notes in CLAUDE.md. But we also do not have 100% internal Claude Code adoption and guidance can be scattered. Seeing at least a high level snippet of which files are being read is quite helpful so I can tell at a glance that the agent is working in the right place and is not needlessly ingesting confusing context.

• For personal use, where I am working on side projects that are much smaller and I have a complete mental map of, so I have in my mind already what context is needed. Again - it is helpful to be able to see at a glance that, yes, Opus did in fact read the entire submodule and not just part of it, and is giving an informed answer. I have all the recommended snippets in my guidance ALWAYS read and understand relevant files ... etc in my CLAUDE.md. This does help significantly but isn't a bulletproof solution.

I find that --verbose mode is a decent stopgap, but it also includes a lot of the "noise" you're talking about and would agree is not helpful (I don't need to see 20 PostToolCall hook success lines). I just wonder if there is a middleground here more similar to codex where you can at least just see the filenames being looked at without the full path info. If you'd like to drop Opus 4.7 on us that has absoutely perfected search/read and puts an end to worrying about files and folders and such altogether, that's would be a great resolution as well :)

Hi @bcherny. I get this change might suit your workflow but it's a little patronising to tell senior devs who are spening $200/month with you what's important and what workflows they should be using. Verbose mode is NOT a viable alternative - there's way too much noise. I go into more detail here: https://github.com/anthropics/claude-code/issues/21178

I'm a framework developer. Seeing this output in real time, wihout the noise of verbose mode, is critical for how I and others here work. You mentioned it's not a vibe coding feature, but the unwillingness to consider making it configurable and saying just use verbose mode is a very "we’ll make all the decisions for you" vibe coding attitude.

You've nuked the usefulness of your CLI for some of your paying customers and now you're saying "trust me bro, our way of working is better than yours, go with it." Even though we're all clearly explaining why for our particular use cases, it's not.

I agree with all the comments made herein and that verbose isn't a legitimate solution. What is the point in the reducing the output to "Reading 3 files". Why even have the 3 in there? It's completely useless. Might as well just do away with it completely at that point, or just say "Reading files". The numbers of files means nothing if there isn't any context in _what_files are being read.

The net result is that I now trust the LLM less, not more. I wonder if it made a bad decision because it didn't read the right files. I can't properly manage the context anymore, and have to use Ctrl+O much more often now. For complex code bases, we need visibility into what the agent is doing. What files being read is important information to that end, not noise.

In addition, changes this extreme in the workflow and UI so pushed out as a minor, non-optional release are troubling for me. My first instinct is to take back control and find some other client other than claude code. This reeks of change for change sake and whoever made this decision lacks an understanding of how people actually work with claude code.

Thanks for the feedback! One thing we can start with is making verbose mode more useful and less noisy.

Landing a PR now to reduce hook output in verbose mode. What else feels noisy currently?

@bcherny May us know if there's a justification for changing it back being not the simplest and most obvious option?

For the majority of users, this change is a nice simplification that reduces noise. It's not perfect for everyone, and it's just a default, so if you don't love it, you can enable verbose mode in your /config to opt out. I want to hear folks' feedback on what's missing from verbose mode to make it the right approach h for your use case.

For the majority of users, this change is a nice simplification that reduces noise. It's not perfect for everyone, and it's just a default, so if you don't love it, you can enable verbose mode in your /config to opt out.

@bcherny Thinking and tool usage detail are completely different things. The only thing that will make verbose mode work for us is having different verbosity levels. A "Tool usage only" level that hides all thinking and just shows the tool usage detail that was removed in 2.1.20 will work.

It's not perfect for everyone

The reason logging systems have log levels is because it's impossible to use a one-size-fits-all approach for output users have to view regularly. The current verbose mode outpult is similar to DEBUG and includes everything. I'd liken showing just tool usage to an INFO level.

In most CLI tools, --verbose is for one-off debugging when something is broken. Dumping everything on screen in these situations is fine because (unlike logs) users don't interact with this output all day.

I want to hear folks' feedback on what's missing from verbose mode to make it the right approach for your use case.

I think we've already answered that question? By explaining exactly what we want to see. Thinking isn't on anyone's lists:

@jleppert said:

I agree with all the comments made herein and that verbose isn't a legitimate solution. What is the point in the reducing the output to "Reading 3 files". Why even have the 3 in there? It's completely useless. Might as well just do away with it completely at that point, or just say "Reading files". The numbers of files means nothing if there isn't any context in _what_files are being read.

@tristananh120-web said:

Why this matters: Debugging - need to see what agent tried to access Security - hook blocks should show blocked path immediately Audit trail - scrolling through conversation, can't tell what was read Multiple reads - "Read 3 files" tells me nothing

@ai-is-here said:

Claude code is not yet smart enough for us to not see more details on its workings. e.g. when asked to read a large file with instructions, it might decide to read 100 lines and call it a day and pretend that it's all knowing now. Please, provide a config to restore the previous logging detail level

@amozh-op said:

My primary use case: When Claude is exploring a codebase or gathering context, I need to see which files it's reading in real-time so I can interrupt (Ctrl+C or Escape) if it starts going in the wrong direction. For example: - Claude might start reading files in a legacy directory I don't want it to reference - Claude might be pulling context from test fixtures instead of actual implementation - Claude might be reading vendored/third-party code when I want it to focus on my source code - With the current collapsed view, by the time I see "Read 15 files", Claude has already consumed context I didn't want, and I've wasted tokens and potentially received suggestions based on irrelevant code.

@etrippler said:

Fine if this read/search groups are optional but I would personally prefer to be able to disable this so I can follow agent actions.

@SaitoPhoenix said:

Couldn't agree more. Complex paired development requires this. The verbose method allows me to easily surface when CC does something it shouldn't do, which triggers me to adjust behavioral instructions. Now, I just can't tell which is leading me to ask CC what it just read or searched for, and that just leads to confusion for both.

@norm said:

Agreed, this is awful behaviour for people who can't code (no feedback on what Claude actually does) and for those who can (now I don't trust what's happening).

@dkampien said:

BROO PLEASE CHANGE IT BACK. I need ot see what is being done to what files. Or at least have a setting for newbies.

I said:

Toggling in and out of verbose mode with Ctrl+O isn't a solution - I don't want the extra friction or the extra output that verbose mode includes. It's not just file reads - things like search patterns are hidden now too.

Someone please correct me if I'm wrong - but it's pretty clear everyone is asking to see the same logging as before _without having to see thinking_.

Just spent a few sessions using --verbose mode, I actually hadn't really tried this before now.

Liked:

• Seeing the thinking traces again.
• Seeing what prompt was supplied to subagents and their full final response. Explore agent responses are better than I thought.
• The raw "tokens" counter in the right corner. Really simple and nice, I could just get rid of some of my statusline shenanigans.
• Seeing full Bash output. Right now I'm doing a lot of data analysis and Opus is writing a lot of 5-50 line python scripts that output small tables. It's useful to be able to see what exactly the script was + the actual output of that command in the format I would have seen it in the terminal. Didn't even realize this was an option.

Disliked:

• Seeing the full filepaths for every Update/Write call. For some reason the Read mode uses the filepath from project root but these tools use the entire pwd.
• Seeing the full output of the Write tool - too verbose for verbose mode, I'll just look at it in an editor.
• Seeing every single read/tool call of the subagents - THESE could be collapsed for sure. Especially when the bash calls are already truncated to single lines.
• Seeing Hook logging - feels like debug info.
• Current vs Latest Version - feels like debug info.

Actually after doing this, my preference would be that ctrl+o simply toggles verbose mode instead of doing what it does now (not sure what it does now actually, some kind of "verbose light" mode?), seems like the true intent behind this hotkey. It would be the best of both worlds. ctrl+o also has some funny behavior right now where it truncates to too few of recent messages.

Like ideal behavior for me:

• verbose: false - leave it how it is
• verbose: true - verbose mode with removed things from my Dislike section
• ctrl+o - toggles verbose mode, truncated to natural chat boundary (compaction?), leave input available.
• ctrl+e - special screen with no input, max verbose detail on full conversation transcript

Maybe there are performance considerations. Regardless, thanks for taking the time to read the feedback.

it's a way to simplify the UI so you can focus on what matters, diffs and bash/mcp outputs

@bcherny, the problem I have is that what is being read is included in what matters to me. If I have to turn on verbose mode, that's actually worse, as now I'll see too much. I just want to see what Claude is doing as it is informative to me both for learning and for making sure Claude is not wandering down the wrong path.

I'll also echo that verbose should not be a binary state all-or-nothing.

Any update on this? How did you guys workaround this as of yet?

Any update on this? How did you guys workaround this as of yet?

use claude install 2.1.19

For the majority of users, this change is a nice simplification that reduces noise. It's not perfect for everyone, and it's just a default, so if you don't love it, you can enable verbose mode in your /config to opt out. I want to hear folks' feedback on what's missing from verbose mode to make it the right approach h for your use case.

Hey don't let the haters get to you! :)

_Cause I'm one of them._

If I was Dario Amodei I'd press the Dr. Evil button that flips your chair backwards to send you into a fiery chasm.

Offer a true option to restore this behavior beside verbose, seriously, it is a horrendous awful change.

For the majority of users, this change is a nice simplification that reduces noise

Please link all the threads about the happy people thanking you for this. Happy tweets? Happy e-mails? I'll even take vague looks of happiness that you spotted on people using 2.1.20+

I mean at this point we're doing this to help you before you end up on the front page of Hacker News for contradicting people complaining in issues and telling them you know better.

Adding my voice here - this change has been a real pain point for me. I rely heavily on seeing which files Claude is reading in real-time. It's not about micromanaging, it's about basic transparency and observability. When I'm working on a complex codebase, knowing what context Claude is pulling helps me catch mistakes early and steer the conversation.

And no, verbose mode is not a solution. It's way too noisy - I don't need to see every hook firing and all the internal chatter, I just want to see the damn file paths. That's it.

Please just give us a config flag to restore the old behavior. Something like showToolDetails: true would be perfect. Let the people who want the clean UI have it, and let the rest of us work the way we need to.

One more thing - the same issue applies to search/grep. Seeing "Searched for 1 pattern" is useless. I used to be able to see exactly what regex or keyword Claude was searching for, which was incredibly helpful for guiding it when it was looking in the wrong direction.

Now I have no idea if it's searching for the right thing until it's already done and wasted tokens on irrelevant results. The old behavior was great for observability - you could course-correct in real time instead of after the fact.

I read through everyone's feedback, and am iterating on the ux a bit more. Once we release the next version of claude code on Monday, can folks try enabling verbose mode in the /config menu and lmk what you think?

Agent observability matters for everyone, not just power users. Even if you're fully trusting Claude to drive, you need visibility into what's being loaded into the agent's context window.

The current UI is actively misleading. I just tested: running ls shows as "reading 1 file" and which shows as "Searching for 1 pattern." These are shell commands, not file reads or content searches. Mislabeling them this way misrepresents what the agent is actually doing.

If there's going to be a config option, the default should be showing individual tool calls — not hiding them. Summary mode should be opt-in, not opt-out.

@bcherny Happy to give it a go, let us know which version.

+1 — This change significantly impacts my workflow. I rely on seeing which files Claude is reading in real-time to catch when it goes off course, especially after context compaction. The old behavior gave me just enough signal to steer without needing to expand every result.

Verbose mode isn't a viable alternative — it's far too noisy. A middle-ground config option (e.g. showToolDetails: true) or verbosity levels would be ideal.

Give us the old UI back ASAP!!

Can confirm that verbose mode brings it back and does present less noisy than past versions of the mode. Feels like a bit of customisability is needed here though. Let us toggle 'read visible' and 'thinking visible'.

Please, can we have this back. I can't get used to it. Why we need this to be hidden? PLEASE bring it back or add an option to configure

Is seeing what files the agent is loading into its context really noise? It seems essential to knowing the output had the necessary context. Being prompted 5 times to hit Ctrl+O, hitting Ctrl+O and only seeing one of the files that was read, and having to then hit Ctrl+E to see the full transcript, which the application cannot handle in many cases, is noisy.

There really is no middle ground of configurability so we can at least see the relative paths of the files? There's no reason this couldn't be something that takes up 1-3 lines? 2 lines per file read plus spacing in verbose mode is still noisier than I want.

I read through everyone's feedback, and am iterating on the ux a bit more. Once we release the next version of claude code on Monday, can folks try enabling verbose mode in the /config menu and lmk what you think?

Can we just stop here and make it clear that you should drop whatever work you're doing on improving verbose mode with the goal of fixing this current issue?

Obviously you can improve it in general but if you actually read everyone's feedback here then you'll understand that the fix is very very simple -> either

1. restore the functionality like it was before or
2. give us a way to toggle it back to the way it was before

But honestly, and this is just my gut feeling combined with everyone's feedback, this change is terrible.

Just logically, why would I want an output that is sort of the same length as what was there before but now it's just useless superficial information that is the same every time.

Searched for 2 patterns, read 3 files

What am I supposed to do with this information? It has ZERO use. ZERO.

I have to put it in caps to truly get the point across that there is _literally nothing I can do with that information_

I just read it again and again as it burns away my brain cells and makes me dumber by default as I'm not getting anything out of it.

I have to refer to your earlier comment here too

For the majority of users, this change is a nice simplification that reduces noise.

How? Explain how it's a nice simplification , it's not a nice simplification it's an idiotic removal of valuable information.

How does it reduce noise? It very much only _adds noise_ and _removes signal_ . It removes something of clear value and intent and replaces it with something with ZERO value.

Is it for people scared of long strings? Not everything has to be minimalist ffs. I'm stuck on 2.1.19 because (like @artnikbrothers and many others), I absolutely cannot stand this change.

If you can logically explain how this change benefits anyone, and I mean literally any claude code user, without saying nonsense like "it's a nice simplification" that doesn't make any sense, I will hear you out. Otherwise just restore the behavior ASAP please.

@alasano I don't think this strategy is going to work to get the team to restore the functionality, it may actually push them away from doing it.

We need another strategy... (I as well am stuck on 2.1.19).

How about this, I'll Venmo or PayPal whoever merges the functionality back in $100 USD.

They are doing the swarm feature, and I see the reason they want to declutter and summarize read and search operation.

Each version has major differences in swarm feature it seems

Current I have to version installed one is the 2.1.17 stable
and the other is latest switching between to experience different thing though

I will switch to Codex if this doesn't get fixed this week.

I think my problem can be summarized as this:

If you are going to displaying something like ● Searched for 13 patterns, read 2 files

There is _nothing_ I can do with that information. You might as well not display it at all. That would certainly de-clutter things, but based on the feedback here I doubt anyone wants that.

I've meanwhile had Claude build me a UI that restores the old display through the SDK, so I suggest anyone bothered by this does that. It's only a few hours of work (for Claude) and you never have to deal with the problem again.

I've meanwhile had Claude build me a UI that restores the old display through the SDK, so I suggest anyone bothered by this does that. It's only a few hours of work (for Claude) and you never have to deal with the problem again.

I will switch to Codex if this doesn't get fixed this week.

OpenCode is worth a look. It works great with Claude Pro/Max subscription and shows command output, the names of files being read, grep / search patterns etc. Not quite as nice as Claude Code <2.1.19 but it's a lot better for my use case than the current state of verbose mode (even after the changes in the latest version). Pure tool usage info, no thinking noise mixed in.

@alasano I don't think this strategy is going to work to get the team to restore the functionality, it may actually push them away from doing it. We need another strategy... (I as well am stuck on 2.1.19). How about this, I'll Venmo or PayPal whoever merges the functionality back in $100 USD.

Hey you may be right, but if they can't listen to feedback and on top of that they make ego driven decisions to actively not fix something because someone was too direct in a github issue.. maybe they shouldn't be working at Anthropic at all.

I don't have anything against @bcherny personally (and I do apologize for any offense caused) , I'm just dumbfounded by the logic of this change and more so by not simply addressing it directly and rather looking to make verbose mode fit this use case.

Setting aside personal preference, @Aeolun also made the same purely logical point ⬇️

I think my problem can be summarized as this: If you are going to displaying something like ● Searched for 13 patterns, read 2 files There is _nothing_ I can do with that information. You might as well not display it at all. That would certainly de-clutter things, but based on the feedback here I doubt anyone wants that. I've meanwhile had Claude build me a UI that restores the old display through the SDK, so I suggest anyone bothered by this does that. It's only a few hours of work (for Claude) and you never have to deal with the problem again.

There is no value added by this change, I don't think I've seen a more obvious regression in UX than this in Claude Code. It's the kind of thing you implement with good intentions because it feels cleaner and maybe you're tired and don't think it through. But don't leave it like that once everyone points out it's bad..

This seems to be getting worse, not better. Diffs for edits to CLAUDE.md are now hidden in the latest version: https://github.com/anthropics/claude-code/issues/23176.

Not sure how the author can claim to be listening to feedback while simultaneously rolling out changes like this.

Hey all, this is now configurable. We have evolved verbose mode to give you a way to toggle file names without also enabling verbose thinking.

To use it: enable verbose mode in the /config menu, or pass in --verbose when starting Claude. You can also hit ctrl+o anytime to see even more verbose output (with thinking and hooks).

Thanks everyone for the feedback so we could get this ux right.

Going to leave this issue open for a few more days for feedback. Lmk what you think!

@binaryfire that issue is unrelated -- commenting on it directly

Hey all, this is now configurable. We have evolved verbose mode to give you a way to toggle file names without also enabling verbose thinking. To use it: enable verbose mode in the /config menu, or pass in --verbose when starting Claude. You can also hit ctrl+o anytime to see even more verbose output (with thinking and hooks). Thanks everyone for the feedback so we could get this ux right. Going to leave this issue open for a few more days for feedback. Lmk what you think!

Doesn't seem to be in the release notes for v2.1.31 but it has changed nonetheless.

1. The behavior with verbose restores showing what was read / searched for etc (as it did previously) but now with less stuff being verbose.

• However it still brings in undesired additional verbose output

e.g. in verbose mode now the entire output of things like a pre-commit hook running prettier is shown

v2.1.31
<img height="500" alt="Image" src="https://github.com/user-attachments/assets/42ff9094-6225-4565-b137-47926039d828" />

v2.1.19 correctly hides this undesired output
<img width="600" height="118" alt="Image" src="https://github.com/user-attachments/assets/a7a35ac8-93cc-4af4-8ad4-614f1e76c4c3" />

I'm not sure how many other scenarios there are where verbose will still output too much stuff.

I'm still wondering why go through this approach of modifying verbose to fit the simplification rather than providing a direct setting specifically for toggling showing file reads / searches (and the new "Read 1 memory" type output) between the aggregated "simpler" version the previous way it was displayed. And then handling verbose changes as a separate matter.

Now the people who were using verbose to see thinking + hooks have to use ctrl+o to get what they already had before by default. It just seems like doing it this way creates more issues than it solves, even though refining what verbose does specifically is a valuable task by itself.

I understand better now the bit of added value of the "simplification" you mentioned because reading 10 files will show 1 line instead of 10 in the terminal and perhaps some people who are vibe coding won't care. But still, my point about doing extensive changes to verbose mode rather than adding a toggle stands.

That's not exactly right -- under the hood we are evolving verbose mode to have more nuance to it, to support more than just two states.

Fix for a very verbose pre-tool use hook output incoming. Keep the feedback coming!

The other issue for me is that subagents (like an Explore agent) will show the entire output rather than just seeing the compacted version with what it's doing going by line by line.

@bcherny thank you for listening to feedback. I find verbose mode much more usable in v2.1.32, though I still think there is room for middle ground and making things more vertically compact without losing information.

After playing with these modes, I personally would love a way to show files read in a comma separated list. Essentially the new default mode but:

"Read file-1.ts, file-2.ts and file-3.ts, and searched for file-*.ts"

instead of

"Read 2 files, searched for 1 pattern"

I realize there are more cases to consider that complicate this but I think something along these lines is possible and a reasonable compromise.

Tangentially, I find using 'ctrl+o' annoying because often an older item in the list will say '(ctrl+o to expand)' but that message is now stale and hitting 'ctrl+o' only show the most recent buffer. It is surprising, because what the UI says can be accessed with 'ctrl+o' really needs 'ctrl+o' then 'ctrl+e'. This was true before v2.1.19 iirc but is why I am averse to that key-bind. If the buffer was a little longer or the '(ctrl+o to expand)' was more clear this would feel better.

Currently verbose mode will show entire files when Claude code is doing cat commands or git diffs. And it’s so annoying. I like how it was before – I can see what Claude code reads, which files, how many lines and that’s it. I don't need to see such things:

<img width="2316" height="1190" alt="Image" src="https://github.com/user-attachments/assets/c53b6357-8713-4a16-8572-629b0058cbc3" />

If --verbose is going to start accepting options, so we can toggle on/off the parts we want to see always vs. the parts that we want hidden by default, I'm all for it. But it's going to have to be configurable, and I am sticking with 2.1.19 for my daily usage until then.

To illustrate, the most common reason for negative feedback on the change in 2.1.20 was from people saying they want/need to see what Claude is doing. Certainly that was my problem, you changed the interface that had been stable, and one that I relied upon in order to trust Claude, without an option to change it back.

In 2.1.34, without --verbose — the first result is not helpful because I have to ^O, the second a minor problem is that it doesn't tell me I can use ^O, naively I might think it's a black box:

❯ without using a subagent, tell me how captioning a gif works
⏺ Let me read the key files involved in captioning.
⏺ Read 2 files (ctrl+o to expand)
⏺ Here's how the captioning pipeline works:
== 49 lines of explanation ==

❯ tell me how captioning a gif works
⏺ Explore(Explore GIF captioning pipeline)
⎿ Done (15 tool uses · 55.1k tokens · 56s)
== 58 lines of explanation ==

In 2.1.34, with --verbose:

❯ without using a subagent, tell me how captioning a gif works
⏺ Let me read the relevant files to understand the captioning pipeline.
⏺ Read(bin/caption)
⎿ Read 277 lines
⏺ Read(bin/make_gif)
⎿ Read 935 lines
⏺ Here's how captioning works, in two phases: 
== 37 lines of explanation ==                                                                          

❯ tell me how captioning a gif works
⏺ Explore(Explore GIF captioning system)
⎿ Prompt:
    == 72 lines later... ==
⎿ Response:
     Perfect! Now I have everything I need. Let me create a comprehensive report documenting the full caption
     pipeline.

== 262 lines of explanation ==

Three hundred lines in my terminal. Yep, that's verbose. And emphatically not what I want. I just want information. I can look up the extra stuff if I need to. I don't want to have to avoid using subagents. I want to be able to track, watch, see, follow, what Claude does. I don't want the thinking on by default, and I don't want to somehow trigger verbal diarrhoea either.

tl;dr — until there's a way to flag "show me what you're doing" without it bringing in everything else I'm sticking with 2.1.19.

I cannot add enough support to the fundamental request in this thread. I'm frankly baffled by the change in the first place, let alone these responses. The choice between a trickle or a flood of information is not a great choice. If you're really going to give me fine-grained control over the verbosity of every tool use, fine, I guess I could deal with that, but that doesn't sound like what's on offer.

@bcherny thank you for listening to feedback. I find verbose mode much more usable in v2.1.32, though I still think there is room for middle ground and making things more vertically compact without losing information.

to be fair he's only listening to the feedback concerning what _he_ wants to do (Frankenstein-ing verbose mode to fit into all complaints instead of just fixing the MUCH simpler issue).

He has in _no way_ addressed any of the feedback from the overwhelming majority of people in this thread and others saying to revert the behavior or simply offer a toggle for that specific part instead of trying to hammer the wrong puzzle piece into the puzzle.

Using versions above 2.1.19 continues to be a huge annoyance, mixing way too much verbose output in just to get the detailed file reads / searches that I had before (and to not get a generic Claude modified a memory instead of showing edits to CLAUDE.md files etc).

<img width="856" height="139" alt="Image" src="https://github.com/user-attachments/assets/4f6ffe71-6d72-4ca7-a19d-5f5c2a458716" />

Was wondering why I had the number of tokens and the current/latest version number at the bottom right now.

It's annoying cause I have that info better formatted in my status line.

Turns it's out cause I have verbose mode enabled.

Just keep removing stuff from verbose mode and we'll get there eventually, just remove all the verbose stuff until only the file reads and searches are still verbose like before and we'll be good @bcherny , what do you think?

A couple more rounds of verbose mode fixes should do it. Maybe a verbosity slider from 1 to 10 ?

If you add an entire verbose config panel allowing you to fully customize 100% of what you want verbose mode to be, I'll send you a bottle/can of the best maple syrup from Canada. That would actually be useful, I just don't want to wait months to get it when I could just get a toggle to enable detailed file reads / searches and get back what we had before.

This is so sad.

I wanted to be open about this change.
I tried your suggestion @bcherny , and gave the new approach an honest shot these last few weeks.

I still prefer the old approach.

I also tried the new verbose mode.
And its far far from ideal.
Outputting complete subagent promps is just overkill for my daily workflow.
So are the extra counters in the corner, and many other examples people have pointed out in the comments already.

At this point I can only assume it must be partly a sense of personal pride, wanting to say that you knew what customers wanted better than they do.

But in the process, you actually broke the experience for another segment too: those who like and use verbose mode the way it is.

Printing out read file names shouldnt be considered “verbose”.
Hiding all that under a generic counter that provides little value should be considered “compact” and opt-in. Or if you really feel strongly about it, make it the default, but let us opt out of it.

Please. This discussion has been dragging along for far too long.

``At this point I can only assume it must be partly a sense of personal pride, wanting to say that you knew what customers wanted better than they do.``

Well said.

We've been using this internally at Anthropic for about a month now

I guess that explains the crazy memory leaks and crashes in recent versions of Claude Code.

Please guys, remember you have customers who aren't comfortable shipping the same kind of code quality you do. To do that, we need to see what agents are doing. Without the excessive output of verbose mode.

Everyone is telling you it was perfect before. Why aren't you hearing us?

black box = bad design

It's been some time now. Still bad UX change.
And when i try doing ctrl+o to see what was read, which files and i have a few more commands after that, claude doesn't show me what's on screen but only latest ones, and suggests i open the whole history and it's a mess then.
(Yes, i have to manually see what files are being read now instead of a great previous UX)
Memory leaks take the cake though, as now i am running on the clock for each Claude session, and need to monitor ram constantly, to not get into swap. 10-20GB claude processes just because a few bash/python scripts were run and 0 garbage collection done or something.

This is the worst regression possible. Im hard stuck on 2.1.19 right now unable to upgrade because claude reads files wrong every single day and requires supervision.

Hey all, thanks for the feedback. This isn't a vibe coding feature, it's a way to simplify the UI so you can focus on what matters, diffs and bash/mcp outputs. Models a year ago weren't good enough for this, but with Opus 4.5 we felt this helps focus on what matters. For folks that don't love it: 1. Try using it for a few days. We've been using this internally at Anthropic for about a month now, and found that it took people a few days to mentally switch over to the new UI. Once they did, it "clicked" and they appreciated the reduced noise and focus on the tools that actually do need their attention. 2. If you still don't like it, opt out by enabling verbose mode in /config or by passing in the --verbose flag

You are completely wrong. Its nothing about vibe coding lol. I do very advanced sast, something no people in the world do, polyglot taint tracking across infra past boundaries... Claude reads files wrong every single day.... Every day... Multiple times per day....
Im hard stuck on 2.1.19 and you can hand wave it away saying "use verbose" but verbose is useless, have you tried it yourself? Seriously... try using verbose day to day "to track file reads" when its the most simple --flag/setting to appease users... Why do you hate us? What does it hurt anyone or the tool? Why are you obtuse for the sake of it? I dont get it...

Saying your client is "too good" for it is the worst take i have heard any developer have...shame on you man...

+1. Previously file names were shown by default, which was the right level of detail — not too noisy, not too hidden. Seeing "Read 1 file" gives me zero actionable information. I shouldn't have to expand every single tool call just to know what Claude is looking at.

Verbose mode is not a solution — it dumps too much unrelated output. All I want is the file path in the collapsed view, exactly how it worked before 2.1.20. A simple dedicated toggle (separate from verbose) would fix this for everyone without affecting users who prefer the current default.

My specific pain point: I run Claude Code on a large folder containing multiple projects. When I ask something like "check out the new deployment script for project Banana," I used to clearly see that Claude was reading the exact script I was referring to. That gave me immediate confidence that we were on the same page and talking about the same file. Without filenames, I have no idea whether Claude picked up the right file or wandered into a similarly named script in a different project. Sure, I can ask Claude to confirm what it read, but that's extra tokens and wasted time — not a real solution.

Please revert this regression. We want to know what you are reading from our systems in realtime.

Hey all, thanks for the feedback. This isn't a vibe coding feature, it's a way to simplify the UI so you can focus on what matters, diffs and bash/mcp outputs. Models a year ago weren't good enough for this, but with Opus 4.5 we felt this helps focus on what matters. For folks that don't love it: 1. Try using it for a few days. We've been using this internally at Anthropic for about a month now, and found that it took people a few days to mentally switch over to the new UI. Once they did, it "clicked" and they appreciated the reduced noise and focus on the tools that actually do need their attention. 2. If you still don't like it, opt out by enabling verbose mode in /config or by passing in the --verbose flag

If this is that actual response from Anthropic, they need to rethink who responds and how. This is beyond unacceptable.

This is effectively a bait and switch.

Please revert

Usually I don't comment on issues as it's needless spam, but you clearly haven't had enough of it yet to understand that this is what everyone wants.

I preferred the more verbose default, and hitting CTRL+o and/or enabling verbose mode is not a sufficient fix. Please restore the previous behavior.

Also, generally: please slow the rate of change. I want to learn how to use a tool, which is getting more and more difficult with the rate of change in claude-code.

Please change this back. Verbose mode is not a solution. Or give us a config option. Also, I'd suggest careful rethinking: what purpose did this change serve? Be specific, do not use terms like "cleaner", "less noise", "focus on content".

+1; at least make this a config option.

This isn't a vibe coding feature, it's a way to simplify the UI so you can focus on what matters, diffs and bash/mcp outputs. Models a year ago weren't good enough for this, but with Opus 4.5 we felt this helps focus on what matters.

Your feelings mislead you as we can see from the feedback here. They mirror the conversations I had with pretty much everyone I know who uses CC daily.

No one likes it.

Change it back please. This information is necessary to ensure it's parsing the right information and correct when it is not. Verbose mode is a non-starter.

If you have a swath of users who for some reason prefer this output and you need to accommodate them too, great, give us some config options (other than verbose) to control the output patterns/formats then. It's unclear why this has to be an one opinionated way or the other problem.

If you want to save tokens, make it per default dumb down but make it an option to enable exhaustivity for those that need it.

Complete regression. Can't tell when it goes down the wrong rabbit-hole anymore.

Just add a toggle please

Usually I don't comment on issues as it's needless spam, but you clearly haven't had enough of it yet to understand that this is what everyone wants.

Typically this is me too, but, I feel like I haven't read my particular use case in the comments yet. I write a lot of typescript scripts and used to enjoy having Claude run them for me (as the output from the script was then automatically provided to Claude for analysis). This is totally busted with verbose mode enabled, because the output dumps into the main Claude console and destroys the performance (see people's earlier comments about Claude processes hogging many GBs of memory). This goes for any kind of long running, output generating bash command.

Sadly, you can't even background the script as a workaround, because by default whenever Claude's background tasks finish in verbose mode, they also dump the entirety of their output into the console, further destroying Claude's performance. We're not even talking more than 50,000 lines either... anything near 100k is enough to fully tank your session, so badly that you have to fully abandon your context, kill the process, and start fresh (no continue).

This use case used to work fine pre 2.1.20, as the output of any long running Bash command Claude was nicely truncated to the top 5-10 lines and shown to the user. So you could easily monitor the output of your command, while getting the benefits of having Claude run it. Now the only workaround is not to do that, with the worst case being totally lagging your shell / system / losing 20 minutes of time rebuilding context again. A pointless regression of great features IMO.

One more fix incoming for subagent output in verbose mode -- almost there. Please keep the feedback coming, we want to hear it and will continue to iterate.

For folks in this thread: we hear you. This is now behind a toggle, as requested. We have repurposed the existing verbose mode setting for this.

• /config > verbose or --verbose: shows file paths for reads/searches. Does not show full thinking, hook output, or subagent output (coming in tomorrow's release)
• ctrl+o: shows full output

@bcherny this is epic. We are all super excited for it.

Just to call out - Claude Code and the underlying models are my favorite software I have used in my entire life of using computers, starting from 13 years old to now 41.

Thank you for making something so magical.

For folks in this thread: we hear you. This is now behind a toggle, as requested. We have repurposed the existing verbose mode setting for this. /config > verbose or --verbose: shows file paths for reads/searches. Does not show full thinking, hook output, or subagent output (coming in tomorrow's release) ctrl+o: shows full output

For me this will probably work but now the people who liked how verbose mode worked before are the ones who are going to complain.

• Switching between file paths for reads/searches and the aggregated "Read x files" ---> should be a toggle by itself

• Show thinking (outside of verbose mode and now ctrl+o) ---> should be a toggle by itself
• Show hook output ---> should be a toggle by itself
• Show subagent output ---> should be a toggle by itself
• Any other detailed output showing without verbose mode --> should be a toggle by itself

And then verbose mode could just show everything all at once. You've reduced verbose mode to what was just the normal behavior pre-2.20.0.

And it only took the a post with 740+ upvotes and 500+ comments on hacker news to make you do _more verbose mode changes_ instead of just adding a toggle for this very specific feature.

I mean at this point we're doing this to help you before you end up on the front page of Hacker News for contradicting people complaining in issues and telling them you know better.

<img width="400" alt="Image" src="https://github.com/user-attachments/assets/80e3d440-12ff-476d-8589-ce2b0b6626ab" />

And now everyone in the HN thread is telling you to stop talking about verbose mode.. never seen anything like this.

I'll go apply at Anthropic, fix this and resign. If I get hired as your manager, I have some bad news for you though lol.

@bcherny I'm glad to hear you've accepted that you will be providing proper support for those of us who want more granular feedback from Claude. I was very worried I'd be stuck on 2.1.19 forever, or looking to switch to a new coding REPL.

That said, I would like to give you a piece of advice you can freely ignore.

This is now behind a toggle, as requested. We have repurposed the existing verbose mode setting for this.

This is arse backwards. As has been pointed out, by doing that you satisfy those of us who want the old semi verbose behaviour and screw over anyone who does actually want --verbose to work. Do you have an internal OKR of "updates pushed per week" you need to satisfy? Have you considered that the response to this should perhaps not be to churn out even more behaviour breaking changes in quick succession, but to stop, design a proper method of controlling the output, ask for feedback, then implement it?

Please no more verbose mode changes! It makes both people who did and didn't use verbose mode unhappy!

This is exactly what we need (just like alasano said):

Switching between file paths for reads/searches and the aggregated "Read x files" ---> should be a toggle by itself Show thinking (outside of verbose mode and now ctrl+o) ---> should be a toggle by itself Show hook output ---> should be a toggle by itself Show subagent output ---> should be a toggle by itself Any other detailed output showing without verbose mode --> should be a toggle by itself

A staggering amount of people have asked to stop with verbose mode changes, so whoever at Anthropic is pushing for it regardless, please reconsider. I understand Boris might not have the final say on this, but something he said earlier in this thread doesn't sit right with me:

Try using it for a few days. We've been using this internally at Anthropic for about a month now, and found that it took people a few days to mentally switch over to the new UI. Once they did, it "clicked" and they appreciated the reduced noise and focus on the tools that actually do need their attention.

This is a developer tool used by many, many people around the world. Just because some people at Anthropic like to use it a certain way, it does not make sense to force all the hundreds of thousands of people around the world to also use it that way.
We're all developers using this and we're all different people with different requirements and preferences. Please let us use our tools the way we want to use them!

---

We just want two things:
1) No changes to how things have worked unless it really is unavoidable. People develop habits and muscle memory, and forcing them to give those up without a good reason is a great way to make many unhappy.

2) If people at Anthropic or other users want a change in how things are displayed or how someone interacts with Claude Code, it should be added as a config option. We're all developers here, no one minds more config options.

The idea that this somehow reduces noise is wrong. The change takes useful information and turns it into noise.

I as a developer want to know what the tool is doing. Please add this back, with or without toggle. Verbose mode is not a solution for this.

If not, remove the output entirely. That CC reads files without knowing which ones is as useful as the void. (And no, I cannot vouch for this).

Revert back this feature. Not knowing what Claude is doing is not a good idea!

I was practicing using Claude Code outside work hours but using my work account (with my boss permission) to create some scripts to parse game files, nothing important.

But Claude Code is hell buggy, despite me telling it multiple times the same info, putting on CLAUDE.md and so on, it keeps forgetting basic things and reading a ton of huge files that it shouldn't read, to look for information it already have. So I started to keep an eye on the filenames to abort in a hurry whenever Claude Code is about to waste tons of my boss cash on useless stuff.

Now with this feature, I can't do that, and indeed it is a feature from Anthropic point of view, after all it is great in burning my boss cash and making Anthropic richer.

bumping until someone listens

This is such a no brainer... why are they even fighting this??
its a developer tool... hello?
of course we need, want and should be able to see what the freaking files being read are....

@bcherny we want a super verbose toggle <3

As a developer, it’s important for me to have clear visibility into what the tool is doing behind the scenes. Understanding its internal actions, decision-making process, and intermediate steps is essential for debugging, validation, optimization, and building trust.

Simply relying on verbose mode is not an adequate solution, as verbosity does not necessarily provide the specific operational insight required.

@bcherny After a week on verbose mode, here's what I've found:

What works: File paths for reads/searches are available — great for daily work.

What doesn't: Verbose mode still dumps full output for things like git diff or script outputs, which does not make any sense and is too much for a normal daily software development workflow.

But more importantly, I've discovered a use case that the current model doesn't serve at all: debugging subagents.
When you maintain shared AI configurations (skills, subagent prompts, CLAUDE.md instructions) for a team, in order to tune subagent config you need to see full subagent behavior - their prompts, tool calls, and responses. This is especially true with parallel subagents where you need to trace which one went off track. The subagent output is hidden now in verbose mode and to see it I need to use Ctrl+O, but it shows a "frozen" snapshot of the output which is useless because i need to see the process in realtime.

This points to three distinct levels that shouldn't be conflated:

1. Compact (current default) — "Read 3 files". Fine for vibe coding.
2. Standard (pre-2.1.20 behavior) — File paths, search patterns, truncated bash output. No thinking, no hooks, no subagent internals. This is what most people in this thread are asking for.
3. Debug/Verbose — Everything: full subagent output, complete bash results, hooks. For people maintaining AI tooling configurations and diagnosing issues.

The current approach keeps trying to make one "verbose" toggle serve both level 2 and level 3 users, which is why every iteration fixes one group's problem while breaking another's. These are fundamentally different needs and should be separate settings.

Try using it for a few days.

This is NEVER the correct way to respond to a GitHub issue. If someone is posting, they're going to the trouble because they've encountered a problem that's impacting their work or workflow.

That's all I wanted to say.

> Try using it for a few days. This is NEVER the correct way to respond to a GitHub issue. If someone is posting, they're going to the trouble because they've encountered a problem that's impacting their work or workflow. That's all I wanted to say.

Its also extremely arrogant and obtuse for the sake of it... Telling developers their way is the only right way and we are just stupid for not seeing the light.... Over what? Asking to see what files their client that is a capable toddler at best?
Its pathetically bad take from him.... Any company....

Just installed Typescript LSP plugin - Another thing (on the very long list of things) that now needs to be removed from being expanded in verbose mode to get back the behaviour we had before.

How much more neutered does verbose mode have to get.

Hopefully the fact that you didn't release the new updates that were promised means you're reworking everything, hopefully correctly this time by adding toggles for everything explicitly.

<img height="440" alt="Image" src="https://github.com/user-attachments/assets/6eaac40e-a952-4d1c-b50c-60b0c01bcc59" />

I want to know what's going on, I have many times hit escape to correct the model to focus on the correct files as an example. Large complex projects will end up with situations where tokens are being wasted. I guess internals does not care about this if deadlines and token limitations might not be their main focus? @bcherny

I beg you to revert this.

"Try using it for a few days."

We could not simply try though, could we? We were, instead, forced-- unless we abandon use-- to do so. A "try" would require a choice, which should always be the default, if a change is to be made at all. Especially for something that pertains to transparency, observability, or interpretability, Silent-- and now, stubborn-- increase of opacity should never be the default in a company that wants to pride itself on being the safer option.

For folks in this thread: we hear you. This is now behind a toggle, as requested. We have repurposed the existing verbose mode setting for this. /config > verbose or --verbose: shows file paths for reads/searches. Does not show full thinking, hook output, or subagent output (coming in tomorrow's release) ctrl+o: shows full output

this is now what we want! We just need to get back the UX with reading/searching commands! Just give us a toggle, to bring it back without verbose mode. The reason I like Claude Code because it had a great UX from the beginning (thanks to @bcherny) but I'm afraid of changes like this. Why changing something what is already proven to be good?

Please don't take away features. Want to add a less verbose option? Fine. Make it an OPTION. Even make it the default option if you really think it is "better" for developers. And dont take away the full-verbose option from those who like the extra detail. Verbosity could be in multiple levels - Minimal, Standard, Verbose (or whatever words/levels to use, the labels are unimportant.)

I cannot count the number of times I have stopped Claude when it has been going down the wrong path (either due to its own fault or because I realized I gave it incorrect or incomplete prompts.) Being able to see what Claude is doing as it is doing it is necessary for efficient use of the tool. Hiding that information adds no value to the user (and any value it adds to Anthropic is at the user's expense - don't be evil!)

I'm really disappointed in Anthropic at how this issue is being handled

\>thing A works fine
\>thing A gets changed to not work fine by default
\>users are mad, create an issue
\>users get told to give it a try, maybe they'll grow on it
\>users still don't like it
\>thing B that also used to work fine is sabotaged to make thing A work somewhat like it used to
\>users of thing A don't like it
\>users of thing B don't like that thing B got sabotaged to fix thing A
\>in the end thing A and B are still both broken for multiple weeks
\>no responses, no transparency, promises that aren't followed up

What's to stop them from releasing another change on a random Tuesday that breaks all of our workflows and gives us no option to revert, and just ignore whatever people have to say about it?

I don't understand this sudden user-hostile trust-eroding behavior for an otherwise great tool

in case anybody is interested, Claude made me a patch to restore the tool visibility, it just replaces a single w with !0 in one line of the minified cli.js and then it works.

https://github.com/aleks-apostle/claude-code-patches/pull/12

I'll try to keep it updated (like I do with the inline thinking visibility patch https://github.com/aleks-apostle/claude-code-patches/pull/9) since it doesn't cost me much (Claude made its own skill to do that on its own every time a new claude is released).

Try using it for a few days. We've been using this internally at Anthropic for about a month now, and found that it took people a few days to mentally switch over to the new UI. Once they did, it "clicked" and they appreciated the reduced noise and focus on the tools that actually do need their attention.

If the engineers at Anthropic love this change, then surely every software engineer on the planet will too.

For those who care about what Claude Code is doing behind the scenes, you can try claude-devtools. It’s a great way to see exactly what actions it’s taking instead of guessing.

Since we're likely not getting independent toggles anytime soon (or maybe ever), I've taken some reference from here and created an easy-to-use patched version of Claude Code that:

1) Shows thinking inline (without verbose mode)
2) Shows files read / patterns searched / ... inline (without verbose mode)

You can find it at: https://github.com/a-connoisseur/patch-claude-code

The patch script is in the repo, so you can either clone the repo and run it yourself, or fork the repo and run the actions in case I am unable to keep the releases up-to-date. The script should work with future releases as well unless they fundamentally change how that part works.

From the 2.1.45 release notes:

• Improved collapsed read/search groups to show the current file

or search pattern being processed beneath the summary line while
active

3 weeks and 100 replies later, but we did it 🤟

3 weeks and 100 replies later, but we did it 🤟

but it's only while active, so you need to catch CC in the act of reading.. otherwise it's back to hidden and ctrl+o.
Sad.

Yea you're right. It's still an overall regression, but a going in the right direction.

A bit extreme perhaps, but another workaround in addition to the custom patches the others have mentioned is to buy a mouse with 2 extra utility buttons, and map those to Ctrl + O and Ctrl + E.

I have a Razer Cobra, and to be honest I don't feel this change as painful as I used to since then.
Have it on the mouse means I can just tap on the terminal tab Im interested in, expand the details, and scroll up to see what was read.

Landed one more improvement, when not using verbose mode. Curious what everyone thinks -- keep the feedback coming!

@bcherny It's not an improvement? It's less of a regression, but it still a regression over 2.1.19.

When using Claude, I want to see what it does, in terms of commands run, and files read. I want the option to see more detail with regards to thinking, agents, etc. I do not consider "files read" to be that extra detail, it is core. For that information to not be on screen means you have not done what we have requested.

And given @anthrotype claims it is a TWO CHARACTER change, at this point it feels like you are deliberately not giving us what we have asked for, when a number of people have explained plainly as to why we feel we want it, and some require it.

Please, for the love of Pete, either with an environment variable and/or a config setting (if you are completely unwilling to just roll back the changes) let us have the old behaviour of just seeing what it does when it reads files. Or just tell us "tough" and stick to your guns. This half-way house where you say you want feedback and then plain and simple ignore the actual feedback is frankly insulting.

Have you seen the latest version (2.1.47)? It does exactly that -- it shows you file names and patterns.

I want feedback because we are actively tuning this UI to make it work well for this group. I think we're close, and don't want to settle for a poor ux.

@bcherny Yes, immediately, because I do want to take advantage of other changes that have landed since 2.1.19. And no, it doesn't. Not unless I watch it like a hawk.

❯ tell me about the wiki formatting outstanding                                                                         
                                                                                                                        
⏺ Read 1 file (ctrl+o to expand)                                                                                        
                                                                                                                        
⏺ The outstanding wiki formatting tasks are all about supporting Obsidian-flavoured Markdown features, since the wiki is
   intended to eventually sync with Obsidian. Here's what's left:                                                       

If I issue an instruction, do something else, and come back, there it is not showing me filenames and patterns.

I want feedback because we are actively tuning this UI to make it work well for this group.

Put it back. That's what would work well for this group. Behind an option, behind an env var, or as the default, I don't care HOW. But if you continue to hide the information, it does not work well.

It feels like we are in a support ticket thread. Oh wait.

tl;dr: we want to see which files were read by Claude and how many lines(if it was not read in full) in the interface as before, without it only being shown during the reading itself or requiring key presses or behind full on verbosity ON. We are fine with it being behind a feature flag or anything else, just to have it as before the "improvement".

And no, adding a time.sleep(2) during reads to UX so we can catch it in the act more frequently and see what files were read is not an improvement of our UX if you decide to do it. Please, don't.
Weird that i feel like i need to provide more details to avoid perverse instantiation here.

Verbose toggle shows thinking. So this is not the toggle for us.
2.1.47

<img width="1081" height="495" alt="Image" src="https://github.com/user-attachments/assets/ad460956-9896-4199-a936-1aa8676b2818" />

Landed one more improvement, when not using verbose mode. Curious what everyone thinks -- keep the feedback coming!

We already gave you the feedback, you just don't listen.

Too busy doing interviews as the genius creator of Claude code, meanwhile you don't get it when articles about your poor decisions and this exact thread reach the top of Hacker News with 1000+ upvotes.

1000 comments on hacker news with 99% saying this is a shit UX and you keep just keep on going on about verbose mode.

How many more times does someone have to say "just give us a toggle to enable detailed file reads / searches" until you get it?

Hey at least my Claude instance was only using 54 GB of RAM yesterday. Not sure if it's cause I have verbose mode toggled on though.

Have you seen the latest version (2.1.47)? It does exactly that -- it shows you file names and patterns. I want feedback because we are actively tuning this UI to make it work well for this group. I think we're close, and don't want to settle for a poor ux.

For me? Its a step in the right direction but im still not satisifed...
The issues i have?
If it reads 3 files? It only shows the file reads in succession, so the first 2? you can barley see unless you are glued to the terminal.
The last file is only shown for the duration of the file read before it goes back to the same behavior of showing "Read x files".

I would like to see the "read tree" fully expanded at all times. I regularly work in 5+ terminals, i dont have the luxury to sit glued to every terminal and every output in a race to see what was read or done... I want the ability to scroll up and instantly see what files were read"...

To summarize:
Expand the "read file tree" and make it permanently visible. Do that and im sure you will make 90% of users happy, including myself.

The last update is great in spirit but fundamentally identical in execution.

From the 2.1.45 release notes: > • Improved collapsed read/search groups to show the current file > or search pattern being processed beneath the summary line while > active 3 weeks and 100 replies later, but we did it 🤟

See my reply above. Its functionally identical... Its just a very poor bone thrown at us...
Even if it reads 1 file (which doesnt even take seconds)? It will end the display on "Read 1 file"...
And if it reads 3 files? you wont even see it either...

So its just them pretending to do something but functionally identical.

Have you seen the latest version (2.1.47)? It does exactly that -- it shows you file names and patterns. I want feedback because we are actively tuning this UI to make it work well for this group. I think we're close, and don't want to settle for a poor ux.

I get it... You are in a lose lose ego situation where you painted yourself into a corner... It sucks... It stings...
But put your ego aside for a moment and realize this is one of the times you need and should just admit "We were wrong", you dont even have to frame it that way publicly, you just have to do...... And give the users exactly what they are asking for...
Its the most sane and reasonable request in developing history... Asking to see what files your AI is reading lol.... hello?

There is no scenario where you can win this battle, you are going to die on this hill if you continue.... You can still appear reasonable, you can still give the users what they want, you can still show your users and the overall industry that there is still companies listening to feedback and in a week or two? Nobody will remember this...

But keep doubling down like this? Its just going to be worse, the corner will just get smaller and yeh... Up to you...

Why.. even in active state.. that was supposed to be half fix for us, we still do not get a good thing?
Screenshot 1 - information visible during reading
Screenshot 2 - information visible during reading with ctrl+o

<img width="988" height="233" alt="Image" src="https://github.com/user-attachments/assets/e8e2ca94-5265-47bf-8a3d-bc10f4cf28fd" />

<img width="969" height="273" alt="Image" src="https://github.com/user-attachments/assets/8adb2781-5f9e-46c9-8b66-8bff97405a51" />

P. S. As i said before, this is not what we want, and even this doesn't work as good as before.

@bcherny You asked for feedback on 2.1.47, and we responded. Claude is now on 2.1.62. You have not responded since.

I would like to know where I stand. Am I stuck on 2.1.19 for the rest of time, or stuck turning on verbose and being bombarded with other stuff I don't want only to get the very small pieces of information I do want?

If the answer is you're not going to listen to us any further, please tell us that. If the answer is you're still working on it but it'll take more time to update, please tell us that.

Because silence feels like a middle finger.

He dont care. He thinks he knows better than us and his way is superior but
to weak to admit it openly.

On Fri, Feb 27, 2026, 22:50 Mark Norman Francis @.***>
wrote:

norm left a comment (anthropics/claude-code#21151) <https://github.com/anthropics/claude-code/issues/21151#issuecomment-3973674056> @bcherny <https://github.com/bcherny> You asked for feedback on 2.1.47, and we responded. Claude is now on 2.1.62. You have not responded since. I would like to know where I stand. Am I stuck on 2.1.19 for the rest of time, or stuck turning on verbose and being bombarded with other stuff I don't want only to get the very small pieces of information I do want? If the answer is you're not going to listen to us any further, please tell us that. If the answer is you're still working on it but it'll take more time to update, please tell us that. Because silence feels like a middle finger. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/21151#issuecomment-3973674056>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BWRY5QIH74RM7VULQJVX7PD4OBRUTAVCNFSM6AAAAACS7PGDIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZTGY3TIMBVGY> . You are receiving this because you commented.Message ID: @.***>

Even worse regressions in .63 lol... It now truncates file reads so you have engineered silent dataloss and context corruption directly into the client...as a...feature??... thats an impressive...feat? Can you guys stop vibe coding please?? @bcherny
How can you be this bad? Seriously???????
And you have the audacity to tell all of us to "learn your superior workflow"... yeh, maybe learn to make your client not suck first?

"● Let me read all three files.

● Read 3 files (ctrl+o to expand)

● The rules_sop.md was truncated. Let me read the full saved output.

● Read 2 files (ctrl+o to expand)

@TheAuditorTool I've learned that the real solution is to embrace pi.dev (and switch to codex as the model)

It's amazing tbh, you can fully customize every single part of the experience, it starts out barebones with all permissions and you just ask the agent to create extensions.

sticking with claude code is just sinking deeper and deeper into the tar pit of opinionated setups.. but it's not your opinion.

I get it, Boris has to build a tool that works for everyone and that's a challenge, you can't please everyone.

For this particular issue I think he's gone completely mad and just keeps making bad decisions but I mean in general, it's not easy to please everyone.

So yeah, switch to pi.dev and remain free of the shackles of any single CLI built by the big players, they'll never be perfect for you.

Just be careful using the login for your Claude MAX account cause Anthropic ban people for that apparently, OpenAI encourages it though.

I set this up the first day in like 30 minutes of playing around, fully custom. (that's an ASCII mouse that follows the text as I type btw, for no other reason than I can do whatever the fuck I want)
<img width="1050" height="169" alt="Image" src="https://github.com/user-attachments/assets/e616d9ac-e8a2-4f8c-af38-0e060096067e" />

Why it so complicated to add an option to configure the way it was before!!!?? Just tell Claude code to do it. Please bring the old UX back!

● Now I need the full SOP (it was truncated) and to understand the actual database schema for the test project generating these false positives.
● Reading 2 files… (ctrl+o to expand)

Yes every time i ask it to read a file... it has to do it twice... and i also cant track what files it reads...
How can you make a client that sucks this much and then be proud and obtuse about it??? @bcherny

Why it so complicated to add an option to configure the way it was before!!!?? Just tell Claude code to do it. Please bring the old UX back!

Its not a technical thing... @bcherny have clearly fallen victim to llm hyping him up as gods gift to earth and everyone just needs to understand the right way and the light.... Its couple lines of code to add...
its ego... its all 100% ego... for no reason... this is the most retarded thing i have ever encountered in my professional "IT/Dev" career the past 25 years... not even joking...

@bcherny 2.1.20 was the version that started this thread. After several back-and-forths you asked for feedback on 2.1.47, and we responded. Claude is now on 2.1.76. No-one from Anthropic has responded since. Are we to believe that you didn't actually want our feedback?

If anyone else is tired of waiting for an official update, I've been using @a-connoisseur's workaround (patch-claude-code) and it works perfectly

@bcherny I tried .68 and .74... They are still fairly useless... but a far bigger issue?
You have added some "memory", this memory hard code files that "it should read".... so even when you tell it to read a specific file? IT checks its retarded memory first and goes "ohh, it must be this file, let me read a completely different file"....

Seriously, what are you even doing at anthropic? Is claude code writing the entire thing by himself? Are you being kept hostage?
How can someone developing, a developer tool be this fking obtuse about it?? its unreal... muppet...

@bcherny

<img width="621" height="99" alt="Image" src="https://github.com/user-attachments/assets/f5c207c5-4678-481e-82f4-d7e00235ba4e" />

This is what i mean... Ok?? Its a fresh prompt... Version .76

You can even see it SEARCHING, still ending up searching AND picking the wrong file... like? How much vibe coded slop is in here?

<img width="674" height="260" alt="Image" src="https://github.com/user-attachments/assets/fed658a4-de90-4273-8588-b329bda8440d" />

And this is what you want us to trust? Not showing what file it reads? In a developer tool? When it consistently does it wrong?
Ok? What is the logic? Please educate us...

Welp, good to know the respect Anthropic have for their paying customers I guess.

Pretty sure after this thread, anthropic employees will never respond to github issues again lol

/tmp/gh-comment-21151.md

I guess we can fix this ourselves now
https://github.com/instructkr/claude-code

@bcherny The community has spent the past year practically begging for transparency on how the client reads files and handles tasks, and the constant pushback never made sense from an architectural standpoint.

However, after reviewing the recent 2.x.x source map leak, the context of those limitations suddenly makes perfect sense. The community assumed the client was struggling with complex context windows, but the codebase reveals engineering bandwidth was instead being spent on a deterministic mulberry32 PRNG for an RPG Tamagotchi system (src/buddy/), complete with RARITY_WEIGHTS and a CHAOS stat.

We also see why the client struggles to follow instructions: the system prompts (prompt.ts) literally have to beg the LLM to ignore the Tamagotchi ("You're not [name]... stay out of the way"), and CI/CD security scanners were bypassed using Hex-encoding (types.ts) just to ship the pet's name.

It is incredibly frustrating for users who rely on this tool for production workflows to see that core file-reading functionality was sidelined for an April Fools' virtual pet. Occam's razor applies here: the architecture isn't struggling with files; it's just completely misaligned.

@bcherny The more i look at your, i dont have anything nice to say really but "mess" of a codebase... It makes total sense why i've been having all of my issues... The model isnt dumb... but the client is retarded, lazy and path of least resistance "save tokens at all" costs... thats why it hallucinates file names, thats why the memory feature sucks and it cant distinguish between similarly named files... because you engineered literal hallucination into the client as a feature... while screaming at us "to just trust the new workflow, you dont need to see what files it reads"... yeh, ofcourse, because you know it sucks and you want to hide it....

Do better bro....

I really doubt cussing at the Anthropic people is going to help, let's stop doing that

I really doubt cussing at the Anthropic people is going to help, let's stop doing that

I didnt cuss them out? If so we have very different takes on that... In any regards? I agree nothing said by users is going to help because they dont care and they are incompetent. And it feels good knowing and saying it after having reviewed the source code of the client.

SMH and rolling my eyes
<img width="1176" height="384" alt="Image" src="https://github.com/user-attachments/assets/7df0d293-163e-4b61-a4e2-29b732a70c51" />

Tamagochi is cute though

<img width="503" height="512" alt="Image" src="https://github.com/user-attachments/assets/0c6b7b3c-eb8c-4a65-8067-7d487cac4717" />

+1 — When Claude says "I've written this file" or "take a look at this", there's no easy way to actually see or open the file from the terminal. I end up scrolling back through the output trying to find the file path, then manually opening it.

In VS Code's terminal mode this is especially frustrating because the file is right there in my editor — I just need Claude to tell me clearly which one it touched.