Keeping an Audit Trail of What Your Coding Agent Did on a Remote Mac mini#

When a coding agent works on a machine you are not sitting in front of, the most useful question afterwards is simple: what exactly happened? Which commands ran, which files changed, what was installed, and when did the session start and stop? On a dedicated remote Mac mini you have the luxury of a machine that exists only for this work, which makes it much easier to keep a clean, readable audit trail. This guide walks through a practical, low-effort approach using tools that already ship with macOS or are common in developer setups.

Why an audit trail matters for agent work#

An agent such as Claude Code can run shell commands, edit files across a repository and call external tools. Most of the time that is exactly what you want. But when a build breaks overnight, a dependency appears that nobody remembers adding, or a test suite suddenly takes twice as long, you need evidence rather than guesses. A good audit trail lets you:

• reconstruct a session after the fact without relying on memory,
• review changes before they are merged into a shared branch,
• spot unexpected network calls or package installs early,
• and hand the machine to a teammate with a clear history attached.

The goal is not surveillance. It is the same habit of keeping build logs and commit history that good teams already have, extended to the agent's terminal sessions.

Layer 1: Git is your primary record#

The most reliable log of what an agent changed is the repository itself. A few habits make Git history far more useful:

• Work on a dedicated branch per task. Ask the agent to create a branch with a descriptive name before it starts. Every change then lives in one place you can diff against the main branch.
• Commit in small steps. Small commits with clear messages are much easier to review than one large commit at the end of a long session.
• Use worktrees for parallel tasks. If several sessions run at once, separate worktrees keep their histories apart and avoid half-finished changes bleeding into each other.
• Never let the agent rewrite shared history. Disallow force-pushes to shared branches in your repository settings so that anything that reached the remote stays visible.

With these in place, git log --stat and git diff main...task-branch answer most "what changed?" questions in seconds.

Layer 2: Record the terminal session#

Git shows file changes, but not the commands that produced them. For that, record the terminal.

The simplest option is running each agent session inside tmux and enabling logging for the pane. tmux can pipe everything printed in a pane to a file, so a long session leaves behind a plain-text transcript that you can search with grep later. Name the log after the task and the date, store it in a dedicated folder such as ~/agent-logs/, and you have a timeline of every command and its output.

If you prefer not to use tmux, the built-in script command does a similar job: it starts a shell that writes everything to a file until you exit. Either way, keep the logs outside the repository so they are never committed by accident.

A few practical notes:

• Transcripts can contain secrets that appear in command output. Keep the log folder readable only by your user and avoid printing tokens in the first place.
• Rotate or compress old logs on a schedule so they do not quietly fill the disk.

Layer 3: Shell history with timestamps#

Even without full transcripts, the shell history is a valuable record if it is configured well. In zsh, the default shell on macOS, you can enable extended history so each entry carries a timestamp, increase the history size, and share history across sessions. Then history -E or a quick look at the history file shows when commands ran, not just what they were.

Layer 4: Know what was installed#

Agents often install packages to get a task done. That is fine, as long as you can see it afterwards.

• Homebrew: brew list --versions gives a snapshot of what is installed. Saving that output to a file at the start and end of a session and diffing the two shows exactly what changed. A Brewfile kept in a configuration repository makes the expected state explicit.
• Language package managers: prefer project-local installs (lockfiles, virtual environments, per-project node_modules) over global installs, so new dependencies show up in the repository diff instead of hiding in the system.
• Global tools: if a global install is genuinely needed, note it in the task's commit message or a short changelog file so the next person knows why it is there.

Layer 5: System logs for the bigger picture#

macOS keeps a unified system log that you can query with the log command. You rarely need it for day-to-day agent work, but it is useful when something unusual happens, such as a background service crashing, the machine restarting, or a launchd job failing to start. Filtering by process name and time window keeps the output manageable.

For scheduled jobs you run yourself through launchd, point the job's standard output and error to dedicated log files. Then every scheduled run, including ones started while nobody was watching, leaves a trace.

Reviewing a session in practice#

Putting the layers together, a short review routine after an agent session might look like this:

1. Read the branch diff against the main branch and check the commit messages.
2. Skim the terminal transcript for installs, network calls and anything that failed and was retried.
3. Compare the package snapshots from the start and end of the session.
4. Run the test suite yourself before merging.

This takes a few minutes for a typical task and catches most surprises before they reach a shared branch.

Why a dedicated remote machine helps#

Audit trails are much easier to keep on a machine that does only one job. On a personal laptop, agent activity mixes with browsing, chat apps and everything else, and logs are noisy. On a dedicated remote Mac mini, the history belongs to the work, the disk is not shared with personal files, and the machine can run long sessions while your own computer is closed. You connect with SSH or a remote desktop tool, check the logs, and disconnect.

If you would rather not maintain such a machine yourself, CCRent offers dedicated Mac mini M4 machines in several regions with Claude Code already set up, reachable over Tailscale and SSH or with remote desktop tools such as RustDesk, so you can focus on reviewing the work rather than on the hardware.

Summary#

You do not need special software to know what your coding agent did. Branch-per-task Git history, recorded terminal sessions, timestamped shell history, package snapshots and the occasional look at system logs together give a clear, reviewable record. Set them up once on the machine where the agent runs, and every future session becomes easier to understand, review and trust.

Claude is a trademark of Anthropic. CCRent is an independent provider, not affiliated with Anthropic.