DEV Community: Denis Bakhoum

Claude Code stopped using its own tools

Denis Bakhoum — Thu, 03 Sep 2026 10:00:00 +0000

A week ago I installed the TypeScript LSP plugin for Claude Code. The pitch sold me. The agent works the way I do in an editor, navigating with go-to-definition and find-references instead of grepping around, and catching type errors as it writes instead of at the end of a task. I watched it work in that session and forgot about it.

A week later I went back to check what it had bought me. Nine calls, all inside the session where I tested it, on August 25. Zero across the twenty-seven sessions since.

That was annoying enough to go digging.

Everything moved to Bash

I pulled every session transcript from ~/.claude/projects for one repo, a large Next.js app I work in daily. 76 sessions, 8,343 tool calls, all on Opus 5, July 31 to September 1.

Across the whole period Bash took 70% of all tool calls. Over the last two weeks, 84%, while the built-in file tools fell to 7%.
(defaultMode: "auto" the whole window, so that didn't change.)

grep 1,281, Grep 0

Grep and Glob were called zero times in 8,343 tool calls. grep ran 1,165 times through Bash and rg another 116.

Here's one from my transcripts, reading a file:

sed -n 269,352p src/domains/billing/server/database/read.ts

This one ran three times in a row across different files:

perl -pi -e 's{\bvendorContracts\b}{importedContracts}g' previewVendorContractsSyncFunction.ts

perl -pi to rename a symbol. In a repo where the LSP plugin with
find-references was installed and enabled. I stared at that one for a while, wondering if some phrasing of mine had nudged it toward the shell. No idea. There were 325 python3 and perl rewrites doing what Edit does natively.

When Claude actually modified a file it mostly used Edit and Write. The swaps happen when it reads and searches.

Where my permission rules went

The permissions docs explain a big chunk of it. A fixed set of Bash commands runs with no permission prompt in every mode:

These include ls, cat, head, grep, find, and read-only forms of
git. The set is not configurable.

Every shell command it reached for instead of a built-in is on that list. 22%of my 5,837 Bash calls used nothing but commands from that list, 31% counting git. None of them ever prompted.

Two of the rules in my deny list:

"deny": ["Read(**/.env)", "Bash(rm -rf:*)"]

Here is a command from my own transcripts, August 11:

DB=$(grep -m1 '^DATABASE_URL' .env | sed 's/^DATABASE_URL=//; s/^"//; s/"$//') \
  && psql "$DB" -c 'select u.email, um."organizationId", o.name, um.role from "User" u ...'

Read(**/.env) is denied, but that call is not a Read. It is a grep, on the prompt-free list, so it never asked.

What the changelog says

The v2.1.116 changelog says Glob and Grep are deliberately removed on native macOS and Linux builds, "replaced by embedded bfs and ugrep available through the Bash tool — faster searches without a separate tool round-trip." On my machine, which bfs ugrep finds neither. The tools reference still lists Grep and Glob. The native build ships neither them nor the replacements.

I don't know whether that is deliberate or a build regression nobody caught.
There are open issues either way.#64136 ties the missing tools to Bash storms and fabricated file paths.
#52121 describes my exact setup, and calls it "particularly problematic for systems where bash grep/find are restricted by permission policies, as there's no alternative code-search path." And #80267, labelled
reproduced by maintainers, treats shell-based file editing as normal: diagnostics go stale "because Claude Code likes to use sed, python, and similar tools to edit files in place".

What I tried

An undocumented env var helped a little (CLAUDE_CODE_THRIFTY_SONIC=false, mentioned in one of those issues, documented nowhere). Read and Edit came back, grep still won. So I wrote a PreToolUse hook that denies Bash for
anything a built-in tool does better.

Blocking grep did not make Claude reach for Grep. It reached for git grep, then git ls-files, and I had to close those specifically. With those closed, it finally uses the right tools. It costs a few calls at the start of every session while the model works out what's blocked.

A hook that blocks grep and find leaves no search path at all. So the current setup allows rg, fd, ls, grep and find through and keeps denying the rest.

The hook and the scripts are at Dionysos5/claude-code-tool-mix.

The part I can't get past

Nothing in my settings changed. I only found out because a plugin got zero calls.

The deny list is still sitting in my settings and I couldn't tell you what else it doesn't cover. Permission rules bind to tool names, and the harness picks the tool. Am I supposed to write a rule for every shell equivalent of every built-in, and keep them current against a build that changes weekly? That's roughly what my hook is now, and I don't think it should be my job.

How Do You Actually Know If AI Is Working On Your Team?

Denis Bakhoum — Fri, 27 Feb 2026 12:24:36 +0000

A few months ago I started leading a team to explore AI and how it can improve developer experience and productivity at my company. I ran weekly meetings, tried experiments with my team, and after a few weeks I had a problem: I couldn't say for sure that AI was making us more productive or by how much.

Engineers were giving mixed signals. Some were excited. Others said AI felt hit or miss — it would nail something obvious, then fall flat on anything touching our codebase conventions, and they'd spend more time correcting it than writing the code themselves. We wanted to show management that the investment was worth it but we had no good metric.

What everyone else is measuring

You've probably seen headlines like "At Company X, all of our code is written by AI" or "AI made our engineers 50% more productive." They rarely explain what that means or how they measured it.

Tool vendors measure lines of code generated and acceptance rate. An engineer can accept every suggestion and throw it all away, so these numbers tell you almost nothing about actual output quality. Productivity percentage sounds, but it's hard to measure varies across developers and even for the same person on similar tasks. It's not reproducible, and it doesn't tell you where to invest to get better.

A better question

Instead of measuring speed, I started asking something more concrete: across a feature's lifecycle, in how many areas can AI reliably carry the work?

Building a feature involves a lot of distinct areas: understanding requirements, system design, front-end components, back-end logic, tests, deployment. For each one, the question is simple: is this covered?

Covered — a workflow exists, validated against your codebase's real patterns, that at least two people on the team have used successfully. The developer reviews the output, makes minor adjustments, and ships.
Partial — the AI helps but can't carry the task alone. Something is documented but the workflow isn't complete, or only one person has validated it. Useful, but closer to pair programming than delegation.
Uncovered — the AI goes in blind, drawing on general training knowledge with no grounding in your specific codebase, it might read your code extensively before starting or it might not. More often the developer ends up steering constantly, like explaining a task to an intern rather than just doing it themselves.

With this framework, new areas start as Partial: one person documents and tests a workflow. When a second person can use it without tweaking, it gets promoted to Covered. Criteria can be adjusted, and over time you can layer in observability to make promotions more data-driven.

Coverage is infrastructure, not intuition

The reason this metric holds up where productivity percentages don't is that coverage describes your team's system, not a feeling about AI's general capability.

When I say forms are covered on my team, I mean a specific workflow exists that clarifies requirements, delegates to a subagent following our codebase's exact patterns, then runs a second subagent that validates the output against a checklist and corrects mistakes. Two developers with no particular prompting experience can create a form and get consistent, good results — not because AI is magically good at forms, but because the workflow is documented and the standards are encoded.

If an area is partial or uncovered today, the path forward is clear: document the patterns, build the workflow, get teammates to validate it through real usage. No need to wait for smarter models.

Three areas from our codebase

Forms (Covered). A dedicated skill, a subagent trained on our patterns, and a review subagent that catches and fixes problems. Multiple people have used it on production forms. The developer reviews the output and ships.

Scheduled tasks (Partial). Patterns are documented and the AI has something to work from, but there's no complete workflow and only one person has validated it in practice. It helps, but the developer still carries a meaningful share.

Bug investigation (Uncovered). Debugging well means having a method: form a hypothesis, write a failing test to confirm it, trace data. Experienced developers do this intuitively. AI tries things and you end up evaluating random attempts rather than narrowing down. Most people on my team stopped reaching for AI here and just debugged themselves — which is the kind of signal a coverage map is designed to surface.

What you can do with it

A coverage map lets you route work deliberately. Covered areas get delegated. Uncovered areas stop wasting people's time. And when someone asks where to invest, you have a specific answer — not "we need a better model" but "we need to build the workflow for this area."
When making the case for AI adoption, it's the difference between "I think it's working" and being able to show exactly where it's working, where it isn't, and what the team is doing about it.