AI Assistants

AI Assistants

Overview

AI assistants and coding agents now hold some of the most revealing data on a host. A chat history shows what the user asked and what they were told. An agentic tool goes further: it can run shell commands, read and write files, fetch URLs, call third-party services through connectors, and act under permissions the user granted. The local footprint of these applications can therefore answer questions that no browser or shell history can: what was the user planning, what did they paste or upload, what did the agent do on their behalf, and what was it allowed to do.

This section documents those footprints. Most of these applications are Electron or Chromium-based, so their artifacts reuse formats covered elsewhere in the knowledgebase (LevelDB, IndexedDB, Chromium HTTP cache, SQLite cookies, JSON state files). What is new is the layout, the schemas, and the investigative questions.

Applications

  • Claude Desktop — Anthropic's Electron app: cached conversations, Cowork agent sessions with an HMAC-chained audit log, MCP servers and extensions, logs, and application state

Coverage

Claude Desktop is the first application documented here. The macfor AI Assistants suite plans further coverage (other desktop assistants and command-line coding agents), but this section describes only what has been researched and implemented.

Why this data matters

QuestionWhere the answer lives
What did the user ask, and what was the answer?Cached conversation stores and cached API responses
Did an agent run a command or touch a file, and did the user approve it?Agent session transcripts and the permission events in the audit log
What external services could the assistant reach?MCP server and extension configuration
Was sensitive data pasted or uploaded?Conversation attachments, upload folders, unsent drafts in browser storage
When was the app installed, updated, launched, and signed in?Logs, updater state, application config
Has the record been altered?The audit log's HMAC chain, where it can be verified

Server-side versus local

Chat history for these services is authoritative on the vendor's servers. A host collection recovers only what the app cached or wrote locally, which varies by application and version.

Locally availableNot locally available
Recent conversations cached by the app (a window, not the full history)The complete account history
Conversations the user later deleted, while stale copies survive in storageAnything the vendor retained after local deletion
Full local agent sessions: prompts, tool calls with inputs, results, permission decisionsServer-side moderation or safety records
Configuration: connectors, extensions, trusted folders, permission settingsAccount state held only by the service
Logs and state that build a timeline of installs, launches, and sign-insCredentials in plaintext (these are encrypted at rest)

Treat absence of a conversation locally as meaningless on its own. It may never have been cached, may have aged out, or may have been removed. Account-level history requires legal process to the vendor or an authorised export from the account.

Common themes

  • Several stores per conversation. The same message can appear in an IndexedDB store and in the HTTP cache. Correlating them gives provenance and sometimes reveals differences.
  • Deleted is not always gone. LevelDB keeps superseded and deleted values until compaction. Recovered values should be labelled as such in a report.
  • Secrets beside the evidence. MCP configuration holds API keys in env blocks, and tokens and device keys sit next to conversation data. Handle collected data as highly sensitive, and prefer redacted output for reports.
  • Fast-moving formats. These applications update frequently and schemas change between releases. Record the app version for every finding.
  • User versus agent. Agent audit logs and permission events are the best evidence for separating what the human did from what the software did.

References

Next
Claude Desktop