Auditing What Codex Touched After a Session

A session that completed successfully and produced the result you asked for isn't automatically a session whose full scope of changes you actually know about — auditing what it genuinely touched, beyond just reviewing the diff for the task you asked about, is worth doing as a standing habit rather than only when something feels obviously wrong.

Why "it did what I asked" isn't the same as "I know everything it did"

A session focused on completing your stated task might, along the way, have touched files or made changes not directly part of the final diff you reviewed — a temporary file left behind, a configuration change made and then reverted but still visible in intermediate history, a read of a sensitive file that didn't result in a written change but still happened. Reviewing only the final diff against your stated task can miss all of this, because it's specifically designed to show you the intended result, not necessarily the full scope of everything that happened to get there.

What a full audit actually looks for

Beyond the files that changed in the final diff, it's worth checking git status and git log for anything that happened during the session that isn't reflected in what you reviewed — untracked files left behind, changes that were made and then undone, anything outside the specific scope you expected the task to touch. For a session that ran under a more permissive sandbox mode, this check matters more, since there was structurally more room for something outside the expected scope to have happened.

When this level of scrutiny is genuinely warranted

Not every session needs a full audit — a small, well-scoped task run under a narrow sandbox with careful incremental review already carries much of this assurance built in in real time. A full post-session audit earns its place specifically for larger, less closely supervised sessions, anything that ran under a more permissive sandbox mode, or anything where the stakes of an unnoticed side effect would be genuinely significant.

Checking file access, not just file changes

Beyond what changed, it's worth considering what a session read, particularly for a task that touched sensitive files — credentials, configuration containing secrets, anything you wouldn't want included in a request's context unnecessarily. This is harder to audit after the fact than file changes are, since reads don't leave the same kind of durable trace that writes do, which is exactly why scoping what a session has access to in the first place matters more than trying to audit reads retroactively.

Building this into a review checklist for higher-stakes sessions

For sessions you've identified as warranting a full audit, it's worth having an explicit checklist rather than relying on memory each time: check git status and log for anything outside the reviewed diff, confirm no untracked files were left behind unexpectedly, and confirm the sandbox mode used was actually appropriate in retrospect for what the task turned out to need. Having this as a written checklist, rather than an ad hoc afterthought, makes it something that actually gets done consistently rather than skipped under time pressure.

What to do if an audit turns up something unexpected

An unexpected finding — a file touched outside the apparent scope, an access to something sensitive that wasn't obviously necessary for the task — is worth investigating directly rather than dismissed as probably fine, especially the first few times it happens. Asking the session itself (if still active) to explain the unexpected action, or reviewing the relevant portion of the session's own transcript, is usually the fastest way to determine whether it was a benign, explainable part of accomplishing the task or something worth tightening the sandbox configuration to prevent going forward.

Why this habit pays off most for automated, recurring sessions

A one-off interactive session you closely supervised in real time needs less of this after-the-fact scrutiny than a recurring, less closely watched automated one — for anything running unattended and repeatedly, building a lightweight version of this audit into the automation itself, flagging anything outside an expected, predefined scope automatically, extends this same discipline to exactly the sessions where a human isn't watching closely enough to catch something unusual as it happens in real time.

Treating an audit as routine hygiene, not an accusation

It's worth framing this practice, especially to a team, as standard hygiene applied consistently to every higher-stakes session, rather than something reserved for moments of specific suspicion — a session that behaved perfectly well still benefits from a quick audit confirming that, the same way a clean bill of health from a routine check is still worth having even when nothing was actually wrong. Reserving audits only for sessions that already feel suspicious means missing the cases where something quietly went unnoticed precisely because nothing about the session felt alarming at the time.

How this connects to every other sandbox practice this site covers

This page is, in a sense, the closing check on everything else this site recommends about sandbox and approval configuration — scoping access narrowly, choosing approval modes deliberately, reviewing diffs carefully. An audit is what confirms those other practices actually worked as intended for a specific session, rather than simply trusting that they did. Treating it as the final, verifying step in a chain of deliberate practices, rather than a separate, optional add-on nobody quite gets around to, is what makes the whole chain genuinely trustworthy in practice rather than merely well-intentioned on paper.