AI 8 min read

Do You Know What Commands Your AI Agent Ran?

AI agents run shell commands you may never review. See one session reviewed from local records, and what those records can and can't tell you.

Madhubalan Appachi · Published February 7, 2026 · Updated September 19, 2026

You open Claude Code, type a prompt — "refactor the auth module to use JWT" — and walk away to grab coffee. When you come back, the task is done. New files, updated tests, a clean diff. You review the code changes, run the tests, push to main. Job well done.

But here's a question: do you know what shell commands Claude ran to get there?

If you're like most developers, the answer is no. And that should bother you a little.

The Invisible Execution Problem

AI coding assistants like Claude Code, Cursor, and Codex don't just write code. They execute code. They run shell commands in your terminal: installing packages, running tests, executing scripts, changing permissions. One prompt can lead to a string of them.

The problem is visibility. Most developers interact with AI agents through a chat-style interface. The conversation scrolls, tool calls fly by, and a chmod or a package install is easy to miss between file reads and edits.

The code diff doesn't help here. It shows what the agent changed in tracked files. It doesn't show that the agent installed a dependency, made a script executable, or ran that script against your local database.

Reviewing One Session: What Happened Outside the Diff?

Here's the JWT refactor again, as a synthetic example of how you'd review it with Suvadu after connecting Claude Code with suv init claude-code. From the project directory, list what Claude Code ran today:

$ suv history --executor claude-code --after today --here
2026-09-18 14:39:02  ✓        0ms  ~/projects/api        git diff --stat
2026-09-18 14:38:52  ✓        0ms  ~/projects/api        npm test -- auth
2026-09-18 14:37:30  ✗1       0ms  ~/projects/api        npm test -- auth
2026-09-18 14:36:15  ✓        0ms  ~/projects/api        ./scripts/migrate-auth.sh
2026-09-18 14:36:12  ✓        0ms  ~/projects/api        chmod +x scripts/migrate-auth.sh
2026-09-18 14:35:47  ✓        0ms  ~/projects/api        npx tsc --noEmit
2026-09-18 14:33:04  ✓        0ms  ~/projects/api        npm install jsonwebtoken @types/jsonwebtoken
2026-09-18 14:32:10  ✓        0ms  ~/projects/api        git status

Eight shell commands, newest first. Two details are worth knowing before you read them:

File reads and edits aren't here. Claude Code reads and edits files with its own tools, not the shell. Suvadu's Claude Code hooks record Bash tool calls only, so this is the shell activity, not everything the agent did.
0ms means "not reported". Claude Code's hook events carry no duration, so Suvadu stores the time the event arrived instead of guessing one.

Now ask which of these deserve a closer look:

$ suv agent report --executor claude-code --here

═══════════════════════════════════════════════════════
  AGENT ACTIVITY REPORT — Sep 18, 2026
═══════════════════════════════════════════════════════

  Period:     14:32 — 14:39
  Agents:     claude-code (8 cmds)
  Success:    7/8 (87.5%)
  Risk:       3 high

───────────────────────────────────────────────────────
  ⚠ HIGH RISK COMMANDS
───────────────────────────────────────────────────────
  [claude-code]  npm install jsonwebtoken @types/jsonwebtoken
             ~/projects/api · 14:33 · exit 0
             Category: package-install

  [claude-code]  chmod +x scripts/migrate-auth.sh
             ~/projects/api · 14:36 · exit 0
             Category: permission

  [claude-code]  ./scripts/migrate-auth.sh
             ~/projects/api · 14:36 · exit 0
             Category: script-exec

───────────────────────────────────────────────────────
  📦 PACKAGES INSTALLED
───────────────────────────────────────────────────────
  npm: jsonwebtoken, @types/jsonwebtoken

───────────────────────────────────────────────────────
  ✘ FAILED COMMANDS (1)
───────────────────────────────────────────────────────
  [claude-code]  npm test -- auth                           exit 1  14:37

═══════════════════════════════════════════════════════

The diff shows the new dependencies in package.json, but only the command record shows that ./scripts/migrate-auth.sh ran. If that script touches a local database or writes files outside the repo, those effects won't appear in git diff. That's the question to take to the script's source, or to the agent's own explanation.

To see that explanation, open the session:

suv sessions

Press Ctrl+T to show AI sessions and open the Claude Code session. Its timeline interleaves your prompt, the assistant's replies, and the recorded commands, so you can check whether the agent said why it ran the migration script. The sessions guide explains each field.

What the Record Can't Tell You

A command record is evidence, not a full audit. Be clear about its limits:

Only reported commands. Suvadu records what its shell hooks and agent integrations are told about. Commands from a tool without an integration, running in a shell that doesn't load Suvadu's hooks, aren't recorded. Neither is anything the host never emits an event for.
No output. Stdout and stderr aren't stored. You'll know npm test -- auth failed at 14:37, but not the error message; for that, rerun it or read the agent's reply.
No view inside a script. ./scripts/migrate-auth.sh is one record. The commands inside the script aren't recorded individually.
Risk is pattern-based. The high labels come from command patterns like package installs, chmod, and script execution. They don't mean those commands were harmful, and a command that matches no pattern — cat .env, for example — isn't flagged even though it reads secrets.
Prompts depend on the integration. Claude Code, Codex, Cursor, OpenCode, and pi capture prompt text. Tools recognized only through terminal environment variables get an executor label and no prompt.

The audit guide covers capture boundaries per integration in more detail, and the compatibility matrix lists per-agent gaps.

Why This Matters

Security

Every command an AI agent runs has the same permissions you do. It can read your .env files, install packages, modify configs, and execute scripts. Most AI tools have safety guardrails, but the attack surface is real: malicious packages, prompt injection via file contents, or simply an AI making a well-intentioned but dangerous decision like running rm -rf in the wrong directory.

Without a record of what was executed, you have little to go on when you need to reconstruct an AI-assisted session.

Debugging

When something breaks after an AI session, the first question is always: "what changed?" If you only reviewed the code diff, you may be missing part of the picture. Maybe the agent installed a conflicting package version. Maybe it ran a migration script. Maybe it modified a config file and then overwrote it. The recorded commands fill in the parts the diff can't show.

Learning

AI agents often use command patterns you wouldn't think of. Reviewing what they ran — not just what they wrote — teaches you new tools, flags, and workflows. But you can only learn from what you can see.

How Suvadu Records Agent Commands

Suvadu is a shell history tool built in Rust that records commands covered by its shell hooks and agent integrations with metadata such as timestamp, working directory, exit code, duration where the source reports it, and executor attribution. Records stay in a local SQLite database.

Dedicated integrations. suv init claude-code, suv init codex, suv init cursor, suv init opencode, and suv init pi hook into each agent's own command and prompt events. For Claude Code, that means the PostToolUse and PostToolUseFailure events for the Bash tool, UserPromptSubmit for prompts, and Stop/SessionEnd to import the session's replies, models, and reported token usage.
Environment detection. In an interactive Zsh or Bash session with Suvadu's hooks loaded, Suvadu checks a set of environment variables to label commands from IDE terminals (Cursor, VS Code, Windsurf, Antigravity, IntelliJ, PyCharm), some agents, and CI platforms (GitHub Actions, GitLab CI, CircleCI).

Setup steps for each agent, and how to verify them, are in How to Set Up AI Agent Tracking.

Searching by Executor

Once commands are tagged, you can slice your history by executor:

# Everything Claude Code ran today (plain output)
$ suv history --executor claude-code --after today

# Cursor commands in a specific directory
$ suv history --executor cursor --cwd ~/projects/api

# Interactive search: Claude Code commands that failed
$ suv search --executor claude-code --failed

# Compare: what did YOU run vs what the AI ran?
$ suv history --executor human --after today
$ suv history --executor agent --after today

Executor filters match the executor type or name, so --executor agent covers commands recorded as agent activity and --executor human covers commands you typed in a regular terminal. IDE-terminal commands have their own ide type.

A Practical Workflow

Here's how executor tracking fits into a real development workflow:

During: Let the AI agent work. You don't need to watch every command scroll by.
After: From the project directory, run suv agent report --executor agent --here to see flagged commands, installed packages, and failures in one place.
Audit: Check that every install was intended, and read any script the agent executed.
Context: Open the session in suv sessions for the prompts and replies around anything surprising.
Learn: Look at the command patterns the AI used. Often you'll discover flags or tools you didn't know about.

This gives you a persistent view of the command events your integrations report, with the gaps listed above.

The Bigger Picture

AI coding assistants are becoming a standard part of the development workflow. That's a good thing. But productivity without visibility is a liability.

We wouldn't accept a CI pipeline that doesn't log its commands. We wouldn't accept a deployment script that runs silently. We shouldn't accept AI agents running commands with no persistent, searchable record either.

Executor tracking isn't about distrusting AI tools. It's about applying the same observability standards to AI-assisted development that we already apply to every other automated process in our stack.

Letting Your Agent Query the Record

Suvadu includes a local MCP (Model Context Protocol) server. A connected AI client can query recent commands, failures, and directory context. The server reads the local database, but any result it returns is available to that client and may be sent to its provider under the client's settings. See How AI Agents Query Your Shell History via MCP for the full story.