Data and storage

Your chats, code and keys stay on your computer, in a few folders you can inspect and delete. By default, only this leaves it:

• What the model sees, sent to the provider you chose, on every request.
• What you or the agent reach on purpose: web pages, MCP servers, git, npm and the like.
• A daily usage summary of counts, with no content, sent to Haarness Cloud. It is on by default; turn it off with one command.

Haarness Cloud gets more only when you sign in, use remote control or turn on phone notifications.

What leaves my computer?

Haarness sends no crash reports. The CLI checks for updates only when you run haarness upgrade.

Your provider's own terms decide what it keeps. Pick the provider and plan accordingly.

Usage statistics

Haarness shares a small summary of how it is used with Haarness Cloud, so the team can see which models and tools people rely on and where turns fail. It is on by default, and you are not asked first. Turn it off with any one of these:

The environment variables win over the setting, which makes them the way to keep CI jobs and scripts out of the statistics. haarness telemetry status shows whether sharing is on and when the last report was sent, and haarness telemetry on turns it back on. A project's configuration cannot change this setting, so a repository you clone cannot turn sharing on or off for you.

See exactly what would be sent, at any moment:

haarness telemetry preview

Desktop shows the same report under Settings → General → See what's shared, and the terminal UI under /usage-statistics → Show what is shared.

What is sent. One summary per day, for the last seven days, counted from the history on your computer:

• chats and turns: completed, failed, interrupted, run by subagents and run by schedules;
• input, output and cached tokens, and Haarness's own cost estimate;
• tool calls and tool errors for each built-in tool, and files changed with lines added and removed;
• all of that per provider and model. Providers and models are named only when Haarness ships them. Anything else is counted as custom, other or local, and every MCP tool as mcp;
• a random install id, the Haarness version, your operating system and CPU type.

What is never sent: prompts, answers, code, file contents, file names, paths, project or chat titles, tool arguments or output, the names of custom providers, models or tools, environment variables and credentials.

When. A running Haarness server sends the summary when the last one is more than about six hours old. The background server that the terminal UI, Desktop and haarness run start does this too. haarness telemetry send sends at once.

Who it is linked to. While you are signed in to Haarness Cloud, the summary is linked to your account. Otherwise it is anonymous, tied together only by the random install id. Cloud keeps each day's summary for 400 days; the privacy policy has the details.

Usage statistics are separate from tracing: turning one off does not affect the other, and traces never go to Haarness.

Where is my data?

haarness doctor prints the data folder this install uses, on its data: line. On macOS too, XDG_CONFIG_HOME, XDG_DATA_HOME and XDG_CACHE_HOME move these folders.

An absolute HAARNESS_HOME keeps everything in that one folder, including the Cloud sign-in, schedules and caches, so a second install with its own HAARNESS_HOME shares nothing with your usual one:

HAARNESS_HOME=~/haarness-test haarness doctor

Without HAARNESS_HOME, macOS keeps a few things in ~/Library/Application Support/dev.haarness.haarness/: schedules, saved command output, previews and global workflows. If you used an older version, ~/.local/share/haarness may be a link to that folder. Desktop keeps its window state and preferences in its own app-data folder.

Who can read my keys?

Provider keys (auth.json), MCP sign-in tokens and your Cloud sign-in are saved in files only your user account can read. They are not in your operating system's keychain, so any program running as you, including the agent's shell commands, can read them.

An MCP server's keys can live in the system keychain instead (the Keychain on macOS, Credential Manager on Windows, the Secret Service keyring on Linux). Store one with haarness mcp secret set NAME, or with the key toggle in Desktop's MCP server form, and the settings name it as ${keychain:NAME}. Haarness reads it only when the server starts and sends it wherever those settings say, so name keychain entries only in settings you trust. On Windows and Linux, other programs running as you can read those entries too.

haarness mcp get hides environment and header values unless you add --show-secrets.

Export or move a chat

A chat moves between computers as a file. The sessions commands list, export and import this folder's chats:

haarness sessions list
haarness sessions export <id> --output chat.json
haarness sessions import chat.json

An export contains the chat and every subagent chat it started. It never contains checkpoints, keys or approvals. The file is readable only by you.

To share one, add --sanitize. Messages, reasoning, tool calls and their results, titles, plans and to-do items are replaced by placeholders. IDs, times, model names and token usage stay.

Share a chat

/share in the terminal UI shows you exactly what will be published, then creates a read-only link to the chat on your Haarness server. Anyone who can reach that server and has the link can read it, with no sign-in, for seven days or until you revoke it from /share. Choose whether to include tool output; review it for secrets first.

Continue a chat on another device

/remote-control in Desktop or the terminal UI lets you use one chat from Haarness Cloud. The chat, its files and your model keys stay on your computer, and its work runs there. While it is shared, what you open from the browser (messages, files, approvals) passes through Haarness Cloud's relay on its way to you. Cloud keeps the chat's title and the IDs it needs to list it and, while a request waits in it, that request's kind and time; never the command, the question or the messages. In a team account, members with builder access or above can use a shared chat too, and viewers see it listed. /remote-control stop ends access. See Remote control.

Notifications on your phone

Haarness for iPhone and Haarness for Android can tell you when an agent needs you or finishes. Notifications are off until you turn them on in the app. They reach an iPhone through Apple Push Notification service, and an Android phone through Firebase Cloud Messaging, Google's push service, when your Haarness Cloud sends to Android phones.

What Apple receives: your phone's notification address (a token Apple gives the app) and what the notification shows: the chat title, the project and computer or the Cloud workspace name, a fixed phrase for the kind of request (for example "Wants to run a command"), the number of requests waiting, and the IDs the app needs to open the chat. A Live Activity update carries its state, that number and, when a new request arrives, the chat title and the kind of request. Billing and security notifications carry only the kind of notice and, for a team's billing, the team's name.

What Google receives, for an Android phone: the same as Apple: the phone's notification address (a token Google gives the app) and the same notice, with the same content. A live update carries the same as a Live Activity update. Haarness Cloud sends it as a data message: Google hands it to the app, and the app shows the notification. Without that token (an API-key sign-in, a phone without Google Play services, or a Haarness Cloud that does not send to Android phones), the app asks Haarness Cloud itself for what needs you, and nothing goes through Google.

A chat's title can be the start of what you asked. Unless you name a chat, its title comes from its first message: a chat Haarness Cloud starts for you is named after the first 80 characters of that message, and other chats get a short title written from it. Whatever is in the title is in the notification, so rename a chat if its title says more than you want on your Lock Screen and on Apple's or Google's servers.

What is never sent: the command, file contents, the question or its choices, your messages beyond a chat's title, the agent's replies and tool output. Open the chat to read them; they come from your computer or Cloud workspace when you do.

What Haarness Cloud keeps:

Answers you give from the Lock Screen or a notification go through Haarness Cloud to your computer or Cloud workspace, like an answer in the Cloud app.

Memory

Memory is notes the agent saves about a project, so later chats start with them. They are kept in your Haarness data folder, not in the repository. Open /memory in the terminal UI, or Memory in Desktop, to read, edit or turn it off. Turning it off keeps what was saved.

Checkpoints

Checkpoints are copies of files taken before the agent changes them; /undo and /diff last use them. They are stored in your Haarness data folder and, by default, kept for 7 days, with the latest 20 per chat kept however old. Files larger than 2 MiB are not copied, so /undo cannot restore them. See Review changes.

Logs

haarness logs
haarness logs --tail 200

Logs are written to the logs folder in your Haarness data folder (~/.local/share/haarness/logs/ by default), one file per day, and kept until you delete them. They record what happened: IDs, tool names, errors. Read a log before you attach it to a bug report.

Configuration profiles

A profile packs up your settings to use on another computer. It leaves out provider keys, MCP sign-ins, Cloud sign-in, .env files, *.pem and *.key files, and your chats. A key you typed directly into a settings file is included. Keep keys in environment variables or auth.json.

Delete my data

There is no command that deletes a chat or all your data. /archive hides a chat; it does not delete it.

To remove everything Haarness stored on this computer:

1. Remove your schedules with haarness schedule remove <id>, so the system stops starting them. If you kept MCP secrets in the system keychain, remove each with haarness mcp secret remove NAME.
2. Quit Desktop and run haarness serve --stop in each project you used.
3. If you set up Chrome, run haarness browser remove --all and remove Haarness from chrome://extensions.
4. Delete ~/.config/haarness, ~/.local/share/haarness, ~/.cache/haarness and ~/.config/haarness-cloud. On macOS, also delete ~/Library/Application Support/dev.haarness.haarness. If you set HAARNESS_HOME, delete that folder instead.
5. Delete .haarness/ and .haarness-chat-attachments/ folders in projects if you no longer want their settings and captured files.

Deleting your local data does not delete the usage summaries Cloud already received; the privacy policy says how long they are kept and how to ask for deletion. Deleting a Cloud workspace destroys its disk. See Cloud workspaces. To delete your Haarness Cloud account, see Delete your Haarness account.