User identity and local data

Claude Desktop on third-party (3P) keeps conversations, settings, and credentials on the device. For SSH remote sessions, the remote host also stores their conversations and receives your inference credential. When the configuration comes from MDM, a local file, or a bootstrap server, users have no Anthropic account and never sign in to Anthropic, and Anthropic holds no per-user state. When your organization manages the app from the Enterprise Admin Console, users sign in with a Claude account to receive their settings, and Where your data goes lists what Anthropic stores in that case.

​

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. When the configuration comes from MDM, a local file, or a bootstrap server, this identifier and the deploymentOrganizationUuid from your managed configuration are what’s attached to telemetry events. The identifier is random per device and per OS-user account, and Anthropic cannot trace it back to a real device or person. In an organization managed from the Enterprise Admin Console, users sign in with a Claude account, so the app is not anonymous to Anthropic there, and Where your data goes describes what Anthropic stores in that case. The OpenTelemetry export to your own collector is the exception: it identifies the user directly. Each exported record carries an enduser.id resource attribute with the user’s identity and a process.owner attribute with the operating-system login name, so attributing activity to named users needs no collector-side correlation. See User attribution for where the identity comes from and the endUserAttribution key that controls it.

​

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 app encrypts stored sign-in tokens and similar secrets with the operating system’s secure storage (see Credentials), but not conversations, settings, or locally applied configuration, including an API key saved from the in-app configuration window. Protection at rest for those files depends on the device’s full-disk encryption, such as FileVault or BitLocker. 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 for new sessions and conversations (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. Each project also keeps its own memory under local-agent-mode-sessions/.../spaces/<projectId>/memory/. Cowork sessions inside a project read and update the project’s memory rather than the files under local-agent-mode-sessions/.../memory/memory/. A Chat conversation inside a project can read the project’s memory but cannot change it, as described under Chat conversations.

​

Chat conversations

Chat conversations 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, through sandbox network access, 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 read-only and applies only inside projects. A Chat conversation inside a project can read that project’s memory unless memory was paused when the conversation started, but cannot add to or change it. Chat conversations outside a project do not read or update memory.
• Project folders are read-only. A Chat conversation inside a project can read files in folders added to the project in Claude Desktop, under the conditions in Project folders in Chat, and cannot change them.
• Claude cannot search past chats. Users can search their own conversations in the app, which scans the per-session files on the device on demand, but 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 writes only inside the session directory. When advanced file analysis is enabled, code runs in a local sandbox. Commands in it can reach the hosts in coworkEgressAllowedHosts, as described under Sandbox network access. The sandbox writes only to the conversation’s outputs/ directory, and reads its uploads/ directory, its transcript, and its saved tool results plus, for a conversation inside a project, that project’s memory. For a conversation inside a project, the sandbox can also read the folders added to the project in Claude Desktop, under the conditions in Advanced file analysis.

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 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.

​

Automatic deletion of idle sessions

By default, chats, Cowork tasks, and Code sessions stay on the device until the user deletes them. To delete them after a period without activity, set chatSessionRetentionDays, coworkSessionRetentionDays, or codeSessionRetentionDays to a number of days from 1 to 3650. Each key covers one kind of session, and a kind you leave unset is kept until the user deletes it. Idle time counts from the session’s last activity, and pinned sessions are not exempt. With Unified Claude on, a conversation started from the home screen on a device that can run Cowork is a Cowork session. coworkSessionRetentionDays covers it along with users’ other Cowork tasks, and chatSessionRetentionDays still covers Chat conversations. While coworkSessionRetentionDays is unset, neither key deletes a home-screen conversation that is a Cowork session, even if chatSessionRetentionDays is set. If you use chatSessionRetentionDays, keep it and set coworkSessionRetentionDays as well. The app deletes whole sessions in the background. A chat or Cowork task is deleted with its attached files and outputs, and a Code session with its conversation. Projects, memory, and the files in a Code session’s working folder stay, and Code sessions on an SSH host are not affected. A session that is running or open on screen is skipped until a later pass. To suspend all automatic deletion for some users, for example under a legal hold, set sessionRetentionHold to true for them. While the hold is on, nothing is deleted, and a device that gets its configuration from a server and cannot reach that server also deletes nothing. These keys require Claude Desktop 1.52386.0 or later.

​

Move a user to a new device

On devices that get their managed configuration from MDM, you can move a user to a new device by copying their data. The copy moves:

• Chats, Cowork tasks, and Code sessions
• Projects, project instructions, and memory
• Scheduled tasks, skills, and plugins
• Attached files

​

What the user sets up again

Ask the user to:

• Sign in to the inference provider, if the app asks
• Reconnect each connector
• Enter the environment variables for Code sessions from their original source, because the app masks saved values
• In each project they use from Chat, add folders and file links again
• Set command permissions for plugins

​

Requirements for the new device

The new device needs:

• The same platform (macOS, Windows, or Linux) and CPU architecture as the old device
• The same OS user name and home-directory path. Otherwise, Code sessions, scheduled tasks, plugins, and project folders stop working.
• The managed configuration, with the same deploymentOrganizationUuid, in place before Claude Desktop launches
• The same Claude Desktop version, or a newer one

​

Copy the data to the new device

1. Quit Claude Desktop on both devices. Closing its window isn’t enough.
2. If the new device has an application-data directory (see Where data lives), delete it. This removes anything the user created in it.
3. Copy these to the same paths. On Windows, use a copy tool that supports paths longer than 260 characters.
   • The application-data directory, except these files in it, which the app creates again when it needs them:
     • host-creds-*.json
     • ccd-session-secrets/
     • spaces-present/*/*/link-key
     • ccd-environment-config.json
     • cowork-enabled-cli-ops.json
     If you copied any of them, quit Claude Desktop on the new device, then delete them.
   • ~/Claude/, or ~/Documents/Claude/ on legacy installs
   • ~/.claude/ and ~/.claude.json
   • The folders and repositories that the user’s projects, scheduled tasks, and Code sessions use
4. Make the user the owner of the copied files, with read and write access. Give no other user account access to the application-data directory, ~/Claude/ or ~/Documents/Claude/, ~/.claude/, or ~/.claude.json.
5. Have the user launch Claude Desktop, and confirm that their chats, Cowork tasks, Code sessions, and projects appear. If they don’t, check that the managed configuration has the old device’s deploymentOrganizationUuid and that the user owns the copied files. Soon after launch, a scheduled task runs once if it recently missed a run.
6. Have the user set up what the copy doesn’t move.
7. If the old device stays in use, its enabled scheduled tasks run on both devices. Retire the old device, or turn off its scheduled tasks in Claude Desktop there. To remove the user’s data from it, see Removing data.

​

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. Code session transcripts are in Claude Code’s store at ~/.claude/projects/, which Claude Code in the terminal also uses, so delete them there separately if you need to remove them. For SSH remote sessions, transcripts are in ~/.claude/projects/ and attached files in ~/.claude/uploads/ in the SSH user’s home directory on the remote host. Claude Desktop also copies those transcripts to the device, into folders in ~/.claude/projects/ whose names start with ssh-, so delete them in both places. 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. Except for SSH remote sessions, conversation history exists only on this device, so deleting it is unrecoverable. Deleting an SSH remote session in the app doesn’t delete its transcript on the remote host.