---
id: "concept-bash-general-tool"
type: "concept"
source_timestamps: ["§ Bash + Code as a General Purpose Tool"]
tags: ["tool-use", "autonomy"]
related: ["concept-agent-harness", "action-provide-bash", "prereq-react-loop", "concept-progressive-disclosure"]
definition: "Providing agents with bash and code execution capabilities so they can autonomously write scripts to solve problems rather than relying on pre-built tools."
---
# Bash + Code Execution as a General Purpose Tool

## The Pattern

Instead of forcing developers to pre-design and configure tools for every possible action an agent might need to take, modern harnesses ship with a **general-purpose bash tool** alongside a code execution environment.

This allows models to solve problems **autonomously by writing and executing code**. By giving models a computer (via bash + code execution), the model can **design its own tools on the fly** rather than being constrained to a fixed, pre-configured set.

## Relation to the ReAct Loop

This pattern is an evolution of the [[prereq-react-loop|ReAct loop]]: instead of selecting from a small menu of typed tools, the model emits shell commands as its action and observes their stdout/stderr as the observation. Bash is effectively the **universal tool**.

## Status

This has become the default general-purpose strategy for autonomous problem solving in coding agents (Claude Code, SWE-agent, Devin-style systems). The action item [[action-provide-bash]] captures the design recommendation.

## Counter-Perspective

Bash access is powerful but also a **security and observability liability**. In high-risk or enterprise settings, harnesses may prefer strongly typed, sandboxed tools with structured schemas — easier to log, audit, and constrain than arbitrary shell commands. The choice between *general* and *typed* tooling is a trade-off between autonomy and governance.

See also: [[concept-progressive-disclosure]] for how harnesses avoid drowning models in too many typed tools when they do exist.