Skip to content

[FEATURE] No indication of WHICH file for READ tool #21151

@tristananh120-web

Description

@tristananh120-web

Preflight Checklist

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

Problem Statement

Current behavior:
Read 1 file (ctrl+o to expand)

Problem:

  • No indication of WHICH file
  • User must expand every single Read to see the path
  • When hook blocks a read, user doesn't know what was blocked without expanding
  • Wastes time, breaks flow

Expected behavior:
Read: 00-project-manager\system.md
or at minimum:
Read: system.md (ctrl+o for full path)

Why this matters:

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

Same issue applies to:

  • Write tool
  • Edit tool
  • Glob tool
  • Any tool that operates on files

Proposed Solution

Suggested fix:
Show tool_name: primary_identifier in collapsed view. File path for file ops, search pattern for Grep/Glob.

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

No response

Additional Context

No response

Pinned by bcherny

Activity

binaryfire

binaryfire commented on Jan 27, 2026

@binaryfire

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

Image

2.1.19

Image
ai-is-here

ai-is-here commented on Jan 27, 2026

@ai-is-here

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.

dkampien

dkampien commented on Jan 28, 2026

@dkampien

Please change it back

etrippler

etrippler commented on Jan 28, 2026

@etrippler

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.

artnikbrothers

artnikbrothers commented on Jan 28, 2026

@artnikbrothers

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

jleppert

jleppert commented on Jan 28, 2026

@jleppert

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

amozh-op

amozh-op commented on Jan 28, 2026

@amozh-op

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.

SaitoPhoenix

SaitoPhoenix commented on Jan 29, 2026

@SaitoPhoenix

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.

bcherny

bcherny commented on Jan 29, 2026

@bcherny
Collaborator

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

67 remaining items

JohnPostlethwait

JohnPostlethwait commented on Feb 12, 2026

@JohnPostlethwait

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.

thierryzoller

thierryzoller commented on Feb 12, 2026

@thierryzoller

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.

nezza

nezza commented on Feb 12, 2026

@nezza

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

Just add a toggle please

jfbuehler

jfbuehler commented on Feb 12, 2026

@jfbuehler

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.

bcherny

bcherny commented on Feb 12, 2026

@bcherny
Collaborator

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.

bcherny

bcherny commented on Feb 12, 2026

@bcherny
Collaborator

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
kirkouimet

kirkouimet commented on Feb 12, 2026

@kirkouimet

@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.

alasano

alasano commented on Feb 12, 2026

@alasano

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.

Image

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.

norm

norm commented on Feb 12, 2026

@norm

@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?

a-connoisseur

a-connoisseur commented on Feb 12, 2026

@a-connoisseur

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.

detrimentalist

detrimentalist commented on Feb 12, 2026

@detrimentalist

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

ahachete

ahachete commented on Feb 12, 2026

@ahachete

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).

mustafaerdinc

mustafaerdinc commented on Feb 12, 2026

@mustafaerdinc

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

speeder

speeder commented on Feb 12, 2026

@speeder

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @norm@jwr@JohnPostlethwait@kirkouimet@jleppert

      Issue actions