[steinnes]

I can’t count how many times I benefitted from seeing the files Claude was reading, to understand how I could interrupt and give it a little more context… saving thousands of tokens and sparing the context window. I must be in the minority of users who preferred seeing the actual files. I love claude code, but some of the recent updates seem like they’re making it harder for me to see what’s happening.. I agree with the author that verbose mode isn’t the answer. Seems to me this should be configurable

[bcherny]

I think folks might be crossing wires a bit. To make it so you can see full file paths, we repurposed verbose mode to enable the old explicit file output, while hiding more details behind ctrl+o. In effect, we've evolved verbose mode to be multi-state, so that it lets you toggle back to the old behavior while giving you a way to see even more verbose output, while still defaulting everyone else to the condensed view. I hope this solves everyones' needs, while also avoiding overly-specific settings (we wanted to reuse verbose mode for this so it is forwards-compatible going fwd).

To try it: /config > verbose, or --verbose.

Please keep the feedback coming. If there is anything else we can do to adjust verbose mode to do what you want, I'd love to hear.

[btown]

I'll add a counterpoint that in many situations (especially monorepos for complex businesses), it's easy for any LLM to go down rabbit holes. Files containing the word "payment" or "onboarding" might be for entirely different DDD domains than the one relevant to the problem. As a CTO touching all sorts of surfaces, I see this problem at least once a day, entirely driven by trying to move too fast with my prompts.

And so the very first thing that the LLM does when planning, namely choosing which files to read, are a key point for manual intervention to ensure that the correct domain or business concept is being analyzed.

Speaking personally: Once I know that Claude is looking in the right place, I'm on to the next task - often an entirely different Claude session. But those critical first few seconds, to verify that it's looking in the right place, are entirely different from any other kind of verbosity.

I don't want verbose mode. I want Claude to tell me what it's reading in the first 3 seconds, so I can switch gears without fear it's going to the wrong part of the codebase. By saying that my use case requires verbose mode, you're saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.

(To lean into the babysitting analogy, I want Claude to be the babysitter, but I want to make sure the babysitter knows where I left the note before I head out the door.)

[bcherny]

> I don't want verbose mode. I want Claude to tell me what it's reading in the first 3 seconds, so I can switch gears without fear it's going to the wrong part of the codebase. By saying that my use case requires verbose mode, you're saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.

To be clear: we re-purposed verbose mode to do exactly what you are asking for. We kept the name "verbose mode", but the behavior is what you want, without the other verbose output.

[consumer451]

This is an interesting and complex ui decision to make.

Might it have been better to retire and/or rename the feature, if the underlying action was very different?

I work on silly basic stuff compared to Claude Code, but I find that I confuse fewer users if I rename a button instead of just changing the underlying effect.

This causes me to have to create new docs, and hopefully triggers affected users to find those docs, when they ask themselves “what happened to that button?”

[bcherny]

Yeah, in hindsight, we probably should have renamed it.

[nazgul17]

It's not too late.

[ivan_gammel]

You can call it “output granularity” and allow Java logger style configuration, e.g. allowing certain operations to be very verbose while others being simply aggregated

[skywhopper]

Feels like you aren’t really listening to the feedback. Is verbose mode the same as the explicit callouts of files read in the previous versions? Yes, you intended it to fulfill the same need, but, take a step back. Is it the same? I’m hearing a resounding “no”. At the very least if you hace made such a big change, you’ve gotten rid of the value of a true “verbose mode”.

[bostonvaulter2]

> To be clear: we re-purposed verbose mode to do exactly what you are asking for. We kept the name "verbose mode", but the behavior is what you want, without the other verbose output.

Verbose mode feels far too verbose to handle that. It’s also very hard to “keep your place” when toggling into verbose mode to see a specific output.

[rising-sky]

I think the point bcherny is making in the last few threads is that, the new verbose mode _default_ is not as verbose as it used to be and so it is not "too verbose to handle that". If you want "too verbose", that is still available behind a toggle

[bostonvaulter2]

Yeah, I didn't realize that there's a new sort of verbose mode now which is different than the verbose mode that was included previously. Although I'm still not clear on the difference between "verbose mode" and "ctrl + o". Based on https://news.ycombinator.com/item?id=46982177 I think they are different (specifically where they say "while hiding more details behind ctrl+o".

[dinp]

I thought I was the only person going crazy by the new default behavior not showing the file names! Please don't expect users to understand your product details and config options in such detail, it was working well before, let it remain. Or at least show some message like "to view file names, do xyz" in the ui for a few days after such a change.

While we're here, another thing that's annoying: the token counter. While claude is working, it read some files, makes an edit, let's say token counter is at 2k tokens, I accept the edit, now it starts counting very fast from 0 to 2k and then shows normal inference speed changes to 2.1k, 2.3k etc. So wanted to confirm: is that just some UI decision and not actually using 2k tokens again? If so, it would be nice to have it off, just continue counting where you left off.

Another thing: is it possible to turn off the words like finagling and similar (I can't remember the spelling of any of them) ?

[bostonvaulter2]

> Another thing: is it possible to turn off the words like finagling and similar (I can't remember the spelling of any of them) ?

Big +1 on that. I find the names needlessly distracting. I want to just always say a single thing like “thinking”

[rob]

You should be able to do something like this:

    "spinnerVerbs": {
      "mode": "replace",
      "verbs": ["Thinking"]
    }

https://code.claude.com/docs/en/settings#available-settings

[bostonvaulter2]

Thank you for the config and the link, that's very much appreciated!

[verelo]

How absurd this is an option, but I’ll be using this config too.

[topherhunt]

I replaced my spinner verbs with thought-provoking Yodaese so my claude sessions are constantly making me think about my life decisions. Loving it. https://gist.github.com/topherhunt/b7fa7b915d6ee3a7998363d12...

[munksbeer]

> I want to just always say a single thing like “thinking”

As a counterview, I like the whimsical verbs. I'll be sticking with them. But nice to see there is an option.

[sincerely]

I don't want my tools to make jokes, I want them to work.

[fabiogaliano]

I remember they shipped a feature so that’s configurable.

[adastra22]

We don’t want verbose mode. We don’t want the whole file contents. We are not asking for that. What is not clear here?

All we want is the file paths. That is all. Verbose mode pulls in a lot of other information that might very well be needed in other contexts. People who want that info should use verbose mode. All we want is the regular non-verbose mode, with paths.

I fail to see how it is confusing to users, even new users, to print which paths were accessed. I fail to see the point of printing that some paths were accessed, but not which.

[JV00]

Verbose mode does exactly what you want as of v2.1.39, you are confusing it with the full transcript which is a different feature (ctrl+o). You enable verbose mode in /config and it gives you files read and search patterns and token count, not whole file contents.

[adastra22]

Please don’t change what these modes do! I have scripts that call into the agent SDK with verbose mode output for logging purposes. Now I guess I need to recreate the old verbose mode for that application? Why?

[extr]

FWIW I mentioned this in the thread (I am the guy in the big GH issue who actually used verbose mode and gave specific likes/dislikes), but I find it frustrating that ctrl+o still seems to truncate at strange boundaries. I am looking at an open CC session right now with verbose mode enabled - works pretty well and I'm glad you're fixing the subagent thing. But when I hit ctrl+o, I only see more detailed output for the last 4 messages, with the rest hidden behind ctrl+e.

It's not an easy UI problem to solve in all cases since behavior in CC can be so flexible, compaction, forking, etc. But it would be great if it was simply consistent (ctrl+o shows last N where N is like, 50, or 100), with ctrl+e revealing the rest.

[bcherny]

Yes totally. ctrl+o used to show all messages, but this is one of the tricky things about building in a terminal: because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter.

That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.

[wild_egg]

Terminals already solved how to do this decades ago: pagers.

Write the full content to a file and have less display it. That's a single "render" you do once and write to a file.

Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently.

If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.

[extr]

thanks dude. you are living my worst nightmare which is that my ultra cool tech demo i made for cracked engineers on the bleeding edge with 128GB ram apple silicon using frontier AI gets adopted by everyone in the world and becomes load bearing so now it needs to run on chromebooks from 2005. and if it doesn't work on those laptops then my entire company gets branded as washed and not goated and my cozy twitter account is spammed with "why didn't you just write it in rust lel".

o7

[snovv_crash]

Your worst nightmare. For me this is the cool part.

[bombela]

Just tell people to install a fast terminal if they somehow happen to have a slow one?

Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms?

It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.

[troupo]

> It's so trivial, can't you ask your fancy LLM to do it for you?

They did. And the result was a React render loop that takes 16ms to output a hundred characters to screen and tells them it will take a year to rewrite: https://x.com/trq212/status/2014051501786931427

[yencabulator]

What's extra funny is that curses diffs a virtual "current screen" to "new screen" to produce the control codes that are used to update the display. Ancient VDOM technology, and plenty fast enough.

[SPICLK2]

I'm with you on this one. "Terminals are too slow to support lots of text so we had to change this feature in unpopular ways" is just not a plausible reason, as terminals have been able to dump ~1Mb per second for decades.

The real problem is their ridiculous "React rendering in the terminal" UI.

[troupo]

> because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter.

Only if you use React as your terminal renderer. You're not rendering 10k objects on screen in a few milliseconds. You're outputting at best a few thousand characters. Even the slowest terminal renderer is capable of doing that.

[bethekidyouwant]

Why would you tailor your product for people that don’t know how to install a good terminal? Just tell them to install whatever terminal you recommend if they see tearing.

[SPICLK2]

Do you have any examples of slow terminals, and what kind of maximum characters per second they have?

[noodletheworld]

How do you respond to the comment that; given the log trace:

“Did something 2 times”

That may as well not be shown at all in default mode?

What useful information is imparted by “Read 4 files”?

You have two issues here:

1) making verbose mode better. Sure.

2) logging useless information in default.

If you're not imparting any useful information, claude may as well just show a spinner.

[bcherny]

It's a balance -- we don't want to hide everything away, so you have an understanding of what the model is doing. I agree that with future models, as intelligence and trust increase, we may be able to hide more, but I don't think we're there yet.

[Wowfunhappy]

That's perfectly reasonable, but I genuinely don't understand how "read 2 files" is ever useful at all. What am I supposed to do with this information? How can it help me redirect the model?

Like, I'm open to the idea that I'm the one using your software the wrong way, since obviously you know more about it than I do. What would you recommend I do with the knowledge of how many files Claude has read? Is there a situation where this number can tell me whether the model is on the right track?

[Wowfunhappy]

Honestly, I just want to be able to control precisely what I see via config.json. It will probably differ depending on the project. This is a developer tool, I don't see why you'd shy away from providing granular configuration (alongside reasonable defaults).

I actually miss being able to see all of the thinking, for example, because I could tell more quickly when the model was making a wrong assumption and intervene.

[whodidntante]

ok, I will be the dumbass here - I am a retired software engineer who has not used any of these tools, but when I as working on high volume web sites, all I wanted and needed was access to the log files. I would always have a small terminal session open to tail and grep for errors for the areas I was interested in. Had another small window to tail and monitor specific performance values. Etc.

I do not know how this concept would work in these agentic environments, but would seem useful, in an environment that has a lot of parallel things going on, with a lot of metrics that could be useful, you would want to have multiple monitors that can be quickly customized with standard linux utilities. Token usage, critical directory access, etc.

This, in conjunction with a config file to define/filter out the log stream should be all that's needed to provide as much or as little detail that would be needed to monitor how things are going, and to alert when certain things are going off the rails.

[bcherny]

That's a cool idea!

[jwpapi]

Honestly Tmux, vim, kitty, almost every terminal, shell, script is configurable. It’s what we’re used to. I wouldn’t know why you wouldn’t start allowing more config options.

[johnisgood]

I do not use CC (yet) but I think this is the right direction. We are hackers. We love hacking. We love to tinker about and configure! Please allow us.

(And yeah, I would love the verbose mode myself, but there could be various levels to it.)

[dimitri-vs]

Exactly. If a user wants a simpler experience there is now the Claude Cowork option.

[thecupisblue]

Maybe during onboarding you could ask for output preference? That would at least help new users.

I find this decision weird due to claude _code_, while being used by _some_ non-technical users, is mostly used by technical users and developers.

Not sure why the choice would be to dumb the output down for technical users/developers.

[trb]

I've commented on this ticket before: https://github.com/anthropics/claude-code/issues/8477#issuec...

The thinking mode is super-useful to me as I _often_ saw the model "think" differently from the response. Stuff like "I can see that I need to look for x, y, z to full understand the problem" and then proceeds to just not do that.

This is helpful as I can interrupt the process and guide it to actually do this. With the thinking-output hidden, I have lost this avenue for intervention.

I also want to see what files it reads, but not necessarily the output - I know most of the files that'll be relevant, I just want to see it's not totally off base.

Tl;dr: I would _love_ to have verbose mode be split into two modes: Just thinking and Thinking+Full agent/file output.

---

I'm happy to work in verbose mode. I get many people are probably fine with the standard minimal mode. But at least in my code base, on my projects, I still need to perform a decent amount of handholding through guidance, the model is not working for me the way you describe it working for you.

All I need is a few tools to help me intervene earlier to make claude-code work _much_ better for me. Right now I feel I'm fighting the system frequently.

[bcherny]

Yep, this is what we landed now, more or less: verbose mode is just file paths, then ctrl+o gives you thinking, agent output, and hook output.

[eterm]

Have you considered picking a new name for a different concept?

Or have ctrl+o cycle between "Info, Verbose, Trace"?

Or give us full control over what gets logged through config?

Ideally we would get a new tab where we could pick logging levels on:

  - Thoughts
  - Files read / written
  - Bashes
  - Subagents

etc.

[bonoboTP]

One use I have for seeing what exactly it is doing is to press Esc quick when I see it's confused and starts searching for some info that eg got compacted away, often going on a big quest like searching an entire large directory tree etc. What would actually wish is if it would ask me in these cases. It clearly know that it lacks info but thinks it can figure it out by itself by going on a quest and that's true but takes too long. It could just ask me. There could be some mode settings of how much I want to be involved and consulted, like just ask boldly for any factual info from me, or if I just want to step away and it should just figure everything out on its own.

[gardnr]

Have you considered keeping the old behavior available as "legacy mode"? I don't want verbose mode. I don't want to spend time configuring a mutli-state verbose mode that introduces new logging in future versions so I have to go and suppress things to get just file names. I just want to see the file names. I don't consider that verbose.

[verelo]

Not only what files, but what part of the files. Seeing 1-6 lines of a file that's being read is extremely frustrating, the UX of Claude code is average at best. Cursor on the other hand is slow and memory intensive, but at least I can really get a sense of what's going on and how I can work with it better.

[alsolinks]

I am not a claude user, but a similar problem I see on opencode is accessing links. More than once I've seen Kimi, GLM or GPT go tothe wrong place and waste tokens until I interrupt them and tell them a correct place to start looking for documentation or whatever they were doing.

If I got messages like "Accessed 6 websites" I'd flip and go spam a couple github issues with as much "I want names" as I could.

[4gotunameagain]

> saving thousands of tokens and sparing the context window

shhh don't say that, they will never fix it if means you use less tokens.

[espeed]

Such as Claude Code reading your ssh keys. Hiding the file names masks the vulnerability.

[dns_snek]

That's approaching the problem from the worst possible angle. If your security depends on you catching 1 message in a sea of output and quickly rotating the credential everywhere before someone has a chance to abuse it then you were never secure to begin with.

Not just because it requires constant attention which will eventually lapse, but because the agent has an unlimited number of ways to exfiltrate the key, for example it can pretend to write and run a "test" which reads your key, sends it to the attacker and you'll have no idea it's happening.

[espeed]

I sent email to Anthropic ([e-mail], [e-mail]) on January 8, 2025 alerting them to this issue: Claude Code Exploit: Claude Code Becomes an Unwitting Executor. If I hadn't seen Claude Code read my ssh file, I wouldn't have known the extent of the issue.

[espeed]

To improve the Claude model, it seems to me that any time Claude Code is working with data, the first step should be to use tools like genson (https://github.com/wolverdude/GenSON) to extract the data model and then create why files (metadata files) for data. Claude Code seems eager to use the /tmp space so even if the end user doesn't care, Claude Code could do this internally for best results. It would save tokens. If genson is reading the GBs of data, then claude doesn't have to. And further, reading the raw data is a path to prompt injection. Let genson read the data, and claude work on the metadata.

[espeed]

Correction: January 8, 2026

[Wowfunhappy]

I agree with you but I think there's a "defense in depth" angle to this. Yes, your security shouldn't depend on noticing which files Claude has read, since you'll mess up. But hiding the information means your guaranteed to never notice! It's good for the user to have signals that something might be going wrong.

[dns_snek]

There's no defense "in depth" here, it's like putting your SSH key in your public webroot and watching the logs to see if anyone's taken your key. That's your only layer of "defense" and you don't stand any chance of enforcing it. Real defense is rooted in technical measures, imperfect as they may be, but this is just defense through wishful thinking.

[Wowfunhappy]

Obviously, don't put your SSH keys in a public webroot. But let's say you're managing a web server and have a decent security mindset. But don't you think it's better to regularly check the logs for evidence of an attack vs delete all the logs so they can't be checked?

[andersa]

Why does it have access to those paths?

[stingraycharles]

What annoys me is that I don’t have the choice anymore. It’s just decided that thinking is not possible to see anymore, files being read are very difficult to see, etc.

I understand that I’m probably not the target audience if I want to actually step in and correct course, but it’s annoying.