How to Reconstruct What an AI Agent Did During a Session on a Developer's Laptop

To reconstruct an AI agent session, you need an ordered record of everything the agent did: the files it read and wrote, the commands and processes it ran, the tools and MCP servers it called, and the requests it sent to model providers, each tied to the agent, session, and user. Today that record is usually pieced together from the agent's own history, shell and git history, EDR, and gateway logs, and it is almost always incomplete. The reliable way to get it is to record agent actions on the laptop as they happen, which is what Qpoint does.

What a complete AI agent session record contains

A record you can investigate with has five parts:

• File activity. Every file the agent read, wrote, created, deleted, or changed permissions on.
• Commands and processes. Every shell command and every process or sub-agent the agent started, with arguments and exit codes, traced back to the agent that started it.
• Tool and MCP calls. Every tool invocation and every MCP server the agent connected to, with inputs and results.
• Outbound requests. Every network request, including calls to model providers, with the prompt sent and the tokens used.
• Attribution. The agent, version, session, user, and host behind each action, in order.

Attribution is what turns a pile of events into a session. Without it, you can see that a file changed but not which agent changed it or why.

Where to look today, and what each source misses

The agent's own session history

Some coding agents keep useful records. Claude Code saves session transcripts locally that show the prompts and the tool calls it made, can export telemetry through OpenTelemetry if an admin turns it on, and supports hooks that can log each tool call. Codex CLI also keeps local session logs.

The limits: every agent records something different, in a different format, and only if it is configured to. The files live on the developer's machine, where they can be edited, deleted, or cleaned up automatically. And they record what the agent asked for, not everything that happened. If the agent runs a script, the script's own file writes and network calls do not show up. Custom agents and agents nobody approved may record nothing at all.

Shell history and git

git diff, git log, and git reflog show what changed in a repository, and file timestamps show when. Shell history may show commands typed in a terminal. None of it says whether a person or an agent made the change, and none of it covers files outside the repo or anything sent over the network.

EDR

EDR records processes, files, and network connections, and it can show that a process was started by claude or cursor. It does not know the agent's session, the prompt behind an action, or what an MCP tool call was. Coding agents also trigger rules built to catch attackers, which makes their activity noisy to investigate.

AI gateway and proxy logs

A gateway shows the requests that pass through it, usually model calls. File reads, shell commands, and local MCP servers never touch the network, so they never appear. Laptops off the corporate network may bypass it entirely.

How to reconstruct a session with what you have now

If something already happened, work through it in this order:

1. Preserve evidence first. Copy the agent's session files and logs off the laptop before anyone clears them, and save the repository state, including git reflog.
2. Find the change. Use git diff and file timestamps to pin down what changed and when.
3. Match it to a session. Line up the change time with the agent's session history to find the conversation and the tool call that made it.
4. Walk the process tree. In EDR, look at processes started by the agent around that time, and at what those processes did.
5. Check outbound traffic. Look at gateway, proxy, or DNS logs for requests from that host in the same window.
6. Ask the developer what they asked the agent to do.

This works sometimes. It is slow, depends on several teams and tools, and breaks when the agent's logs are missing or the activity happened off the network.

Recording sessions as they happen

Qpoint takes the other approach. A single binary runs on the laptop, between the agents and the operating system, and records every action as it happens:

• It finds agents by their behavior, not from a list of known binaries, so Claude Code, Codex, Cursor, custom agents, and agents nobody approved all show up as they start.
• It records file activity, commands and process lineage, tool and MCP calls, and outbound requests, including LLM calls broken down by provider and model.
• It ties every event to the agent, session, and signed-in user.
• It tags reads of sensitive paths, such as SSH keys and credential files, automatically.
• It needs no wrappers, SDKs, or changes to how developers work. The agent does not know the difference.

The record does not depend on the agent's cooperation, and it survives even if the agent's own logs are deleted. See Qpoint Monitor for everything it records.

Example: a deploy script changed unexpectedly

An engineer reports that a deploy script was modified and no one remembers changing it. Incident response searches for writes to that file and lands on one session:

The agent read a README that contained instructions, called a shell tool, and rewrote the script, all within 40 seconds. Nobody had to interview the developer or find the agent's logs.

Rolling it out to developer laptops

• Platforms: macOS, Windows, and Linux.
• Deployment: push the binary through Jamf, Intune, a script, or the Qpoint installer, to a pilot group or the whole fleet.
• Offline laptops: events are stored on the machine and sync when it reconnects, so sessions on planes and home networks are still recorded.
• Where events go: a single normalized stream you can send to Splunk, Datadog, Elastic, or your existing pipelines.
• Your data: the control plane and event stream run in your environment. Qpoint never sees your data.

More on rolling out to laptops is on the endpoints page.

Beyond recording: rules and enforcement

The same binary that records agent activity can also set rules for agents across the fleet, such as approved agents and MCP servers, and block or redact actions, like reading credential files, before they complete.

Frequently asked questions

Can't we just use the agent's own logs? They help, but they are different for every agent, depend on configuration, live on the developer's machine, and do not capture what processes started by the agent go on to do.

Does this change how developers use their agents? No. There is no wrapper, proxy, or SDK. Developers keep using Claude Code, Cursor, or Codex as they do today.

What if the laptop was offline? Events are stored locally and sync when the laptop reconnects.

Can we see what the agent sent to the model? Yes. Outbound requests are recorded, including LLM calls with provider, model, and token usage.

See it on your own laptops

Book a demo and we'll show you Qpoint recording a live agent session, from the first file read to the last request, and walk through how it would roll out to your fleet.

Related Articles

• Build or Buy: Adding AI Agent Visibility to Your Endpoint Security Product
• Monitoring AI Agents in Kubernetes and CI Runners: What to Use
• Audit Logs and Policy Controls for AI Agent Sandboxes: What You Can Build On