Repeated Agent Workarounds Reveal Missing Features in Developer CLIs
Ayush Bhardwaj of Allos AI argues that the shell commands coding agents write after using a tool can reveal where its interface is failing them. In an audit of roughly 20,000 calls, he found repeated filtering and retries that pointed to missing ways to select, summarize and inspect results. Bhardwaj’s case study shows how to turn those patterns into CLI features and updated instructions, then use recorded calls to test whether the changes help agents answer correctly and with fewer turns.

Repeated workarounds expose missing interface features
? ayush-bhardwaj found a product roadmap in the commands agents wrote around his CLI. He built chat-history, a tool for coding agents to search past sessions across Claude Code, Codex, and Cursor. In an audit of about 20,000 calls to 14 everyday CLIs, roughly a quarter of calls sent output into filters such as head, grep, tail, Python, sort, or wc. For read-heavy commands, the share was higher: agents piped git show and cargo test output 62% of the time.
These commands are often sensible. An agent downloads a documentation page, searches for one setting, then keeps a few lines. It asks for a JSON report, then tails the output to reach the totals. It runs tests and trims the log. But each filter reflects an assumption about where the useful answer sits. Repeated patterns suggest that the tool is making the agent select and reshape information by hand.
In Bhardwaj’s October audit of chat-history, four out of five reads of old sessions—188 of 236—were piped through tools such as grep, sed, head, tail, or Python. He calls this the “pipe tax”: not that filtering is wrong, but that the agent keeps having to compose the same kind of cut-down command. Across the broader audit, 83% of pipes followed patterns that appeared at least ten times, even when their arguments varied.
The answer is not to prevent agents from piping. For one-off questions, they should be able to bound and select output themselves. The design opportunity is to notice when many agents keep making the same selection, then build that selection into the tool.
A pipeline can hide the failure along with the noise
Filtering can distort more than output size. Bhardwaj points to a Bash pipeline where cargo test reports a compilation error, but the command’s status appears successful. Without pipefail, Bash returns the exit code of the final command in a pipeline, not necessarily the test process. The agent may still see the error text, but the green status is misleading.
A filter can also remove the error itself. Bhardwaj describes a reported Claude Code issue in which a script threw a ReferenceError, while tail -3 retained only harmless lines. The model saw no error and reported success. His practical recommendation: when a tool fails, put a short failure summary in the final lines and point to the full log. A useful summary at the end is more likely to survive a truncation than an error buried earlier in a long output.
Build the selections agents repeatedly make
The chat-history case study shows how to turn those patterns into CLI features. One long session contained about 1.2 million characters; the messages around a search match were about 3,000. A general output cap can limit the size of a response, but it cannot identify the relevant messages. Bhardwaj added ways to return just the matching messages or a bounded slice around them.
Other repeated workarounds pointed to different features. Agents were using Python to extract a few fields from JSON, so search gained a compact mode: one line per result, about six times smaller than JSON while preserving the same results. About a third of inspect calls involved agents looping over sessions one at a time, so the CLI was changed to inspect several sessions in one call.
The distinction is between letting an agent make a useful choice and making it reconstruct that choice from shell commands each time. Infracost, a cloud-cost tool, reported a similar pattern: agents were writing jq and Python pipelines over large JSON responses. The company moved filtering into the CLI, added compact output, and supplied a skill to teach agents the new interface. In its tests, Claude answered none of six hard questions correctly without those changes and all six with them; cost across the benchmark fell 41%.
Documentation is part of the interface
A feature does little if the agent is still instructed to use the old one. Bhardwaj changed chat-history’s --deep flag so that it became a no-op, but left the skill file telling agents to use it. All 95 searches in the test continued to pass the flag. After he rewrote the skill, neither of two sessions used it; both tried the newer flags on their first read.
For an agent, the skill file, help text, and error messages are not supporting documentation around the interface. They are part of the interface. Stale instructions can preserve a workaround—or direct the agent toward a flag that no longer does anything. After the updated instructions reached agents, 99% of searches used compact output, and the share of reads piped through other commands fell from 82% to about a quarter.
Treat transcripts as test cases, not just logs
Bhardwaj’s proposed evaluation method starts with the calls agents actually made. Replay recorded commands against the old and new builds, then compare the results with what the agent did next. If a ranking changes, check whether the result the agent used stays on top. If an output format changes, check whether relevant information disappeared. A retry with different arguments may point to a failing case.
What the agent did next is only a rough answer key: it suggests what the agent wanted, but does not prove it. Bhardwaj recommends holding back some cases to evaluate the fix rather than using every trace to shape it. He also suggests starting with simple, frequent needs. In his audit, 55% of measured pipelines used only head, tail, or sed, pointing first to ranges and limits. For large outputs, bound what appears by default and say how to get the next slice.
Smaller output is not, by itself, evidence of a better workflow. Bhardwaj describes an agent mode that cut model-read output by 59%, while the saved tokens amounted to nearly 0.5% of all tokens read. In that case, cost and runtime did not improve. Infracost’s agents started getting answers right after its redesign; DuckDB’s agents were already answering correctly. The meaningful measures are whether agents get more answers right and need fewer turns—not just whether they read fewer tokens.
Bhardwaj’s division of labor is deliberate: people decide what the tool should be, then use real transcripts and tests to check whether it works. Agents can help find patterns across calls and test changes against recorded behavior, but he cautions against asking them to design an agent-facing tool from scratch. His closing instruction is simpler: back up the transcripts, look for repeated pipes or immediate retries, and treat the workaround as the bug report.