When people say “general agent,” many teams imagine a neat little lineup of tool calls: read Gmail, query a CRM, check a calendar, then write back a polished answer. It sounds clean. It demos well. And then reality walks in and asks a very annoying question: where does the intermediate work go?

What did the agent fetch? What did it filter out? What does it want to verify before answering? In many systems, all of that stays trapped inside the model’s context window. That is like asking someone to sort a pile of receipts in their head while standing up. Technically possible. Also a fantastic way to miss things.

Thariq from Anthropic posted a short but sharp thread about this, and his advice after talking with many companies building general agents is delightfully unglamorous: use the bash tool more. The point is not to make every agent cosplay as a software engineer. The point is to give the agent a real workbench — a place to save files, search them, rerun steps, and check its own work (◕‿◕).

The real problem is not Bash syntax — it is whether intermediate state can exist outside the model

Thariq’s main example comes from an email agent. The user asks: “How much did I spend on ride sharing this week?”

If your system only has normal tool calls, the flow is something like this: fetch a bunch of emails, then ask the model to figure it out from there. Thariq notes that you might fetch around 100 emails. Once that happens, the model has to do needle-in-a-haystack work inside its own head.

With bash, the agent can save those results to files and then search them. Thariq highlights three benefits:

  • The answer can be grounded in reproducible code
  • The agent can take multiple passes to find everything
  • It can double-check and verify its work

That is the key idea. Bash is not making the model magically smarter. It is giving the model a place to stop pretending it can hold the whole job in memory. Many agent failures are not pure reasoning failures. They are workflow failures.

Clawd Clawd 歪樓一下：

This is the difference between “think harder” and “use a desk.” If you dump 100 receipts on a person and say, “calculate the total in your head,” you are testing stress tolerance, not intelligence. Bash gives the agent a desk: files, search, and a way to leave breadcrumbs.

Bash is really acting as workflow glue

Thariq’s next example is chaining API calls.

Say the user asks for all contacts you emailed this week. That is not a one-shot API problem. You may need to fetch all sent emails, dedupe the contacts, and then make an individual API request per contact to enrich the result.

This is where bash becomes useful in a very boring, very powerful way. The agent can write out each step, transform data between steps, retry pieces, and inspect the outputs along the way. Instead of juggling a tower of JSON objects inside the context window, it gets to build a small workflow in the open.

Some people in the replies pushed on this and asked a fair question: is this really bash-specific, or is it just a code execution environment with standard tools? That question matters. Because the real hero in the thread may not be the word “bash” itself. It may be the whole package behind it: filesystem, pipes, standard utilities, and the ability to run a process step by step.

You can think of bash as the universal adapter in the agent toolbox. It is rarely glamorous. It is just the thing that suddenly saves you when five mismatched parts need to work together.

This is not just for coding agents

One of the most interesting parts of the thread is that Thariq keeps the examples outside traditional coding work.

He mentions video and file editing. Models are good at using tools like ffmpeg to process videos, and they can search captions to find the right time slices. That is a very real workflow. You are not asking the model to merely “understand” a video. You are asking it to operate on files.

He also brings up recurring tasks. If your agent runs inside a container, it could use cron or at to create recurring jobs dynamically based on what the user asks for.

That means bash is not just a “developer tool” here. It is an interface between the agent and real-world artifacts: emails, files, videos, schedules, and processes.

Clawd Clawd OS：

People often see a shell and think, “ah, engineer black magic window.” From an agent’s point of view, though, it looks more like hands. If the job involves files, conversions, search, scheduling, or repeated passes, the path somehow keeps leading back to the shell. Old tools survive for a reason.

The pushback is real: security, exfiltration, and deployment

The replies under the thread are worth reading because they hit the hard part immediately.

Jeffrey Emanuel points to the obvious risk: if you allow arbitrary bash calls, you create a massive security problem and make data exfiltration much easier. His point is simple — a bash tool needs some internal mechanism to detect or block dangerous actions.

Other replies focus on deployment and runtime design. People ask: where does this actually run? How does the agent get filesystem access? Do you spin up a container for every user request? Those are not minor implementation details. Those are architecture questions.

There is also skepticism from a performance angle. One reply says they have been benchmarking agent performance with code versus tools, and it does not seem like there is an obvious difference yet. So the claim is not “bash always wins.” The claim is more like: in many workflows, bash gives the agent a much better working surface.

That distinction matters. The thread is not a victory lap for unrestricted shell access. It is a reminder that the moment you give an agent a real workbench, you also inherit real security and infrastructure responsibilities.

Clawd Clawd 補個刀：

Giving an agent bash is like giving it a Swiss Army knife. Extremely useful. Also not something you casually hand over and then wander off. The knife is not evil. But if you skipped permissions, policy, and isolation, you did not build a tool system — you built a future incident report.

Anthropic’s answer: a bash parser and a permission system

Thariq ends the thread by making the guardrail story explicit. The bash tool is one of the most powerful general-purpose tools you can give an agent, but you also need guardrails to make it safe.

He says the Claude Agent SDK includes a bash parser and permission system to make this easier.

That is a small line, but it reveals a very practical stance. Anthropic is not saying, “just open the terminal and pray.” They are saying: if bash is important, then parsing, permissions, and policy enforcement have to be part of the product, not an afterthought.

In other words, bash is not a shortcut around system design. It forces you to take system design more seriously.

Wrap-up

The biggest takeaway from this thread is not “every agent should learn Bash.” It is this: if an agent needs to work in multiple steps, leave intermediate results behind, search through them, and verify its own output, then it will want something very much like a shell.

That is why bash keeps showing up. Not because it is cool, but because it is old, general, and brutally practical. It lets an agent move work out of its head and into a process you can inspect.

For teams building general agents, that may be the real lesson here. Do not treat shell access as something only coding agents need. Quite often, the boring infrastructure is exactly what turns an agent from “looks impressive in a demo” into “can actually get the job done.”

If I had to put it in one blunt line: bash may look like a black terminal window, but for agents it is often the construction site. No construction site, no building.