Aider's /run command for shell integration: when to let the model see your output

Published 2026-03-05 by Owner

Aider’s /run command lets you execute a shell command and pipe its output into the model’s context. The model then has the output available for the next turn. This unlocks debugging workflows that would be otherwise awkward but introduces some considerations worth knowing.

The basic flow

Inside an aider session:

> /run npm test

[npm test output appears, including errors]

> the failing test is about token validation. fix it.

The model sees the test output and your follow-up prompt. It can now write a fix that’s grounded in the actual error message, not your description of it.

This is meaningfully more reliable than typing “the test fails with this error message” because the model sees the original output, including stack traces, file paths, and any context the testing framework provides.

When this is great

Debugging test failures. /run npm test, then ask for a fix. The model sees the failure and proposes a fix grounded in the actual error.

Following CI failures locally. When CI fails on a check you can run locally, /run lets you reproduce in front of the model.

Inspecting state. /run git status, /run docker ps, /run kubectl get pods — let the model see the state of your environment before suggesting changes.

Quick exploration. /run grep -r "old_function_name" --include='*.ts' — let the model see all the call sites before refactoring.

Seeing actual file contents. /run cat .env.example — sometimes faster than asking the model to read the file.

When this is risky

The output gets sent to the model API. Whatever appears in the terminal becomes part of the model’s context, which means whatever appears in the terminal goes to Anthropic, OpenAI, or wherever your model is hosted.

Risky commands:

Anything that prints credentials. /run env would dump every environment variable, including secrets. /run cat config.json could include API keys. /run aws sts get-caller-identity produces account-related metadata.

Anything that produces customer data. /run psql -c "SELECT * FROM users LIMIT 10" would leak real user data. Never run this with /run.

Anything that produces sensitive logs. /run journalctl -u myservice --since "1 hour ago" could include any sensitive data your service logged.

Anything with very long output. /run npm install --verbose produces megabytes of output. The model context fills up; useful information gets truncated.

The mitigation: think about what the command will output before running it. If you don’t want the model to see the output, don’t pipe it through /run.

A safer pattern

For commands where you’re not sure what they’ll produce, run them in your terminal first (outside aider). Look at the output. If it’s safe, then /run it inside aider.

For commands that produce mixed output (some sensitive, some not), pipe through redaction:

> /run npm test 2>&1 | sed 's/SECRET=.*$//g'

Or run a command that produces a summary instead of the full output:

> /run pytest --tb=line   # short tracebacks instead of full

The principle: shape the output before it reaches the model. Don’t dump everything and hope for the best.

Auto-test mode

Aider has an auto-test feature that automatically runs your test command after each edit:

# .aider.conf.yml
auto-test: true
test-cmd: npm test

This effectively does /run npm test after every edit and feeds the result to the model. The model sees test failures and self-corrects.

The same considerations apply. Whatever your test output contains, the model sees. For most projects, test output is fine. For test suites that print sensitive setup data (some integration tests do this), you’d want to redact or skip auto-test.

The performance side

Long shell command output costs tokens. A /run that produces 10,000 lines of build output adds 100k+ tokens to your context. The session gets expensive fast.

For commands you’ll run often, consider:

Using flags that produce shorter output (--tb=line, --brief, etc.)
Piping through head or tail to bound output
Using grep to filter to relevant lines

For test runs:

> /run npm test --reporter=min   # minimal output
> /run pytest -q                 # quiet mode

The model rarely needs every line of build output. It needs enough context to understand what failed. Trim accordingly.

When `/run` is the wrong tool

Some tasks where /run doesn’t help:

Inspecting binary files. /run hexdump file.bin produces unreadable text. The model can’t reason about it.

Long-running processes. /run npm run dev doesn’t terminate. The session hangs. Use a separate terminal for long-running work.

Interactive commands. /run psql opens an interactive shell aider can’t drive. Use a separate terminal.

Commands that need stdin. /run rm -i file.txt needs your interactive yes/no. Doesn’t work via /run.

For these, run the commands in a separate terminal and report results to aider via natural language.

A workflow I use

For TDD-style development:

Write a failing test (manually)
/run npm test — model sees the failure
“Implement the function to make this test pass; do not modify the test”
Aider produces the implementation
/run npm test — verify it passes
Commit

The pattern is fast because the model has direct access to test output. No copy-pasting error messages. No “the test still fails — let me check” round trips. The model sees what’s happening and adjusts.

For 80% of TDD work, this loop is faster than manual implementation while preserving the discipline of test-first development.

A pattern for legacy code exploration

When working in unfamiliar code:

> /run grep -r "deprecated_pattern" --include='*.py' -l
> /run wc -l <files from above>
> /run cat <one of the files>

The model sees: which files use the pattern, how big they are, what the actual code looks like. Now it can reason about the scope of a refactor.

Without /run, you’d describe each of these to the model in prose and the model would produce approximate plans based on imagined code. With /run, the plans are grounded in reality.

The principle

/run is one of aider’s most useful primitives. It makes the model’s context match your actual environment. The cost is that whatever the command outputs goes to the model provider; treat the command’s output as material you’re choosing to share.

Once you internalize this, the friction of “what should I share with the model?” disappears. You run what’s safe, you don’t run what isn’t, the workflow becomes fluid.

For everything else, your terminal still works. /run is for the cases where putting the output into the conversation is more useful than describing it.