TL;DR: Runtime forensics for AI coding agents means reconstructing exactly what an autonomous session did across a repository, shell, and CLI harness, not just whether a single tool call was approved. Built-in logs from tools like Codex and Claude Code are scoped to individual permission decisions, so reconstructing a multi-step or cross-session attack requires correlating git history, shell history, and tool-call traces under a layer that mediates and records every action. Enterprise teams close that gap with sidecar enforcement and live workspace forks that let them fork, inspect, merge, or roll back agent work instead of trusting an unmodified log stream after the fact.
AI coding agents now read repositories, run shell commands, call MCP tools, and commit code with less human review at each step than a junior engineer would get on day one. When something goes wrong, a security team's first question is rarely "was this approved." It is "what actually happened across this session, and does it connect to anything the agent did last week." That question is runtime forensics for AI coding agents: the discipline of reconstructing an agent's actions across a full session, and across sessions, from the artifacts it leaves in the repository, the shell, and the harness itself.
This article covers what those artifacts look like, why the logging built into agents like Codex and Claude Code answers a narrower question than forensics requires, the long-horizon attack patterns that make session-level reconstruction necessary, and a practical framework for building this capability into a coding agent stack without rebuilding it.
Table of Contents
- What Is Runtime Forensics for AI Coding Agents?
- What Coding Agents Leave Behind in a Session
- Why Built-In Agent Logging Isn't Runtime Forensics
- Long-Horizon and Cross-Session Attack Scenarios
- A Four-Stage Framework for Reconstructing Agent Sessions
- Mandatory Mediation and Live Workspace Forks
- Building Runtime Forensics into Your Coding Agent Stack
- FAQ
What Is Runtime Forensics for AI Coding Agents?
Runtime forensics for AI coding agents is the practice of reconstructing what an autonomous coding session did, in what order, and why, using the evidence it left in the repository, the shell, and the agent harness itself. It answers "what happened across this session and how did it connect to later actions," not "was this one command approved."
It gets confused with three adjacent practices that answer narrower or different questions:
- Approval and audit logging built into the agent (Codex's OpenTelemetry export, Claude Code's permission settings) records individual tool-call decisions, not a reconstructable session.
- Traditional application security logging (SIEM, EDR) captures host and network events, not the agent's intent or the chain of tool calls that produced a repository change.
- Static code security scanning (SAST/SCA) analyzes committed code for known vulnerability patterns; it says nothing about how an autonomous session arrived at that code or what else happened in the same session.
What Coding Agents Leave Behind in a Session
A coding agent session leaves a scattered evidence trail across the repository, the shell, and whichever CLI harness is running it, and none of those artifacts were designed to be read together. Reconstructing a session means pulling all three into one timeline.
Repository and Git History
Every commit, branch, and stash an agent creates is real git history, but git alone does not distinguish a human commit from an agent-authored one, or capture the prompt and tool calls that led to it. OpenAI's Codex sandboxing documentation notes that in the default workspace-write policy, the .git, .agents, and .codex directories inside the workspace are protected as read-only, which limits direct tampering with version history but does not itself produce a forensic record of what the agent did before it committed.
Shell History and Command Traces
Shell history shows commands that ran, not the reasoning that triggered them or the tool call that issued them. When an agent operates through workspace-write with danger-full-access disabled, its filesystem and network reach is bounded, but the shell history alone cannot tell an investigator which of those commands came from the agent versus the developer at the same terminal.
CLI Harness Logs and Approval Records
Codex CLI, Claude Code, and Cursor each keep their own harness-level records, and those records differ meaningfully in scope. Claude Code's permission system, per Anthropic's documentation, does not require approval for file reads or Grep within the working directory, requires approval for most Bash commands and file modifications, and evaluates rules in a strict deny-then-ask-then-allow order. Codex, per OpenAI, runs with network access off by default as of September 2026 and an OS-enforced sandbox that typically limits writes to the current workspace, with an approval policy governing when it must stop and ask.
Runtime control infrastructure like Gensee Crate records which process touched which file or ran which command outside any one harness, rather than relying on each tool's own records.
Why Built-In Agent Logging Isn't Runtime Forensics
Built-in agent logging is scoped to answering whether a specific action was permitted, not to reconstructing an entire session or linking it to later ones, so it structurally cannot substitute for forensics even where it is enabled and well configured. The two are aimed at different questions, and the difference has more than one dimension.
| Built-in agent logging | Runtime forensics requirement |
|---|---|
| Confirms whether one tool call was approved or denied | Reconstructs the full sequence of actions and their intent across a session |
| Lives inside one agent's own event stream (Codex telemetry, Claude Code settings) | Correlates events across git, shell, and multiple CLI harnesses at once |
| Off by default and opt-in to turn on, as of 2026 for Codex's OpenTelemetry export | Must be mediated and always-on, not a setting a session can skip |
| Stored per project or session, scoped to that workspace | Needs lineage that follows risk across sessions and repositories |
What Codex and Claude Code Logs Actually Capture
Codex's telemetry is off by default; when enabled, OpenAI's documentation says it emits structured events such as codex.conversation_starts, codex.user_prompt, codex.tool_decision, and codex.tool_result, and explicitly advises treating tool arguments and outputs as sensitive. OpenAI's own account of running Codex internally states these logs export via OpenTelemetry, are available through OpenAI's Compliance Platform for Enterprise and Edu customers, and feed a security triage workflow that inspects the original request, tool activity, approval decisions, and network policy decisions together. OpenAI frames the distinction directly: traditional security logs mostly answer what happened, while Codex's logs help explain the surrounding user and agent intent.
Claude Code's settings model tells a similar story from a different angle. Anthropic's documentation describes four settings scopes (user, shared project, project-local, and managed), with managed settings applying to everyone an organization deploys to and overriding local choices except for documented exceptions. When a developer grants a standing Bash approval, Claude Code saves it to .claude/settings.local.json at the repository root, and that approval then applies to every future session in that repository, including subdirectories and worktrees. Anthropic is candid that this isn't a security boundary around the program, since the same underlying command can be invoked in different forms; for enforcement that doesn't depend on parsing command text, Anthropic points teams toward sandboxing and a PreToolUse hook instead.
The Gap Between Approval Records and Session Reconstruction
Both systems record decisions well within their own scope. Neither one is built to answer whether a Bash approval granted in one repository three weeks ago is the same standing permission a prompt-injected dependency exploited today, because that question spans sessions and repositories, not one event stream. This is the gap runtime control infrastructure like Gensee Crate is built to close: mediating and recording agent actions at the point of execution, across sessions, rather than inside any single agent's own opt-in telemetry.
Long-Horizon and Cross-Session Attack Scenarios
Long-horizon attacks against coding agents unfold over multiple steps or multiple sessions, which is exactly what per-decision approval logs and per-session shell history are not built to connect. Reconstructing them requires session-spanning evidence, not a single alert.
Memory Poisoning Across Sessions
An agent that carries persistent memory, project notes, or a standing Bash approval across sessions can be poisoned once and exploited later. A malicious instruction planted in a README, a config comment, or a memory file does not need to act immediately; it can wait until a future session re-reads that file and treats it as trusted context. Without a record that ties the poisoning event to the later session that acted on it, an investigator sees two unrelated incidents instead of one attack.
Prompt Injection via MCP Tools and Repositories
MCP tool responses and repository content are both untrusted input from the agent's perspective, and both are prime injection surfaces. A tool result or a file the agent reads can carry embedded instructions designed to redirect the next several tool calls. Because Claude Code's file reads inside the working directory do not require approval and Codex's default sandbox still permits routine local operations, an injected instruction can trigger real writes and commands before any approval gate has reason to intervene.
Planted Persistence and Delayed Execution
The more difficult scenarios combine both patterns: an agent is manipulated into planting a script, a dependency, or a scheduled task that executes well after the originating session has ended. By the time the delayed action fires, the shell history and git log show an isolated event with no obvious link to the session that planted it. Our analysis suggests this delayed-execution pattern is precisely where session-scoped logging fails hardest, because the two halves of the attack never appear in the same log stream at all.
Tip: When reviewing an incident, don't just ask which command executed. Ask which earlier session, prompt, or tool result could plausibly have planted the condition that made this command look normal.
A Four-Stage Framework for Reconstructing Agent Sessions
Reconstructing an agent session reliably means working through four stages in order: capture, correlate, replay, and attribute. Skipping any one of them leaves either an incomplete timeline or an untrustworthy one.
![https://pub-7b00fbd2070049a3aa74950ae9141ae4.r2.dev/images/ak_4d71df17bde075ad/job_cb0b1b669bbd1fac5cd680d460c290b2/inline-2.png]](https://pub-7b00fbd2070049a3aa74950ae9141ae4.r2.dev/images/ak_4d71df17bde075ad/job_cb0b1b669bbd1fac5cd680d460c290b2/inline-2.png%5D){kind=link}
- Capture. Record every tool call, file read and write, shell command, and network decision at the point the agent takes it, not by parsing logs after the fact.
- Correlate. Tie those captured events to the git commits, branches, and shell history they produced, and link them across sessions and repositories rather than treating each session as isolated.
- Replay. Reconstruct the session as an ordered sequence an investigator can step through, seeing what the agent saw and what it changed at each point.
- Attribute. Connect the reconstructed sequence to an identity, a policy decision, and, where relevant, an earlier session that planted the condition being investigated.
In practice we find that teams which only capture and correlate, without a way to replay and attribute, end up with logs they can search but not actually explain, which defeats the purpose of doing forensics in the first place. For an example of reproducible evidence, see this controlled reproduction of an autonomous agent's package-service boundary escape.
Mandatory Mediation and Live Workspace Forks
Mandatory mediation means every agent action passes through an enforcement point before it takes effect, rather than being logged after the fact from inside the agent's own process. A live workspace fork extends that idea to the repository itself: the session's changes land in a fork that can be inspected, then merged, promoted, rolled back or discarded instead of applied irreversibly.
Sidecar Enforcement Without Rebuilding the Agent Stack
A sidecar sits alongside an unmodified agent (Claude Code, Codex, or Cursor) and mediates its actions without requiring an SDK rewrite or a change to how developers already invoke the tool. This matters because per-agent approval settings, like Claude Code's .claude/settings.local.json or Codex's sandbox policy, are configured and enforced independently in each tool; a sidecar model applies one mediation layer consistently across whichever harness a given team happens to run.
Fork, Inspect, Merge, or Roll Back
Treating an agent session as a transaction means its changes exist in an inspectable, isolated state before they become permanent. A security engineer can fork the session's work, review exactly what changed and why, merge it once it's cleared, or roll it back cleanly if it isn't, rather than reverting a commit after the fact and hoping nothing downstream already depended on it. Gensee Crate Enterprise applies this model as customized integration with existing identity, endpoint, MCP, and SIEM tooling, and Gensee Crate Personal brings the same fork-inspect-merge-rollback pattern to individual developer setups.
Cross-Session Risk Lineage
Because mediation happens at runtime rather than inside each agent's opt-in telemetry, a session where persistence was planted can be linked directly to the later session where it was exploited. That lineage is the piece that per-session shell history and per-decision approval logs cannot reconstruct on their own, since neither was designed to look backward across sessions for a planting event tied to today's action.
Teams evaluating this approach for engineering organizations that already run Codex, Claude Code, or Cursor at scale can review the enterprise integration model directly, and the GitHub organization has the open-source components for teams that want to inspect the sidecar mechanics before adopting it more broadly.
Building Runtime Forensics into Your Coding Agent Stack
Runtime forensics becomes usable in an enterprise environment only when it plugs into the identity, endpoint, and SIEM tooling that security teams already run, rather than asking them to watch a separate console. The integration points fall into three groups.
Identity and Endpoint Integration
Every mediated action needs to resolve to a real developer identity, not just a workspace path, so that lineage across sessions and repositories can be tied to a person and a device. This is where mediation layered onto existing identity and endpoint tooling covers ground that agent-native logging, scoped to a single machine's local settings files, cannot.
MCP and SIEM Integration
MCP tool calls are one of the highest-value events to capture, since they are also one of the more common injection surfaces described earlier. Feeding mediated MCP events, approval decisions, and session lineage into an existing SIEM lets a security team triage agent incidents in the same pipeline as every other alert, instead of standing up a parallel review process just for coding agents.
Getting Started Without an SDK Rewrite
Because sidecar mediation wraps the agent rather than replacing its runtime, adoption does not require migrating off Codex, Claude Code, or Cursor, or rewriting how developers invoke them. Teams that want to see the mechanics before committing to a rollout can book a demo or review current plans on the pricing page; engineers who prefer to start with the open-source pieces can join the conversation on Discord.
FAQ
What is runtime forensics for AI coding agents?
Runtime forensics for AI coding agents is the reconstruction of an autonomous coding session's actions, in order and with intent, from the evidence it leaves in the repository, shell, and harness. It differs from built-in approval logging by answering what happened across a full session and across sessions, not just whether one tool call was permitted.
How is this different from Codex or Claude Code's built-in logs?
Codex's OpenTelemetry export and Claude Code's permission settings each record decisions inside their own agent's process, scoped to one session or one repository's settings file. Runtime forensics correlates that evidence with git history, shell history, and other harnesses, and links related events across sessions, which neither built-in system is designed to do on its own.
Does adding runtime forensics require rebuilding our agent stack?
No. A sidecar model mediates an unmodified agent like Codex, Claude Code, or Cursor from alongside it, without requiring an SDK rewrite or a change to how developers invoke the tool.
What is a live workspace fork in this context?
A live workspace fork treats an agent session's changes as a unit that can be inspected, then merged, promoted, rolled back or discarded before it becomes a permanent part of the repository, rather than applying changes irreversibly and reverting after the fact if something goes wrong.
Can memory poisoning really be traced back to an earlier session?
Tracing it requires lineage that links the session where a malicious instruction was planted to the later session that acted on it; per-session logs generally do not preserve that link on their own. Runtime mediation designed for cross-session lineage is intended to make that connection visible as design intent, though results depend on how completely a given environment captures both sessions.
Conclusion
Runtime forensics for AI coding agents exists because approval logs and shell history each answer a narrower question than "what happened across this session, and how does it connect to the last one." Codex and Claude Code both give developers meaningful control over individual decisions, but reconstructing a long-horizon or cross-session attack needs mediation and lineage that spans the repository, the shell, and every harness in use, not one agent's opt-in telemetry. Mandatory mediation and live workspace forks, applied as a sidecar to agents teams already run, are how that reconstruction becomes practical instead of theoretical. If your organization is running Codex, Claude Code, or Cursor at scale and needs this visibility built into existing identity, endpoint, and SIEM tooling, book a demo to see how it fits your environment.