guide
By ReclaimLLM TeamReconstruct an AI coding session from tool calls, policy decisions and results. Know what the evidence proves, and where the record stops.
Updated November 14, 2026.
An agent has changed a configuration file. A developer remembers approving a command. The final chat message says the tests passed. Security asks whether the agent also read a credentials file.
Those statements describe different parts of the session. To answer the question, you need a sequence that connects a requested action to a policy decision and an observed result. A useful AI coding audit trail also makes its missing evidence visible.
Start with one session and one question: what can we establish about this file read, command or change?
Treat these as separate records when you design or evaluate capture:
A policy response of allow does not prove that someone clicked an approval button. A proposed command does not prove execution. A successful command does not prove that its output was safe to send elsewhere.
Preserving those distinctions prevents an investigation report from claiming more than the evidence supports.
This gap is real in at least one tool. In November 2026, Cursor staff said there is no platform audit trail that links a proposed tool call, the user's decision (accepted, rejected or auto-approved) and the execution result into one searchable record. They added that the approval-card decision is not passed through hooks (Cursor forum, t/156247/10). A team that needs that link has to build its own record.
Cursor's hook reference documents conversation and generation identifiers, with tool_use_id on generic tool events. It provides separate hooks before execution, after success and after failure. These fields can support correlation when the events reach your collector. The same reference describes a pre-tool policy response; it does not establish that your collector receives a human approval record.
Claude Code offers more of this natively. With OpenTelemetry export turned on, Claude Code emits a claude_code.tool_decision event for each permission decision, with decision (accept or reject) and source, which says whether the decision came from configuration, a hook, or the user (user_temporary, user_permanent, user_reject, user_abort). It also emits a claude_code.tool_result event when a tool completes. Both carry a tool_use_id that matches the ID passed to hooks, so you can join them (Claude Code monitoring docs). Prompt text and tool arguments are redacted unless you set OTEL_LOG_USER_PROMPTS and OTEL_LOG_TOOL_DETAILS. Claude Code hooks also receive a transcript_path to the session transcript file, which may lag the current turn (Claude Code hooks reference). Together, these are the closest thing to built-in Claude Code audit logs for agent actions. Note that, in the interactive CLI, a later call allowed by a saved rule reports config, not the original user approval.
Choose an explicit mapping for each assistant you capture. Do not assume another tool uses Cursor's identifiers or event meanings. Store the source event type alongside any normalized label so a reviewer can trace your interpretation back to the original event.
The following example is synthetic. It illustrates an investigation worksheet, not a ReclaimLLM export or a customer session. The identifiers and outcomes are invented solely to explain the method.
| Order | Session / action | Recorded evidence | Supported conclusion |
|---|---|---|---|
| 1 | demo-session / read-1 | Request to read config/example.env | The agent proposed this read. |
| 2 | demo-session / read-1 | Policy collector records deny | The recorded policy rejected it. |
| 3 | demo-session / read-1 | Tool failure reports permission denied | The observed read attempt was denied. |
| 4 | demo-session / shell-2 | Request to run python scripts/check_config.py | The agent proposed a different route. |
| 5 | demo-session / shell-2 | Result says exit code zero; output omitted | A result was recorded; its contents are unknown. |
| 6 | demo-session / edit-3 | Diff changes a configuration loader | The captured change can be reviewed. |
This record supports a narrow finding: the direct file read was denied. It does not establish what the later Python script read internally or printed. Review that script, its available output and any relevant runtime evidence before concluding the file remained untouched.
The worksheet also has no human approval record. Write “human approval not captured,” even if a developer remembers approving the command. Their recollection can be added as an interview note, with its source clearly identified.
When a request has no corresponding result, mark its outcome unknown. Then check whether capture stopped, the tool was interrupted, the event was filtered or the action ran through a different surface.
Cursor's current cloud hook documentation describes early read-only turns without hooks. It also documents restricted visibility into backend-hosted HTTP MCP results. A missing payload in those paths cannot establish that nothing sensitive happened.
Keep a coverage note with each investigation: assistant version, execution environment, capture configuration and known omissions. This makes a later reviewer less likely to interpret an incomplete record as a complete account.
An evidence record can itself contain credentials, personal information and private source code. Decide which fields you need before forwarding entire tool payloads into another system.
Redact sensitive values while retaining useful relationships: a consistent placeholder can show that two events refer to the same path without displaying a developer's home directory. Document redaction and truncation so reviewers understand why content is absent. Restrict access to session exports and choose a retention period that matches the investigation purpose.
For the local storage risks, see where AI coding transcripts keep secrets.
ReclaimLLM's search and replay view brings captured conversations and tool activity together, with results and file changes where the capture source supports them. That makes the session a practical starting point for review. The scope of the answer still depends on what was captured; replay alone cannot establish missing approvals or unseen execution.
Before relying on a capture setup, run a harmless test: one allowed read, one denied read, one failed command and one file edit. Compare the resulting record with what you observed. Repeat when your assistant or capture configuration changes.
For auditor-facing exports and control evidence, use the separate SOC 2 evidence guide. For a session investigation, finish with three statements: what happened, what evidence supports it and what remains unknown.