To audit an AI assistant, compare its file changes with a known repository baseline, inspect the session or tool logs, and check any external service it touched. To undo work, use the recovery mechanism for where the change happened: an IDE checkpoint or Git for repository files, and the affected service’s own recovery controls for commands, deployments, API calls, or other outside effects. No single undo button covers all of these.
Start with a known state and limited permissions
Before asking an assistant to make changes, check the repository’s working tree. If it is clean, a commit gives you a durable baseline. If you already have uncommitted work, identify it clearly—by reviewing or recording the changed files—so you do not mistake it for the assistant’s work or discard it during recovery.
As an Amazon Associate I earn from qualifying purchases.
Decide what the task actually requires the assistant to access: files, terminal commands, network connections, and external services. Where the host permits it, limit permissions and approvals to the task or session. In VS Code, Microsoft recommends opening untrusted projects in Restricted Mode, using agent sandboxing on supported platforms, reviewing edits before integrating them, and protecting sensitive files. Its guidance also warns that tools and commands may use your credentials to push code, change infrastructure, call APIs, or trigger deployments. See Microsoft’s VS Code security guidance.
Inspect what changed before accepting or merging it
Open the assistant’s changed-file list and review the diff against your request. Check additions, deletions, and edits to configuration or other sensitive files; verify the purpose of each meaningful change rather than relying on the assistant’s summary. In VS Code, supported workflows show affected files and line counts, and let you review changes before a commit, merge, or pull request. In the extension-host workflow, pending edits can be accepted or rejected individually, or resolved from the chat view. The exact controls depend on the VS Code workflow and session. See VS Code’s review and revert documentation.
#1 Best Overall
For a Git repository, these commands help establish what is currently changed and whether anything is staged:
git status --short
git diff
git diff --cachedThe first command lists changed paths; the second shows unstaged changes, and the third shows staged changes. A diff is evidence of file changes, not a full record of terminal commands, approvals, network activity, or external effects. For an overview of Git history and workflows, see Pro Git.
Keep the right record for the question you need to answer
A diff answers “which tracked file lines changed?” A session record can help answer “what did the assistant do, and in what context?” An administrative audit log is for organization-level activity and may not include the conversation itself. These records complement one another; none should be assumed to contain every action or to have the same access and retention rules.
Recommended Free Tools
| Record or control | Useful for | Important limitation |
|---|---|---|
| IDE diff or pending-edit review | Seeing affected files and lines; accepting or rejecting supported edits | Workflow varies, and some changes may already be written to disk before review |
| IDE checkpoint | Returning supported workspace files to an earlier request state | Temporary and limited to supported workspace changes; does not reverse completed outside actions |
| Git history | Durable repository history, collaboration, and recovery of tracked files | Does not by itself explain the assistant’s intent or undo effects in other systems |
| Agent session log | Reconstructing session activity; details vary by platform | Availability, content, sharing, and retention vary |
| Enterprise audit log or compliance API | Organization-level investigation, filtering, and export of covered events | May omit chat content; access, coverage, plan eligibility, and retention vary |
| External service audit and recovery controls | Checking actions against APIs, cloud services, deployments, or other systems | Separate from local workspace rollback; the affected service must be identified |
For custom records, VS Code agent hooks can record tool invocations, command execution, and file changes. GitHub’s Copilot SDK documentation describes lifecycle hooks for custom safety checks, audit logging, and approval workflows. Treat hooks as part of a control system: decide what they collect, protect the resulting logs, and test their behavior in the host you use. See VS Code security guidance and GitHub’s Copilot Agents documentation.
Rank #3
GitHub Copilot cloud-agent session pages show progress, token usage, and session length; its cloud-agent commit messages link to session logs. That connection can help explain a repository change during review, but it is not a substitute for checking the diff. See GitHub’s session management documentation.
Choose a file recovery method that matches the change
Restore a supported VS Code checkpoint
In a supported VS Code chat session, navigate to the earlier request and choose Restore Checkpoint. Microsoft says this restores affected workspace files and removes subsequent requests from that conversation history. Checkpoints are temporary and do not replace Git for permanent history or collaboration. In the extension-host workflow, you can instead accept or reject pending edits individually.
Rank #4
Before restoring, confirm that later requests and file changes are not work you need to keep. If you are unsure, inspect the diff and preserve a copy or commit of useful work first. A checkpoint only covers what that session’s checkpoint supports.
Use Git for tracked files
Choose a Git operation based on whether the unwanted change is unstaged, staged, or committed. First inspect git status and the relevant diff; then target only the file, hunk, or commit you intend to change.
Best Value
- Unstaged edits: To discard all unstaged changes in one specific tracked file, use
git restore -- path/to/file. This replaces that file with its index version, so do not use it if the file contains unrelated edits you want to retain. For a selective interactive restore, usegit restore -p -- path/to/fileand review each hunk. - Staged edits: To unstage a file without discarding its working-tree edits, use
git restore --staged -- path/to/file. Inspect the diff afterward; the edits remain in the working tree. - Committed change: For a change that should be undone while preserving shared history, create a revert commit with
git revert <commit>. Review the resulting change before sharing it.
These commands have different effects depending on repository state. Avoid treating a broad reset or deletion as a universal rollback: preserve unrelated user work, and coordinate recovery if the change is already shared.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Recover separately from commands and external actions
A workspace checkpoint does not reverse a completed terminal command, network request, deployment, or change made to an external service. If an agent is still running, stop it to prevent further actions, but do not assume that stopping has rolled back work already completed.
- Identify the command or tool action, when it ran, and every service or resource it may have affected.
- Check that service directly—using its activity or audit events, version history, transaction controls, backups, or documented recovery procedure—to establish whether the action completed and whether it ran more than once.
- Choose a compensating action only after assessing its own risks. If code was pushed, identify the commit and coordinate repository recovery with the team.
GitHub says stopping a Copilot cloud-agent session ends its Actions run but preserves commits already pushed. Review those commits and recover through repository history if needed; stopping is not a rollback. See GitHub’s session management documentation. Microsoft likewise distinguishes workspace checkpoint restoration from completed external actions in its review and revert documentation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check what enterprise logs contain and how long they last
Do not treat a session transcript and an administrative audit log as interchangeable. Before relying on provider records, verify the product tier and eligible role, covered event types, whether content or only metadata is recorded, export method, and retention period. Published retention periods below describe different services and record types; they are not a comparison of assistant reliability or equivalent log coverage.
| Provider and record | Published retention | Scope and qualification |
|---|---|---|
| GitHub Copilot enterprise audit log | 180 days | GitHub says its Enterprise Cloud Copilot audit log retains events for the previous 180 days; the documentation recommends streaming events to a SIEM for longer history. GitHub audit-log documentation |
| OpenAI Compliance Logs Platform | 30 days | OpenAI says the platform retains data for 30 days and advises customers needing longer retention to download and retain logs under their own policies. The documentation notes a stateful route deprecation and removal in 2026, so API users should check the current API reference. OpenAI Compliance Platform documentation |
| Anthropic Enterprise audit-log export | Previous 180 days | Anthropic’s page, dated June 15, 2026, says audit-log exports cover the organization’s previous 180 days and do not include chat titles or content. Chat inputs and outputs may be separately available to Primary Owners through data exports. Anthropic audit-log documentation |
OpenAI’s documentation names several supported Compliance API integration providers, including Concentric AI, CrowdStrike, Cyberhaven, Enkrypt AI, and Forcepoint; that list is not an endorsement. Audit records can contain sensitive operational details, so restrict access and choose export and retention policies that fit your organization.
Quick Recap
Reduce the chance and impact of unwanted actions
- Use the narrowest file, tool, network, and service permissions that still let the assistant complete the task.
- Require approval for consequential commands or external actions where the host supports it. GitHub describes Copilot CLI permission prompts as interactive confirmation before actions such as modifying a file, executing a command, or accessing files outside the current directory; see GitHub’s responsible-use documentation.
- Keep human review between generated changes and integration, especially for sensitive configuration or operations.
- Use sandboxing and network restrictions where available. Approval prompts and auto-approval rules are not security boundaries: VS Code warns that terminal auto-approval relies on best-effort command parsing, and model-assisted permission decisions can make mistakes.
- Protect sensitive files, and retain logs with access controls appropriate to the operational details they may contain.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
