User identity and local data

Claude Desktop on third-party (3P) has no Anthropic account. There is no sign-in step, no cloud-stored conversation history, and no per-user state on Anthropic infrastructure. Identity and persistence are entirely local to the device.

​

Identity

When the app first launches in 3P mode, it generates a random UUID and writes it (base64-encoded) to the ant-did file in the application-data directory. This identifier, together with the deploymentOrganizationUuid from your managed configuration, is what’s attached to telemetry events. It is random per device and per OS-user account, and Anthropic cannot trace it back to a real device or person. If you need to attribute Claude Desktop activity to named users, configure OpenTelemetry export and join the exported events to your identity system on the collector side, or include user identity in the headers your managedMcpServers helpers emit.

​

Where data lives

Claude Desktop on 3P stores everything under a dedicated directory, separate from standard Claude Desktop, so the two modes can coexist on one machine without interfering. Within the application-data directory: Files in this directory are written with owner-only permissions so other OS accounts on the same machine cannot read them. The logs directory contains main.log (application and configuration-validation events), cowork_vm_node.log (sandbox VM activity), claude.ai-web.log (renderer events), and mcp.log / mcp-server-<name>.log (MCP connection events). Separately from the application-data directory, Claude Desktop writes user-visible outputs (Artifacts and scheduled-task results) to ~/Claude/ in your home directory, or ~/Documents/Claude/ on legacy installs. This folder is intended for you to browse directly and is not removed when you delete the application-data directory.

​

Memory

During Cowork sessions, Claude writes short Markdown files recording what it has learned about the user — working preferences, project context, and corrections — and reads them at the start of subsequent sessions. These files live under local-agent-mode-sessions/.../memory/memory/ and never leave the device. Users can review and delete individual entries, or pause memory entirely (existing files are kept but not read or updated), under Settings → Cowork → Memory. The same page exposes a Global instructions editor for the CLAUDE.md file that is included in every session. Memory belongs to Cowork sessions only: Chat conversations neither read nor write these files.

​

Chat conversations

Conversations in the Chat tab follow the same storage model as Cowork sessions: each conversation is a session state file plus a working directory under local-agent-mode-sessions/, in the layout described in the table above. The state file records the conversation; the working directory holds the transcript, an uploads/ directory with copies (or hard links) of files attached to the conversation, an outputs/ directory for files Claude creates during the conversation (its scratch space), and the same HMAC-chained audit.jsonl event log. Because attachments are hard-linked where the filesystem allows it, edits made to the original file while the conversation is open can be visible to the conversation. Conversation content leaves the device only as inference requests to your configured provider, as web search queries to your configured search backend, through web access your egress configuration allows, in connector tool calls permitted by your toolPolicy configuration and the user’s approvals, and, if you have enabled content capture, in telemetry to your own collector. For the questions security reviews most often ask about Chat:

• Memory is not used. Chat conversations do not read or update the memory files described in the previous section.
• Past chats are not searchable. There is no index of conversation content, server-side or local (history exists only as the per-session files above), and a Chat conversation has no tools for listing or reading other sessions’ transcripts. Each conversation is isolated to its own directory.
• The advanced file analysis sandbox stays inside the session directory. When advanced file analysis is enabled, code runs in a local sandbox that reads only the conversation’s uploads/ directory and writes only its outputs/ directory, with no network access.

Deleting a conversation’s session state file and working directory removes all of this; there is no other copy.

​

Credentials

Inference credentials are handled according to how they’re delivered:

• Managed configuration (for example, inferenceGatewayApiKey, inferenceBedrockBearerToken): read from the OS preference store or registry at launch and held in memory. The app also writes resolved credentials to a small set of transient, owner-only files for its own session processes, described below.
• OAuth tokens (in-app Google sign-in, MCP servers with oauth: true): stored in the application-data directory, encrypted with the operating system’s secure storage (Keychain on macOS, DPAPI on Windows).
• Credential-helper output: held in memory for inferenceCredentialHelperTtlSec seconds, then discarded and re-fetched.

​

Transient credential files

Parts of each session run as separate processes: the sandbox VM for Cowork sessions, and the Claude Code runtime for Code tab sessions. Processes that cannot receive credentials through an in-memory channel read them from short-lived files that the app writes for them. All of these files are created with owner-only permissions and are cleaned up automatically: Aside from these files, credentials delivered through managed configuration are held in memory only.

​

Removing data

To fully reset a device’s Claude Desktop on 3P state, delete the application-data directory above and the ~/Claude/ user-files folder. To return to standard Claude Desktop without removing data, choose the Anthropic sign-in option on the sign-in screen; to also remove the locally authored 3P configuration, delete the configLibrary/ directory. Conversation history exists only in this directory, so deleting it is unrecoverable.